Comments on Hansen draft (2717/18-bis-03)

Hi All:

Sorry to be tardy with this feedback, but hope it's still timely. Some
detailed comments on the new Hansen (2717/18-bis-03) draft listed below. On
a big issue front, I assume that the intent of the revised guidelines is to
maintain a partitioning of URI space into permanent / provisional /
historical. I think the draft would better reflect that by reordering
sections 3 (provisional), 4 (historical), 5 (permananet). The order seems
jumbled to me. I would imagine a more logical order could be

	3 (was 5 - permananet)
	4 (was 3 - provisional)
	5 (was 4 - historical)

This reflects better the relative importances of each tier. (Of course, the
order could be reversed, to go from minor to major, although I think that's
less helpful.) I do think that sect 5 should be renamed from

	"URI Scheme Registration Procedure"
to
	"Guidelines for Permananet URI Scheme Registration"

which would balance better with the other two sections. Otherwise seems
we're back in the trees, with one true path and a couple boxes for the
bozos.

Also (discussed in detail below) but the idea that schemes can be removed
from the 'permanent' allocation makes me decidedly queasy. If that's the
case, then are we really using the right word in 'permanent'?

Cheers,

Tony
 

###

#1 - Sect. 1, 1st para

"for considerations by those who are defining" - shouldn't that be singular
("consideration")?

#2 - Sect. 1, 2nd para

"RFCs 2717 and 2718 draw a distinction" - might that better be "drew" since
this document is just about to obsolete those RFCs?

#3 - Sect 2.1, 1st para, 1st sentence

"Because URI schemes are a single, global namespace,..."

Suggest "comprise" or constitute" would be a better word than "are"

"...the unbounded registration of new schemes is harmful to the Internet
community."

Suggest "may be" instead of "is". I don't think it can be demonstrated or
proved to have a deleterious effect.

#4 - Sect 2.2, 2nd para, 2nd sentence

"However, if there is a strong reason for a URI scheme to not use the
hierarchical syntax, thgen the new scheme definition should at least follow
the syntax of previously registered schemes, if possible."

Whoa! What does this mean? That new URI schemes do not have to conform to
the generic syntax?? Does this not conflict with the previous para? And the
"if possible" is very weak.

#5 - Sect 2.2, 3rd para, 2nd sentence

The word "artistic" is gratuitous. Suggest it be removed.

#6 - Sect 2.3, 1st para, 2nd sentence

"describe how the resource indicated can be identified by software that
obtains a URI of that scheme"

Don't understand this. I thought the precise function of a URI was to
_identify_ a resource. That is software that has acquired a URI has already
acquired the resource identifier.

#7 - Sect 2.4, 1st para, 1st sentence

"In addition to the definition of how a URI identifies a resource"

Is this not both misleading and redundant? A URI _is_ a resource identifier
in and of itself. How can there be any further definition?

#8 - Sect 2.4, 1st para, 2nd sentence

"A basis for this model was HTTP;"

Should this be something like "The customary model for this practice is
HTTP;"

#9 - Sect 2.4, 1st para, 2nd sentence

"a HTTP resource"

Suggest "an" instead of "a"

#10 - Sect 2.6, 2nd para & Sect 3, last but one bullet point

Why are permanent security considerations referecing RFC 3986 (7), while
provisional registrations referencing RFC 2434 (6)?

#11 - Sect 2.7, last para, 2nd sentence

"com-example-info". Heh, heh! Very droll. ;) I do think it would be better
not to use an existing URI scheme application but to use something a tad
more neutral, e.g. "com-example-test".

#12 - Sect 3, 1st para, 2nd bullet

"(Modification of a registration entry to note multiple uses of the same
scheme name requires IESG approval.)"

Can't say that I really approve of that - "multiple uses of the same scheme
name".

#13 - Sect 5.2, 1st para, 4th bullet

"To facilitate review,"

Surely more acxcruate is "To enable review,".

#14 - Sect 5.2, 1st para, 5th bullet

"Allow for at least 2 weeks"

Not that I would want in any way to impede the approval process (althoug
real world examples would seem to indicate that aproval is not such a
frantic effort), but I would have thought 4 weeks is a better review time
period to give any interested parties who may be busy travelling or on
vacation a reasonable review window.

#15 - Sect 5.2, 2nd para, 4th bullet

"add the registration"

Should be "adds the registration" (plural). Also, is only one "Designated
Expert" to be expected. In fact, why not even just replace this with "Expert
Review" - the language used in 3rd and 5th bullets?

#16 - Sect 5.3, 4th para

"Transition to or from 'permanent' status"

Can that be for real? That 'permanent' does not mean 'permanent' but only
'permanent for now'. In fact, I'm not really convinced by trhe 'historical'
category. What purpose does it really serve apart from a place to park some
superannuated schemes. If one can transition (whether it be at the behest of
the IESG) from 'permanent' to other status, then I think we have the wrong
term here.

#17 - Sect 6, 1st para, last sentence

"with an initial (optional) mailing review"

Any chance of spelling out the mailing list in this document. (Assuming we
might even get some agreement on what it would be.;)

###


Tony Hammond

New Technology, Nature Publishing Group
4 Crinan Street, London N1 9XW, UK 

tel:+44-20-7843-4659
mailto:t.hammond@nature.com

********************************************************************************   
DISCLAIMER: This e-mail is confidential and should not be used by anyone who is
not the original intended recipient. If you have received this e-mail in error
please inform the sender and delete it from your mailbox or any other storage
mechanism. Neither Macmillan Publishers Limited nor any of its agents accept
liability for any statements made which are clearly the sender's own and not
expressly made on behalf of Macmillan Publishers Limited or one of its agents.
Please note that neither Macmillan Publishers Limited nor any of its agents
accept any responsibility for viruses that may be contained in this e-mail or
its attachments and it is your responsibility to scan the e-mail and 
attachments (if any). No contracts may be concluded on behalf of Macmillan 
Publishers Limited or its agents by means of e-mail communication. Macmillan 
Publishers Limited Registered in England and Wales with registered number 785998 
Registered Office Brunel Road, Houndmills, Basingstoke RG21 6XS   
********************************************************************************

Received on Tuesday, 8 March 2005 12:05:53 UTC