From: ccoprmm@oit.gatech.edu (Michael Mealling)
Message-Id: <199407061402.AA11501@oit.gatech.edu>
Subject: Re: New URC Specification is ready....
To: pays@faugeres.inria.fr
Date: Wed, 6 Jul 1994 10:02:27 -0400 (EDT)
In-Reply-To: <773487002.23785.0-faugeres.inria.fr*@MHS> from "pays@faugeres.inria.fr" at Jul 6, 94 11:30:02 am
pays@faugeres.inria.fr said this:
> - it is an error to merge in a single document encoding and use
I agree. The reason I put that in there was that a large number of people
wanted 'real world' examples with full client/server examples in the
new version. I plan on breaking those out into two document eventually.
> - the use part must be moved to sone distinct document or at least should
> be completely implementation independant
Probably not for Toronto but by the end of Fall I would expect two distinct
documents that are completely independent.
> Specific comments:
>
> 1. multiple values for an attribute:
>
> it seems but is not explicit that your choice is to have
> n single-valued attribute-value pairs.
> An alternative solution (see RFC-822) could be
> [attribute_name]:[list-of-value] (with some separator)
>
> I think your choice is preferable, but I would like to see this
> choice
> - justified
> - explicitely stated in the draft
I personally prefer the second but I'm flexible on this. I forsee things with
[list-of-value(s)] such as Collections, Author(s), etc.
> 2. character-sets:
>
> there are some unclear points
>
> -- a value is a text string, specifics left up to ....
>
> do text string means USACII text string?
No. I guess I need to clarify that. So noted.
> then a common method to represent other char-sets must be given
> to avoid each specification reinvent a new method
> else: there should be a specifier of the char-set and representation
> in any case a MIME compatible solution is to be choosen and
> specified, in fact a general method will also allow such things
> as compression (with a compression algo identifier etc...)
I agree. You will note the blatant exclusion of character set issues. I
don't want this document caught up in the character set debates going on
within the IETF. I think this will probably be solved somewhere else but
I'm not sure where.
> 3. structuring precedence
>
> I don't like too much your precedence based structuring, and would
> prefer a real explicit nesting mandatory in any case.
> A grammar specification is required!
Can you enumerate why you don't like the precedence based structure? It's
simple, extensible and buildable without tools. I fear anything more complex
wwill end up not being used. If I had to fill out an ASN.1 object evertime
I wrote a document in WordPerfect I fear I'd have to go learn WordStar again.
> 4. section 5: ??????????
>
> 1. The sentence:
> In order for URCs to be useful they must be contained in some
> type of network based retrieval tool.
> makes no sense : a URC contained in a tool??????
So you can get access to it. If I just have a URC and I have no method
for actually giving it out to anyone then it seems kind of useless.
> 2. the whole paragraph is not related to its title (Usage of URC)
>
> 3. all the stuff about whois++ is irrelevant in a doc about encoding
> and use of URC, it is a section of applicability of whois++
> to store and retrieve URC and must be in some other document
As stated above, I agree that this part of the document should become
another document sometime in the near future. But not right now. It
all needs context.
Thanks for the comments. Expect to see some of them implemented in the
revision.....
-MM
-- ------------------------------------------------------------------------------ <HR><A HREF="http://www.gatech.edu/michael.html"> <ADDRESS>Michael Mealling</ADDRESS> <ADDRESS>michael.mealling@oit.gatech.edu</ADDRESS></A>