RE: DOI and the non-IETF tree

Norman,
	Thanks for your comments.  I'd like to pull one thing out
here as critical for me:


At 11:54 AM +0100 09/11/2003, Paskin, Norman (DOI-ELS) wrote:
><enormous snip>
>The phrase 'non-IETF tree' had a different connotation for me and some IDF
>colleagues, i.e. "not arising out of an IETF WG". Indeed, DOI did not go
>through an IETF WG:  but we brought it to the IETF because we agree that
>there should be a central place for URI registration.  Larry M. made an
>excellent case for putting Engineering in IETF reviews and as noted earlier
>we will respond to that. But I'd like to note that if the vnd- scheme (even
>if renamed as a recent suggestion) continues (as it looks now) to carry a
>connotation of lightweight, second-class citizen status, we feel that
>doesn't meet our needs.

I think "non-IETF tree" has a different meaning either than "not arising out
of an IETF WG" or "second-class citizen".  I think of URI schemes as
indicators that tell the recipient how to proceed with processing of the
identifier.  This is is easiest to see with schemes like HTTP: or FTP: where
different protocols and different protocol processing are invoked according
to the scheme, but it is true as well for things like cid: which may appear
in multiple contexts.  For me, then, the division between the IETF 
and other trees
indicates whether or not the IETF maintains sufficient documentation (and
in some cases change control) for an implementor to look to the IETF to
understand the protocol processing indicated by the scheme.

I see IANA registration of non-IETF schemes as very valuable because it gives
an indication of whom to talk to for information on protocol processing
if it is *not* the IETF.  The conversation I hope we can move to is how to
structure the trees so that the registration and later lookup carry enough
information so that implementors can easily understood to whom they
need to turn for information and what that likely relationship will be.
Larry's update of the King draft uses some of the trees that MIME used;
this is handy for the IETF because we understand them.  But if they do
not suffice to meet the needs of those creating those schemes, then we can
expand them or adjust them.  We might, for example, adopt trees that
use short hand versions based on how change control in protocol processing
is done (e.g. "proprietary (the registrant has change control)" or 
"membership (a group
of members that you might join has change control)").  We might also not
need that level of hierarchy at all (as in the recent suggestion to 
use orgname-schemename).

The key values here are ensuring that the same scheme name is not 
adopted by multiple
organizations with dissimilar protocol processing expected and 
indicating to whom
to turn for indications on protocol processing for the scheme.  I 
remain hopefully
that we can accomplish that and I encourage you to continue to work with Larry
and the URI mailing list members to further those goals.
				best regards,
					Ted Hardie

Received on Thursday, 11 September 2003 13:47:15 UTC