Subject: IETF tree URL registration procedure incomplete

From: "Larry Masinter" <[email-masked]>
Date: Wed, 25 Aug 1999 10:43:33 PDT

(Conversation redirected to URLREG):

The recent discussion on the [email-masked]' list about the 'tv' URL
makes me believe that the process described in 
draft-ietf-urlreg-procedures-07.txt for IETF tree documents isn't
adequate to insure proper review of new top level URI schemes, and also
that it assumes more editorial control by IESG of Informational
RFCs than is currently documented by RFC 2026.

As Scott Bradner wrote on the ietf list:

> in the 30 years that the RFC series has run it has always been the case
> that an independent person could get an RFC published if the RFC Editor
> frlt it was a contribution to the Internet community - I think we
> have to think very hard if we want to change this.

In the particular case of "URL schemes", the URI working group
in 1994 and the URLREG group in its many years of existance have
relied on the ability of the IESG (and not merely the RFC editor)
to exert some judgement over URL registrations contained in Informational
RFCs.

In some ways, URL schemes bear some resemblance to top level domains
in their role as a root of a naming authority and in the desire of
some organizations to 'own' the 'short name'; the uproar over a private
use of 'tv' without apparent consensus of the TV community would not be
there if the name of the URL scheme were 'directtv-tune:', as 
draft-ietf-urlreg-procedures-07.txt might propose.

The URL registration procedure document has languished for a while;
the lack of an 'approved' process and guidelines has hampered the
discussion.

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

---

From: "Larry Masinter" <[email-masked]>
Date: Wed, 25 Aug 1999 11:15:16 PDT

The first step in registering a new URL scheme in the IETF tree is
   to publish an IETF Internet-Draft detailing the syntax and
   semantics of the proposed scheme.  The draft must, minimally,
   address all of the items covered by the template provided in section
   6 of this document.

   After all issues raised during a review period of no less than 4
   weeks have been addressed, submit the draft to the IESG for review.

   The IESG will review the proposed new scheme and either refer the
   scheme to a working group (existing or new) or directly present the
   scheme to the IESG for a last call.  In the former case, the working
   group is responsible for submitting a final version of the draft to
   the IESG for approval at such time as it has received adequate
   review and deliberation.

There are a couple of issues that arose with the 'tv' scheme
that bear some elaboration in this procedure:

a) Where does the discussion of the new scheme take place?
b) What is the decision process and authority by which URL schemes
   could be rejected if they don't seem (to some) to meet the
   criteria?
c) are there guidelines or process requirements for "demonstrable utility",
   e.g., existance of independent interoperable implementations, or
   widespread use?
d) Does this process of IESG approval modify the guidelines of
   RFC 2026 for publication of "Informational" RFCs?

---

From: "Larry Masinter" <[email-masked]>
Date: Wed, 25 Aug 1999 11:34:19 PDT

In particular, it has been argued that the IETF process
for publication of Informational RFCs does not require
technical review. In 

http://www.ietf.org/mail-archive/ietf/Current/msg05318.html

Michael Dolan argued, in regard to draft-zigmond-tv-url-02.txt:

"The continued insistence that this draft obtain technical review 
and approval either in or out of IETF is not required under the 
Informational process.  So, there simply is no requirement to change 
the draft technically based on comments here or in W3C or anywhere 
else.  Continued references to current and past mail threads on the 
(lack of) technical merits are just not relevant unless someone can 
explain why this draft requires a special review process."

I think we might want to make sure that 
draft-ietf-urlreg-procedure-07.txt says that the URL review process
is an ongoing activity of the IETF, and any Informational
RFC which purports to register an IETF tree URL is subject
to technical review. It would be useful if the resulting BCP
were listed as "Updates RFC 2026", so that there's no question
about the applicable process.

---

From: "Michael A. Dolan" <[email-masked]>
Date: Wed, 25 Aug 1999 12:02:56 -0700

Larry-

I support your proposal.

In general, clearer process is always good.

And, to the extent that IETF is actually endorsing a document (as is 
implied by it being registered in the IETF tree - does this need 
clarification, too?), then IETF should indeed have great control over 
the content, and provide detailed technical review and approval.  
This could also be done by stating that IETF tree submissions be 
Standards track only, but perhaps that overconstrains your intent 
with that tree.

All this, as long as there is still *some* home for the unreviewed, 
hairbrained, [insert adjective here] schemes.  This seems required in 
light of the URIREG mechanism to permit external entities editorial 
and revision control over schemes registered in the "alternative 
tree", even if they were first reviewed by IETF.

Regards,
	Mike

>about the applicable process.

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

---

From: "Craig A. Finseth" <[email-masked]>
Date: Wed, 25 Aug 1999 15:57:11 -0500 (CDT)

...
	...

This is the first I have heard of any "uproar" over the use of "tv:."
In my experience reviewing this issue, I've only support or
indifference to it.  Never an "uproar."

Now, there have been questions about the RFC _process_, but those have
nothing to do with the technical merits of the issue.

Craig

---

From: "Larry Masinter" <[email-masked]>
Date: Wed, 25 Aug 1999 14:34:09 PDT

> nothing to do with the technical merits of the issue.

Yes, I'm talking about the process. That's why I brought this up
as a discussion point for draft-ietf-urlreg-procedures-07.txt.

