Re: Criteria for new URL schemes; W3C/IETF cooperation
From: Michael A. Dolan (miked@tbt.com)
Date: Mon, Aug 23 1999
Message-Id: <3.0.5.32.19990823081825.008cc2a0@cts.com>
Date: Mon, 23 Aug 1999 08:18:25 -0700
To: "Larry Masinter" <masinter@parc.xerox.com>
From: "Michael A. Dolan" <miked@tbt.com>
Cc: "Dan Zigmond" <djz@corp.webtv.net>, "Mark Vickers" <mav@liberate.com>, "Philipp Hoschka" <hoschka@w3.org>, "Keith Moore" <moore+iesg@cs.utk.edu>, "Patrik FältströmdHL2bQ==" <paf@swip.net>, <ietf@ietf.org>, <www-tv@w3.org>
Subject: 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