Re: Criteria for new URL schemes; W3C/IETF cooperation

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

1. The applicability of RFC 1738 to URI scheme review _process_ today 
is questionable:

	a. RFC 2396 updates RFC 1738, and specifically states in section 1 
that the URI process of 1738 will be updated, thus implying that RFC 
1738 will be obsoleted in this area.  Presumably this update is draft-
ietf-urlreg-urlreg-procedures-07.  So, I do not see how you can 
reference both of these documents concurrently.  Either RFC 1738 
process applies, or the new draft process applies, not both.

	b. RFC 1738 predates RFC 2026.  If some (such as URI) draft's were 
meant to be reviewed differently, then RFC 2026 would surely have 
stated that, if even in a general nature.  It does not.

	c. RFC 1738 makes no distinction at all between the requirements for 
a Standards Track scheme and an Informational scheme.  While we would 
probably interpret this omission differently, it certainly begs the 
question.  How can one *ever* submit an Informational track draft 
without being in conflict with this RFC?

2. The tv: draft does in fact, meet the technical standards of RFC 
1738.  While the quality of this meeting is perhaps debatable, it in 
no way violates the syntax described in RFC 1738.  And, it is indeed 
unusual in its use relative to other schemes.  But assertions that 
the scheme is not useful or operable are unfounded and in fact there 
is proof to the contrary due to its existing use.

3. The suggestions that URI drafts be subject to the draft URIREG 
process is not reasonable for the reasons I've previously stated:

	a. the URIREG draft has not been approved,

	b. there is no procedure setup in IETF yet to follow,

	c. the real implications of a document published under the "IETF" 
tree 
versus the "alternative" tree is not clear, and

	d. it seems a bit unfair to impose a new process mid-stream on a 
draft first submitted in 1997.

I am not criticising this new draft registration process.  It in fact 
sounds very reasonable.  But I am pointing out that it is not ready 
for deployment yet.

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

5. The MOU with W3C is apparently still a draft, so is of 
questionable formal applicability.  However, it is common and prudent 
practice anyway, which I would certainly agree with.  However:

	a. W3C is *not* the home of television standards development.  ATSC 
(in the US) and EBU/DVB (in Europe).  So, I would vigorously argue 
against any assertion that W3C represents the interests of the 
television community.

	b. W3C is *not* the primary home of URI's.  IETF is.  The fact that 
there may be overlap in the development of some past and future URI 
schemes is fine, and cooperation should definitely be done.  But just 
because it is a URI, does not make it W3C's purvue.  Further, if for 
some reason it is argued that it is, see (4) above.

The fact that W3C has a public interest group (not a sponsored 
working group, BTW) with a charter to discuss television-related 
topics, is merely interesting.  Further, while the membership of the 
interest group is open, publications at W3C are not.  And, this 
author is not permitted to publish anything at W3C since it requires 
corporate membership to do so (and DIRECTV is not a member).

I again recommend to the authors that they make the documentation 
changes only, and submit it for continued processing per RFC 2026.  
Further technical review, in or out of IETF, is just not relevant.

Work in process on other television schemes under development is 
outside the scope of this process discussion, but is certainly 
welcomed in both IETF and W3C upon formal submission of something to 
review.  We hope everyone will contribute as vigorously to 
development of the new schemes as they have to their review and 
comment of this one.

How can we bring closure to this process discussion?  RFC Editor?

	Mike

At 12:51 AM 8/23/99 PDT, Larry Masinter wrote:
>URL scheme criteria:
>
>The criteria and process for new URL schemes was set in RFC 1738,
>section 4, "Registration of New Schemes". While URLREG has 
elaborated
>those in draft-ietf-urlreg-guide-05.txt and
>draft-ietf-urlreg-urlreg-procedures-07.txt, the original requirement
>that "URL schemes must have a demonstratable [sic] utility and 
operability"
>still applies. Publication of draft-zigmond-tv-url-02.txt would
>constitute registration of the "tv" URL scheme, in the face of the
>numerous questions about its utility (and actual deployment) and
>documented problems with its operability.
>
>It would be reasonable to reject publication of this document as an
>"Informational" RFC merely on the grounds that doesn't meet the
>criteria and procedures established for new URL schemes; it doesn't
>meet the general criteria in RFC 1738 and it doesn't meet the 
criteria
>for URLs in the IETF tree as elaborated in
>draft-ietf-urlreg-guide-05.txt.
>
>(It's unclear that additional 'technical discussion' after three 
years
>of repeated advice 
http://lists.w3.org/Archives/Public/uri/1996Nov/0002.html 
>would cause the document to change in a useful way.)
>
>-----------------------------------
>IETF process:
>
>RFC 2026 (The Internet Standards Process) must be viewed in light of
>more recent activities, and, in particular, IETF's joining with W3C
>and other organizations to coordinate development of Internet
>Standards. The IETF and W3C both signed draft-ietf-poission-pso-mou-
01.txt.
>It calls for the organizations to work out processes for 
coordination.
>
>In areas that are within the scope of both IETF and W3C or in areas
>that are primarily covered by W3C activities, the need to coordinate
>activities should modify the process in RFC 2026.
>
>URL scheme registrations fall in the overlap of IETF and W3C
>interests; extensions of web-related protocols to support the TV
>domain is currently primarily a W3C activity.
>
>Despite the lack of explicit guidance in RFC 2026 on additional
>process steps necessary to insure coordination, the IETF has, and
>should continue, to take inter-organization cooperation into account
>when considering its actions.
>
>It is in the spirit of the MOU to at least consider whether a
>particular proposal (be it an IETF RFC or a W3C recommendation or
>note) represents the attempt of a member company or partipant to
>bypass the process or technical criteria of one organization by use 
of
>the other organization's standards development process.
>
>>From the W3C description of the activity (http://www.w3.org/TV/), 
it
>is clear that the development of a "tv" URL scheme is specifically 
in
>the charter of that activity
>(http://www.w3.org/TV/tvweb-ig-charter#xtocid47112), along with an
>established process of that group to review those schemes and
>collectively submit them to the IETF.
>
>>From the IETF side, it seems important not to interfere with the 
W3C
>process that was established to review TV URLs. The W3C group's
>charter says they will review the various proposals and then submit
>their documents to the IETF. Premature publication would be 
subverting
>the W3C activity.
>
>>From the W3C side, the attempt to publish draft-zigmond-tv-url-
02.txt
>as an Informational RFC in the IETF doesn't seem to be consistent 
with
>the agreed charter of the W3C TV Interest Group, of which the 
document
>authors are, I believe, assigned as individual participants.
>
>As the W3C Process document says:
>
>"Every effort must be made for open communication and cooperation
>between W3C and the IETF so that, for example, two versions of a
>specification do not evolve independently as a result of separate
>work. Such fragmentation thwarts the principle of interoperability 
so
>vital to W3C success."
>
>It would be unreasonable for IETF and W3C to create separate "tv" 
URL
>specifications. Since this is a chartered W3C activity, it should be
>allowed to proceed without premature publication by the IETF of a
>flawed specification.
>
>Larry
>-- 
>http://www.parc.xerox.com/masinter
>
>
-----BEGIN PGP SIGNATURE-----
Version: PGP for Personal Privacy 5.0
Charset: noconv

iQA/AwUBN8FmQCl9dIG/haQGEQI25QCg/l5Wk99D6EmnLxEx8n5pfSCaKt8AoN+A
YNSKPf8s90FjD0KLJy2tQx/B
=oqDX
-----END PGP SIGNATURE-----

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

Received on Monday, 23 August 1999 11:22:03 UTC