Subject: Re: draft-zigmond-tv-url-02 discussion on [email-masked]

From: "Michael A. Dolan" <[email-masked]>
Date: Sun, 22 Aug 1999 13:59:43 -0700

Larry-

"End run around"?  Why do folks on ietf think this I-D is a 
conspiracy of one kind or another?  If we're not trying to evade W3C, 
then we must be marketing folks looking for some justification of a 
product idea (one person's comment).  Or if not that, then we are an 
evil industry group trying to force their will on IETF (paraphrased 
several other folks' comments).  I wish I could convince you this 
paranoia is unfounded so that we could move past this.

But the real issue here is the review process for Informational 
RFC's, for which there seem to be pretty different opinions.  Here's 
my view based on IETF publications:

The recent thread, "Tighter admission policy for I-Ds", has been very 
interesting.  But Informational submissions are still permitted, and 
there are far, far stranger things published by IETF than this I-D.  
And, it was very clear that there was no concensus on that thread to 
eliminate Informational submissions, or even to significantly alter 
their requirements or review process.  And, even if the concensus was 
drifting towards such changes, the proposals being made have no place 
affecting existing submissions process.

We seem to also keep coming back to the technical merits of the 
submission.  RFC 2026, sections 4.2.2 and 4.2.3 describe the process 
to be used for Informational submissions.  There does not appear to 
be any requirement to obtain technical concensus or approval of the 
group, in fact there are clear statements to the contrary.

The review process does *not* require approval or endorsement of 
outside organizations (such as W3C, etc).  [But FYI, I have been 
working with the WWW-TV chairman on how best to proceed with these 
and other TV related publications, particularly ones where there is 
existing practice; as well as ones that will welcome future open 
technical review.  Some items are likely not appropriate for IETF to 
publish.]

IETF has clearly established itself as the home for URI publication, 
and has re-confirmed this with the recent I-D proposing new processes 
for their submissions.  So, the tv: submission seems completely 
appropriate to make to IETF and is not out of scope.

And, this submission, by IETF's own admission, does not fall into an 
existing WG.  So, by definition, no end-run is occuring here.

And, this submission does not conflict with any existing RFC or draft 
from a WG.

The errors in document format have been acknowledged by the authors, 
and they have agreed to address them.

Given the IETF process for Informational RFC's as it appears to me, 
and the facts above, I would recommend that the authors simply 
resubmit the draft with the documentation changes that were 
suggested, and then if those changes meet the requirements of the 
documentation standards, then the draft continue on its review 
process as provided for in RFC 2026.

If I am mis-reading RFC 2026, then perhaps someone can help me 
understand it better.  Or, if there are undocumented processes that 
have become common practice here, then perhaps someone could 
elaborate on them.  But given the documented review process, I see no 
alternative but for the draft to continue its process within IETF and 
IESG.

Also, just FYI, as to the published television URI requirements, of 
which I have reviewed in detail and in fact added to myself:

	a) It would be impossible to meet all or even most of these with a 
single URI scheme, and this I-D scheme in fact meets at least one 
requirement; and

	b) The extent to which this scheme meets these requirements is 
interesting, but not relevant.  We are trying to publicly document 
current practice as an Informational RFC, for better or worse 
(including how little of the lengthy requirements, if any at all, are 
met).

	Mike

