# Re: New URC Specification is ready....

pays@faugeres.inria.fr
06 Jul 94 11:30:02+0200

- Messages sorted by: [ date ][ thread ][ subject ][ author ]
- Next message: Wallace Colyer: "Re: (long) sketch of proposed imap: URL syntax and semantics [TRY AGAIN!]"
- Previous message: John Gardiner Myers: "Re: (long) sketch of proposed imap: URL syntax and semantics [TRY AGAIN!]"
- Next in thread: Michael Mealling: "Re: New URC Specification is ready...."
- Reply: Michael Mealling: "Re: New URC Specification is ready...."

    Date: 06 Jul 94 11:30:02+0200

    From: pays@faugeres.inria.fr

    To: uri@bunyip.com, ccoprmm@oit.gatech.edu

    Subject: Re: New URC Specification is ready....

    Message-Id: <773487002.23785.0-faugeres.inria.fr*@MHS>

A few unordered comments/questions about the draft (and sorry but I really
feel unhappy with the global specification)

-- PAP

General comments:

- it is an error to merge in a single document encoding and use
- the encoding part though not perfect can be refined and should
remain the core of this document
- the use part must be moved to sone distinct document or at least should
be completely implementation independant

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

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?
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...)

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!

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??????

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

- Next message: Wallace Colyer: "Re: (long) sketch of proposed imap: URL syntax and semantics [TRY AGAIN!]"
- Previous message: John Gardiner Myers: "Re: (long) sketch of proposed imap: URL syntax and semantics [TRY AGAIN!]"
- Next in thread: Michael Mealling: "Re: New URC Specification is ready...."
- Reply: Michael Mealling: "Re: New URC Specification is ready...."