Re: Comments on <draft-ietf-acap-mlsf-00.txt>?

From: Gavin Nicol (
Date: Thu Jun 05 1997 - 08:39:49 EDT

>This needs a solution that is above the character stream level and below
>the application protocol level.

>Were it encoded into the character stream, that would result in
>quoting problems which would destroy server-side searching

Perhaps, but perhaps not. It really depends on the search engine.

>Were it put at the application protocol level it would require a
>datastructure so complicated as to be completely impractical and

I would say that this statement is completely inaccurate. Attribute
based-protocols all share a common data model that is very simple.

>In addition, putting it at the application protocol level means that
>a different solution for the same problem will be necessary in each
>application protocol.

I do not consider this to be a bad thing, because you can then
optimise the solution for the particular problem. Searching is a good
example: some systems might perform well searching against mlsf,
whereas others might search better with structure keys. I would say
that linguistic searching based on mslf would not be scaleable.
(i.e. asking a 1GB document the frequency of various language use
would be slow).

>There are *a lot* of attribute-value based protocols including SNMP, LDAP,
>DHCP, ACAP, RFC 822/MIME/HTTP, etc. In fact, the attribute-value model is
>a basic tool in protocol design. There's simply no clean way to represent
>language alternatives of multi-valued attributes at the application
>protocol level.

I think this is completely incorrect. A protocol is nothing more than
a set of data structures, and the encoding of them. There are
obviously a number of ways of representing linguistic alternatives in
data structures, and therefore, there are a number of data structure
encodings possible. That says to me that a number of application level
protocols are possible.

You could have just as easily designed an application protocol based
on SGML: Define a number of private use characters to be SHORTREF's,
which would expand into tagging structures like:

   <TEXT><LANG EN>...<LANG FR>...</TEXT>

though I certainly wouldn't recommend using private use characters in
this way...

This archive was generated by hypermail 2.1.2 : Tue Jul 10 2001 - 17:20:34 EDT