RE: IETF tree URL registration procedure incomplete

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Larry-

I haven't been involved at all in the URLREG development, so these 
comments may be out of whack, but since you cc'd me, here's my 
thoughts....

At 03:31 PM 8/25/99 PDT, Larry Masinter wrote:
>I thought the general idea for allowing "Informational" documents
>to describe IETF tree URLs is that the IESG might approve of
>the URL as a naming mechanism, even if the thing named were not
>itself Standards track. The technical review of "aol:" would not
>review the AOL service or its use of keywords, but would review
>the use of the 'aol' URL scheme against URL guidelines.

I agree with the above.  I think the namespace review and the scheme 
review should probably be pretty orthogonal decisions.

As you note above, there are 3 review levels possible for a URI 
scheme submission.  These are:

	1. general editorial review (RFC 2026 compliance, including general 
readability and document quality)

	2. general URI technical design guidelines (RFC 1738 compliance, but 
still editorial in nature)

	3. technical review of the scheme's syntax and semantics within its 
usage context

I think Informational is (1) and (2).  Standard is also (3).  What's 
funny about URI's compared to other submissions is that in non-URI 
submissions, if the technology is out of scope to IETF, then the 
draft is rejected.  In contrast, a URI scheme description can be out 
of scope, but still has to be taken in at some level so it can be 
registered.

And, orthogonal to the above review levels is the scheme namespace 
review, which I presume always requires review by IESG, if only to 
assign it to the proper tree.  Presumably this is done early in the 
process, since where it is assigned in the tree may affect the rest 
of the scheme review process?

I'm not sure what decision mechanism was envisioned for the IETF and 
alternative trees, but one simple management scheme is that the 
alternative tree is for schemes that, if they were not URI's, would 
have been rejected as out of scope for IETF publication of any kind.

For example, if I wanted to document the television feed namespace 
alone as an RFC (hbo, kpbs, etc), I would expect IETF to reject the 
draft as not relevant to the Internet (as they should, in my 
opinion).  Conversely, since I *must* register tv: (which uses that 
namespace) with IETF, it is automatically in the alternative tree 
(since it's namespace documentation alone would have been rejected as 
out of scope).

This is independent of the decision of what review level to make 
(whether it is Informational or Standards track).

Also, one problem with a level 3 review (in any tree) is that it 
presumes IETF is qualified to do it.  Is this test applied now?  For 
non-URI submissions, I think it is - if the draft is out of scope of 
"the Internet", then it is rejected.  (Yes, this does not entirely 
address W3C-related items, but lets ignore that for now).

The presumption for level 3 review is that IETF indeed has the 
expertise to review it.  If it doesn't, it shouldn't try.

Of course, this all may not be what you had in mind for the trees, 
but it is one possible process to apply, and hopefully help reach a 
clear process of some kind.

>In this case, IESG would not review how televisions were tuned
>and whether PIP and 'channel return' were useful concepts, but the
>IESG might review the use of 'tv:abc' to reference the US broadcast
>stream.

Not sure I agree here, regardless of what tree it is in (although 
following my algorithm above, it would be impossible to put tv: in an 
IETF tree).

Is there really anyone in IESG that can (or should) address the 
television namespace?  My opinion is no.  (But if you disagree, then 
we can pick an arbitrary obscure technology for the example, and/or I 
will explain why the tv namespace problem is even _more_ complex than 
some have pointed out in the ietf and www-tv lists).  All IESG can 
really effectively do in this case is decide what tree to put it in 
and perform a level 1 and 2 review.

>I believe we've meant this in discussions, as evidenced from
>the discussion on this topic over the last 5 years, but it hasn't
>made its way into the documents; this is something that needs
>to be corrected.

The more you can document the process, the fewer lengthy debates will 
occur on it (or maybe not, but the more easily those debates can be 
ignored ;-).

>In general, when an Informational RFC calls for some kind
>of action on the part of IANA, there is necessarily a review
>according to the rules of the IANA space being modified.
>Perhaps we don't need to make a specific exception to RFC 2026.
>
>We probably will need to deal with dispute resolution as well,
>if, say, some Big Web Site Owner wants to define some alternative
>meaning for 'aol:' or use it to define links with their own
>referents.

Won't RFC 2026 be sufficient for the appeal process of URI's, too?  
All schemes must be in the form of a draft, and any dispute could 
come in the form of a new draft submission.  Thus, it will bubble up 
to IESG on "conflict with other RFC's" guideline.

Well....hope this was helpful somewhat.

	Mike

-----BEGIN PGP SIGNATURE-----
Version: PGP for Personal Privacy 5.0
Charset: noconv

iQA/AwUBN8SG0Cl9dIG/haQGEQK3KQCg2C6KsZY+MMsYf5I4zvjI7EuWjlAAnj0V
JHyFUUQiGPzZ49LUNNfk9cpE
=2ePf
-----END PGP SIGNATURE-----

------------------------------------------------------
Michael A. Dolan, Representing DIRECTV,  (619)445-9070   
PO Box 1673 Alpine, CA 91903        FAX: (619)445-6122