Re: DOI and the non-IETF tree

Ted,

The notion that URI schemes are

>> indicators that tell the recipient how to proceed with processing of 
>> the
>> identifier.

makes perfect sense to me. In olden days I had the simple view that uri 
schemes were reserved for identifiers that had defined over-the-wire 
protocols, but that seems to have withered over time, or maybe it was 
always a misunderstanding.

Anyway, I do have a couple of questions and, since we don't know each 
other and email is hard, I want to point out that they are meant to 
clarify and not provoke:

1. The distinction between IETF and non-IETF source and or continued 
control of a scheme seems reasonable, but what is the advantage of 
building it into the label? That is, what do I know about, say, 
org-doi:10.123/456 that I don't know from doi:10.123/456? (I'm asking 
you to trust me here that there is a useful data model and some 
resolution methods that will make understanding anything about doi 
worthwhile in the construction of clients). So the IANA registry could 
carry this information, as well as pointers to where to look for 
maintenance of the scheme, but why isn't it enough to carry that 
information in that registry?

2. Change control -- the IDF, to be sure, would consider itself the 
authority for making changes in the meaning and use of DOIs and I would 
look to the IETF for information on the details of FTP. But in what 
formal sense does the IETF own change control on FTP? In some ways this 
is a restatement of question 1 -- what useful information on change 
control do I get from the label? Wouldn't I have to always look further?

Thanks.

Larry

On Thursday, September 11, 2003, at 01:46  PM, hardie@qualcomm.com 
wrote:

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

=========================================
Larry Lannom
Corporation for National Research Initiatives (CNRI)
Suite 100, 1895 Preston White Dr, Reston, VA 20191

email:  llannom@cnri.reston.va.us
tel:  703 620 8990

Received on Thursday, 11 September 2003 16:47:21 UTC