RE: IETF tree URL registration procedure incomplete

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

At 06:11 PM 8/25/99 PDT, Larry Masinter wrote:
>
>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'.

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.

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

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

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
>serve 'tv' URLs to anyone? If so, could you provide a couple of
>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
>some kind of content-negotiation to tell the site that you know
>how to interpret these URLs?

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

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

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.

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

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.

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

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

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

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

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

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

iQA/AwUBN8SjASl9dIG/haQGEQLIDQCgmFeBZQSMPgAh3gLsukekwo15nhYAn2mJ
ZfGcAUB8BhfHHGEy2aY60UrZ
=mG88
-----END PGP SIGNATURE-----

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