Review of URL syntax

Larry Masinter | 25 Aug 1999 19:43

Picon

IETF tree URL registration procedure incomplete

(Conversation redirected to URLREG):

The recent discussion on the 'ietf <at> ietf.org' 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;

(Continue reading)

Craig A. Finseth | 25 Aug 1999 22:57

Re: IETF tree URL registration procedure incomplete

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

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

Larry Masinter | 25 Aug 1999 23:34

Picon

RE: IETF tree URL registration procedure incomplete

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

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

Larry Masinter | 25 Aug 1999 20:15

Picon

RE: IETF tree URL registration procedure incomplete


   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?

(Continue reading)

Michael A. Dolan | 25 Aug 1999 21:02

RE: IETF tree URL registration procedure incomplete

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

At 11:34 AM 8/25/99 PDT, Larry Masinter wrote:
>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

(Continue reading)

Michael A. Dolan | 26 Aug 1999 02:14

RE: IETF tree URL registration procedure incomplete

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

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

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

(Continue reading)

Michael A. Dolan | 26 Aug 1999 04:14

RE: IETF tree URL registration procedure incomplete

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

(Continue reading)

Larry Masinter | 26 Aug 1999 03:11

Picon

RE: IETF tree URL registration procedure incomplete

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

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

> 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

(Continue reading)

Dan Zigmond | 26 Aug 1999 01:14

RE: IETF tree URL registration procedure incomplete

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

I know Larry's email isn't attempting to provide a thorough summary of our
"tv:" draft, but I feel that there's a misconception here that our draft
somehow gives American broadcasters unfair rights in the "tv:" namespace.
This is not the case.  What the draft actually says in section 3.3 on
network identifiers is: 

   "The current practice is simply to
   compare network identifiers against a list of those known to be
   available on the receiver." 

In other words, in the US "tv:abc" is likely to tune you to the local
affiliate of the American Broadcasting Company, while on a receiver in
Australia "tv:abc" will take you to the Australian Broadcast Corporation.
The only registrar in this draft is the receiver itself, so it's local
rather than global.

Granted, this behavior is exactly what some people object to in the draft.
But that's not the same as (and, in fact, it's exactly the opposite of)
somehow rewarding the global identifier "tv:abc" to the entity that happens
to use the "ABC" abbreviation in the US.

	Dan

---------------------------------------------------
Dan Zigmond
Senior Manager, Broadcast Applications

(Continue reading)

Michael A. Dolan | 26 Aug 1999 02:49

RE: IETF tree URL registration procedure incomplete


Larry-

Your points are well-taken.   But...

Where it *does* work is when the page with the tv: reference in it 
will be broadcast and not available on a globally accessible web 
server.  It thus implicitly contains the context of the channel on 
which it is broadcast, which is a local context to the receiver.  So, 
when watching the Disney channel, Disney will be able to put "tv:abc" 
in one of the broadcast web pages, and the tune event that that URI 
permits will in fact do the "right" thing.  It is in fact good that 
it is somewhat non-specific (and perhaps thus not a URL).  In 
contrast, they can't put in tv:7 at the studio, since it would surely 
do the wrong thing more than 50% of the time, since ABC is not always 
on channel 7.

We've had this discussion before, and I'm not sure Dan and Mark would 
agree with me, but in my view, for network feeds it is a URN.  The 
resolution to a specific transport and channel occurs within the 
receiver.  "abc" is translated locally to a transport (DIRECTV or 
NTSC for example) and channel to the best (or possibly multiple) ABC 
network feeds which is OK.  The receiver knows how to do this.

Disney feeds sent to Australia would not contain "tv:abc" (unless of 
course they meant to get the Australian Broadcasting Company).

And, within intranets, or any locally scoped network where the TV 
space is well known, you can in fact put "click here tv:7 to see the 
president's speech" and it too will do the right thing.

(Continue reading)

Larry Masinter | 26 Aug 1999 03:18

Picon

RE: IETF tree URL registration procedure incomplete

> Where it *does* work is when the page with the tv: reference in it 
> will be broadcast and not available on a globally accessible web 
> server.  It thus implicitly contains the context of the channel on 
> which it is broadcast, which is a local context to the receiver.  So, 
> when watching the Disney channel, Disney will be able to put "tv:abc" 
> in one of the broadcast web pages, and the tune event that that URI 
> permits will in fact do the "right" thing. 

Are you saying that no one in Australia can ever watch the Disney
channel? If the 'right' thing is to tune to the American Broadcast
Company channel?