At 08:50 PM 8/21/99 PDT, Larry Masinter wrote:
>There's not been any apparent traffic on this list recently. 
However,
>there's quite a flurry of messages  about the 'tv:' URL
>scheme on the [email-masked] mailing list:
>
>http://www.ietf.org/mail-archive/ietf/Current/maillist.html
>
>The overlap in membership of this list and that one isn't clear;
>is the proposal to publish the 'tv' URL scheme as an RFC
>the result of the discussions of this group or an end-run
>around?
>
>As was pointed out in one message
>(http://www.ietf.org/mail-archive/ietf/Current/msg05155.html),
>
>the draft,
>
>(http://www.ietf.org/internet-drafts/draft-zigmond-tv-url-02.txt)
>doesn't seem to meet the requirements in 
>http://www.w3.org/TV/TVWeb/TVWeb-URI-Requirements.html.
>
>There are various other issues as well, but the procedural
>one is probably the lead.
>
>Larry
>
>
>

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

---

From: Paul Hoffman / IMC <[email-masked]>
Date: Sun, 22 Aug 1999 15:34:44 -0700

>group, in fact there are clear statements to the contrary.

An easy way around the problem for this draft is to have the discussion 
about the merits and demerits of the draft be discussed *off* the IETF 
mailing list by interested parties. You already have a mailing list in 
place for this, which is better than many folks who toss drafts over the 
transom for publication. In the -03 draft, list the subscription 
information for the mailing list, list the archive information 
(<http://lists.w3.org/Archives/Public/www-tv/>), and give people plenty of 
time to discuss the -03 draft. Urge them to read the archive first so they 
know what has already been said.

I see a few possible outcomes of doing this:

- The discussion brings up changes that you agree need to be made to the 
spec. You fix them before submitting it again for publication.

- The discussion convinces you that the spec is indeed broken, but you 
believe that the current (broken) spec is already is in significant use. 
You submit the broken spec with an explicit statement that it is broken and 
is only being published for interoperability purposes, and you start work 
on a new spec with the input from the group.

The IESG can handle either case if you document it well. Be open about what 
suggestions you didn't put in to whatever you submit. This will help them 
decide what they want to suggest to the RFC Editor.

--Paul Hoffman, Director
--Internet Mail Consortium

---

From: Paul Hoffman / IMC <[email-masked]>
Date: Sun, 22 Aug 1999 15:34:44 -0700

--Paul Hoffman, Director

---

From: Harald Tveit Alvestrand <[email-masked]>
Date: Mon, 23 Aug 1999 08:11:58 +0200

At 13:59 22.08.99 -0700, Michael A. Dolan wrote:
>-----BEGIN PGP SIGNED MESSAGE-----
>Hash: SHA1
>
>Larry-
>
>RFC's, for which there seem to be pretty different opinions.

It's not an end run around the RFC publishing process, per se.
It's an end run around the URI registration process.

For several years, the policy of the IETF has been that registration of new 
URI schemes could be done by Informational or standards-track documents, 
but required explicit IESG approval.

This policy was put into place as a "stopgap" until proper procedures (such 
as those the URLREG group has spent several years considering) coud be put 
into place. I know - I was the one suggesting that policy!

I'll ask you for only about the 3rd time:

   Do you have a mailing list where you are happy to discuss the technical
   properties of this URI scheme, and how the draft can be modified so that
   all of us can be less than terribly unhappy with it?

If you're happy with using the WWW TV list, that's OK with me, but I 
haven't seen you say that yet.

                                Harald A

--
Harald Tveit Alvestrand, Maxware, Norway
[email-masked]

---

From: Harald Tveit Alvestrand <[email-masked]>
Date: Mon, 23 Aug 1999 08:11:58 +0200

Harald A

---

From: "Larry Masinter" <[email-masked]>
Date: Mon, 23 Aug 1999 00:51:06 PDT

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

---

From: "Larry Masinter" <[email-masked]>
Date: Mon, 23 Aug 1999 00:51:06 PDT

URL scheme criteria:

Larry

---

From: "Michael A. Dolan" <[email-masked]>
Date: Mon, 23 Aug 1999 08:18:25 -0700

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:
>of repeated advice 
http://lists.w3.org/Archives/Public/uri/1996Nov/0002.html

---

From: "Michael A. Dolan" <[email-masked]>
Date: Mon, 23 Aug 1999 08:18:25 -0700

Mike

---

From: Keith Moore <[email-masked]>
Date: Mon, 23 Aug 1999 11:20:47 -0400

Larry,

I am sympathetic to the arguments that this document not be published.
I am however still hopeful that we can find a better way to move 
forward than to reject it entirely.

However, it would set a bad precedent were IETF (or W3C, or any other 
PSO member) to categorically refuse to publish a document when another 
PSO member had work activity in the same area.  While we all have 
limited resources and it is usually desirable to avoid duplication of
effort, there also needs to be some room for standards-setting 
organizations to compete

We recognize that both W3C and IETF have interests in tv: URLs,
and we want to do the right thing.  The best outcome would be to
reach consensus between all parties, including IETF participants,
W3C, and proponents of the current tv: URL document.  If we cannot
acheive this then (in this case anyway) it is up to IESG and 
the RFC Editor to decide whether and how to publish this document.
As is usual, a decision to publish will be announced on the IETF
mailing list well before actual publication.  If another PSO member 
objects to that decision, then - after the decision is made and
before the document is published - seems like the time to formally 
request that it be taken to the PSO.  

Of course, we hope it doesn't come to that, and we will try to come 
up with a decision that satisfies all parties.

Keith

---

From: Keith Moore <[email-masked]>
Date: Mon, 23 Aug 1999 11:20:47 -0400

Larry,

Keith