RE: IETF tree URL registration procedure incomplete

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

If something is unrelated to the Internet and there is no need for
an Internet protocol to traffic in names for it, then there is no
need for a URI scheme. Whether a URI scheme is actually needed seems
to be part of the 'utility' constraint, although we probably mean
'utility in the context of the Internet'.

For example, 'draft-antti-telephony-url-09.txt' deals
with URLs for telephone and fax. The telephone network is
not specified in the URL scheme, but merely the mechanism
for addressing it. (You might note, by the way, that 
this draft does a reasonable job of separating the global
addressing scheme from 'local dial strings'. Even though
a local receiver may have a local number interpretation,
the document tries to lay out guidelines for using international
telephone designators whenever possible.)

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

There's never any harm in technical review. So I don't think
we need to constrain the process. The authors should exercise
some judgement as to where best to approach the 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.

I don't know what it means to have a 'scheme that is not a URI'. There
are an enormous number of name and address spaces used in
computer systems, and only some of them really need URI schemes.

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

Whether something is relevent is an extrinsic property, not an
intrinsic one; that is, it doesn't depend on the topic or content,
it depends on the use. Are there actually any sites at all that
serve 'tv' URLs to anyone? If so, could you provide a couple of
URLs for web pages that actually have them? Do you need to do
some kind of content-negotiation to tell the site that you know
how to interpret these URLs?

I think the rest of your message  is based on some presumption
about "scope" that doesn't jive with my world view, so it makes
it hard to discuss. For the most part, there are no strict rules
about scope, but rather some amount of judgement is required.

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

Again: URI schemes are not "out of scope". If you don't need to
name it in an Internet protocol or Web document served on
the Internet then you don't need a URI scheme, you just need
some kind of private designator that you can use however you want.
If you want to name it in the Internet, then the guidelines apply.
The judgement about whether the guidelines have been followed might
require review both by those familiar with the guidelines and those
familiar with the technology that it purports to name.

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

I don't see this clear orthogonality. The issues of whether
the expertise to review exists in the Internet community
seems very much tied to whether Informational ('outside
IETF process') or Standards track ('IETF process') applies.
After all, expertise and domain of applicability should be
highly correlated!

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

I think you're presuming a notion of 'qualified to review'
that isn't quite right. Whether the IESG believes that
it is qualified to insure that a document has received adequate
review from the affected community is a different question than
whether the IESG believes that IESG members themselves understand
the domain well enough to generate the appropriate critique.

In the typical 'last call' mechanism, comments are solicited from
a wide community, and valid technical comments require response,
no matter where they come from. It isn't considered necessary
or appropriate to review the credentials or affiliation of the
sender before dealing with the issue. Now, it might be that someone
in the television community might be more familiar with some technical
issues, and someone from the community of web browser implementors
might be more familiar with others. That's the point of calling
for a "wide review", rather than delegating it to a committee
of "experts" who are, of necessity, experts in the focused area.


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

Again, the question is "is the IETF qualified to insure the
document has had adequate review." Take, for example, the
description of color gamut representation in RFC 2301 (standards
track). I doubt that very many people in the IESG are qualified
to review whether the 'PhotometricInterpretation' range of values
specified there are adequate for commonly transmitted color
documents. On the other hand, it's still a Proposed Standard,
because there was some belief that the affected community
(color fax device manufacturers) participated effectively in
the review.

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

The process involves sufficient judgement at various points by
the organizations and individuals involved (RFC Editor, IESG,
Working Group Chair, Document Editor) that the only clarity
you can get is "who has the authority to decide" and "what
is the appeal process", while everything else turns on guidelines
which are, at best, "Best Current Practice".


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

I don't think your algorithm makes sense.

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

Certainly not. I believe the IESG can ask that the community
affected actually review the document and come to consensus.
Thus, the call to use the 'www-tv' list (which presumably
includes the affected community) to discuss the particular issue
of "URLs for TV". Certainly there was a lot of conversation on
that list a little while ago, which petered out without coming
to any particular conclusion.

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

The guidelines in 2026 are about RFCs in general, and not about
URLs in particular. Now one might infer the latter from the former,
but it's dangerous to do so, since, as we've seen, it's possible
to come to quite different conclusions.

Larry
-- 
http://www.parc.xerox.com/masinter