> It is in fact good that 
> it is somewhat non-specific (and perhaps thus not a URL).  In 
> contrast, they can't put in tv:7 at the studio, since it would surely 
> do the wrong thing more than 50% of the time, since ABC is not always 
> on channel 7.

And the American Broadcast Company is not always on 'tv:abc'.

> We've had this discussion before, and I'm not sure Dan and Mark would 
> agree with me, but in my view, for network feeds it is a URN. 

Let's not go there.

> The 
> resolution to a specific transport and channel occurs within the 
> receiver.  "abc" is translated locally to a transport (DIRECTV or 
> NTSC for example) and channel to the best (or possibly multiple) ABC 
> network feeds which is OK.  The receiver knows how to do this.

(Continue reading)

Larry Masinter | 26 Aug 1999 02:01

Picon

RE: IETF tree URL registration procedure incomplete

> I know Larry's email isn't attempting to provide a thorough summary of our
> "tv:" draft, but I feel that there's a misconception here that our draft
> somehow gives American broadcasters unfair rights in the "tv:" namespace.
> This is not the case.  What the draft actually says in section 3.3 on
> network identifiers is: 
> 
>    "The current practice is simply to
>    compare network identifiers against a list of those known to be
>    available on the receiver." 
> 
> In other words, in the US "tv:abc" is likely to tune you to the local
> affiliate of the American Broadcasting Company, while on a receiver in
> Australia "tv:abc" will take you to the Australian Broadcast Corporation.
> The only registrar in this draft is the receiver itself, so it's local
> rather than global.
> 
> Granted, this behavior is exactly what some people object to in the draft.
> But that's not the same as (and, in fact, it's exactly the opposite of)
> somehow rewarding the global identifier "tv:abc" to the entity that happens
> to use the "ABC" abbreviation in the US.

But there's a difference between the situation with 'news:' (where
there really is a global name space of netnews groups), and 'file:'
(where the reference is in practice always to some local resource),
and relative URLs (where the sender has some way of setting or
inferring what the BASE is for the relative URL provided.)

In the case of 'tv:abc' in any kind of Internet content, the
sender has no way of knowing anything about the receiver's mapping
of network identifiers to channels. In this case (unlike all of

(Continue reading)

Larry Masinter | 26 Aug 1999 00:31

Picon

RE: IETF tree URL registration procedure incomplete

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

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

(Continue reading)

Ian King | 25 Aug 1999 20:12

Picon

RE: IETF tree URL registration procedure incomplete

FYI: I have exchanged mail with Patrik Falstrom, the AD over URLREG, as
recently as this week, and the URLREG docs are being moved forward, albeit
not as swiftly as we might like.  The next hurdle for them is to be
re-reviewed by the Security ADs; they objected to the section on how URL
Security Considerations should be written, and I amended the procedures doc
per their recommendation, resulting in -07.  I believe that the drafts will
then be forwarded to the RFC Editor; I will continue to monitor this to
ensure that this happens, or that any other issues are promptly dealt with.

However, Larry, you raise another point: you express skepticism regarding
the process for review of Informational RFCs that describe URL schemes.  The
procedures draft specifically states that all proposed URL schemes shall be
reviewed by IESG; this was a piece of "buy-in" that we actively sought from
the Area Directors at URLREG meetings.  Reading your email as a whole, I
think you are suggesting that this won't be truly effective until these
drafts have become RFCs and are useful tools for the IESG -- if I'm not
reading you right, please correct me and we should discuss it further.  

PS: I'm holding off on asking for IESG last call on the vnd.* tree draft
(draft-king-vnd-urlscheme-01.txt) until after the URLREG docs are on their
way; as it is, the two URLREG docs were dependent on each other and the URI
drafts, and I don't think it serves anyone to create another layer of
dependency at this time.    But I'm hoping the existence of that RFC will
provide a viable and attractive alternative in situations such as tv:.  

Cheers -- Ian 

Ian King <iking <at> microsoft.com>
Speech Product Group
MICROSOFT CORPORATION

(Continue reading)

Larry Masinter | 25 Aug 1999 20:34

Picon

RE: IETF tree URL registration procedure incomplete

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.

Return

Return to gmane.ietf.url.

Search Archive

Language

Change language

Options

Current view: Threads only / Showing only 20 lines / Not hiding cited text.
Change to All messages, whole messages, or hide cited text.

Post a message
NNTP Newsgroup
Classic Gmane web interface
XML

XML

RSS Feed
List Information

About Gmane