Is there a required technical review, even for Informational RFCs,
if they register IETF tree URL schemes?

Larry

---

From: "Larry Masinter" <[email-masked]>
Date: Wed, 25 Aug 1999 15:31:20 PDT

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.

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.

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.

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.

Larry

---

From: "Michael A. Dolan" <[email-masked]>
Date: Wed, 25 Aug 1999 17:14:09 -0700

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

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

>IESG might review the use of 'tv:abc' to reference the US broadcast

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.

>made its way into the documents; this is something that needs

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

>meaning for 'aol:' or use it to define links with their own

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

---

From: "Larry Masinter" <[email-masked]>
Date: Wed, 25 Aug 1999 18:11:26 PDT

> of scope, but still has to be taken in at some level so it can be 

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

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

> 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 

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.

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

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

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

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

> following my algorithm above, it would be impossible to put tv: in an 

I don't think your algorithm makes sense.

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

> 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

---

From: "Michael A. Dolan" <[email-masked]>
Date: Wed, 25 Aug 1999 19:14:26 -0700

>'utility in the context of the Internet'.

There are URI schemes defined and used over systems that are in no 
way related to the Internet.  The system designer has decided that 
the URI syntax is a useful thing - maybe they have a browser in the 
device and it is natural - whatever.  Such schemes still need to be 
documented *somewhere*, and I don't think you want multiple 
authorities for this registration.  This means that IETF may have to 
accept URI submissions that are not intended necesaarily to be used 
over the Internet.  The reason you need a single authority is that 
the device may be requested to support the Internet someday (in 
addition to the private system).  Not that the URI will *ever* be 
used over the Internet, but that the system will need to not have a 
namespace conflict.

An example is dsmcc: as defined by DAVIC.  This should never be used 
on the Internet.  The namespace is highly MPEG transport-specific - 
so much so, that it is time-varying and headend-specific.  It can't 
be used outside the MPEG transport (like on a web page).  But it 
still needs documentation and registration, since the same device 
might very well wish to connect to a system that also understands 
Internet URI's.  It can't then have two definitions for dsmcc:.

URI's are bigger than the Internet.

>some judgement as to where best to approach the process.

I agree there is no harm in the review.  But there is harm in the 
unspecified and ambiguous authority of that review.  I am admittedly 
known to err on the side of more process than less.  But, I think the 
authority of the review needs to be clearer.  Too much personal 
discretion results in these discussion threads.  There is probably a 
happy medium, though.

>it depends on the use.

Yes, but the point is that it is my opinion that IETF should not even 
attempt to address these namespaces in *any* context.

>Are there actually any sites at all that
>URLs for web pages that actually have them?

Yes.  But they may not be generally accessable.  In otherwords, you 
may only have found the page because a reference was placed in the 
Disney broadcast program you are currently watching, as opposed to 
you stumbling on it while browsing.  Just because the page is 
accessable from the Internet, doesn't mean there is no specific 
context for it.

> Do you need to do

Not in the HTTP sense, but implicitly.  See above.

>about scope, but rather some amount of judgement is required.

Yes, I see from your reference on RFC 2301, that our worlds are 
different in the sense that I have anarrower scope of what is 
"Internet" technology.  But that is not the issue.  Whatever the 
scope of IETF, that should be applied to the namespace tree 
selection, whether it is discretionary or not, if the namespace of 
the URI would have been out of scope, then the URI should not be put 
in the IETF tree.  If you are saying that there is no scope, then 
yes, this is not a useful definition.

Somewhat not relevant to this discussion, but if I were RFC Editor 
(everyone's probably pretty glad I'm not ;-), I would have rejected 
the draft for RFC 2301 (with all due respect to Xerox - sorry) as out 
of scope.  In my opinion, this belongs somewhere else, such as NCITS 
L3 (where JPEG lives - ISO/IEC 10918-1 defines JPEG).  Or, maybe at 
W3C, where PNG is defined.  So, why IETF is publishing a graphics 
file format is a bit of a mystery to me and confuses my 
understandiung of scope, but I digress.

>After all, expertise and domain of applicability should be

Probably too much text was snipped or something, but perhaps my 
original comment was not clear.  I was referring to the review level 
being orthogonal to the scheme namespace review.  Thus, one can have 
IETF tree Informational track (as you originally proposed on this 
thread), or alternative tree Standards track, or the other 
combinations.

>of "experts" who are, of necessity, experts in the focused area.

Yes. I am aware of this "brokering" process.  And, I guess I think 
it's bad.  If a standards body doesn't internally have the expertise 
to review and approve something, then it is my opinion, that it 
should not do it.  But we disagree on this, and I am probably in the 
minority.

>...I believe the IESG can ask that the community

Yes.  For good reason.  Despite the best intentions and efforts of 
the chair, it's membership does not represent the TV industry very 
well.

>to come to quite different conclusions.

OK.  But one could explicitly state that the dispute resolution for 
URI's is simply what I said above - you have to submit the 
alternative, and the other one can be superceded.

I'm not sure I like my process though - I think the schemes have to 
be permament registrations.  So, then it has to be done "right" in 
the first place.  Maybe the scheme name can't be a registered 2nd 
level domain name or something?  What do you think?  Obviously a full 
tradename search is not practical.  But reversing a definition would 
be very bad in the event the first submission was an honest mistake.

	Mike