Re: DOI and the non-IETF tree

Hi Larry,
	Some responses inline.

At 4:42 PM -0400 09/11/2003, Larry Lannom wrote:
>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.

Other folks on the uri mailing list may want to comment on this; 
there was a distinction
at one point in history between how some folks understood URLs and other forms
of URIs that maps at least broadly to the view above.  That 
understanding evolved
over time, and the current understanding is captured in RFC 3305, 
which describes
the two views as "classical" and "contemporary".

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

I think the idea that it is built into the scheme name is essentially 
because there is no other part
of the identifier's structure that it really could be built into 
without interfering with
the functionality of that part of the structure.  To expand your 
question a bit--what is
the point of building the information into the identifier at all?  My 
personal view is that
it makes it easier to be sure that the protocol processing about to 
be applied to the
identifier is correct.  By associating the scheme name with the 
registry, you help
ensure that the implementors can be confident looking to the registry 
(or registration
tree) for data on the protocol processing.  The registry could run 
the registration
system as a flat namespace, but we've had a fair of amount history tell us that
increases the likelihood of conflict and that the mechanisms for 
resolving those
conflicts get ugly fast.

If we have a registry like:

org-orgname-schemename:

We can punt the question of who owns orgname to someone else pretty easily.  If
we have it as org-schemename and two different orgs conflict over schemename,
we're in charge of the resolution.  We may not be good at that, it 
may take a good
bit of time and effort that we could better spend on things we're better at.

There may be less of a reason to distinguish between:

org-orgname-schemename:

and

sdo-sdoname-schemename:

or

vnd-vendorname-schemename.

I hope we can have a productive further discussion on this point.


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

The IETF has change control over the documents which it publishes.  Where those
documents are protocol specifications, since it can change the 
documents, it can
change its published view of the protocol specification.  Any adherence to the
view published by the IETF is voluntary.
			regards,
				Ted Hardie



>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 17:42:43 UTC