Subject: A core issue (was RE: imparting clues to the trade press)

From: Ian King <[email-masked]>
Date: Fri, 27 Aug 1999 00:14:49 -0700

But there is a key issue here, which IS about Dan's paper.  (John, I think
I'm mostly agreeing with you here, actually.  :-) 

The underlying issue is the "registration" of a "URL scheme".  The Working
Group 
which I have co-chaired has worked hard and long to taxonomize and document
process (we really didn't create a whole lot, to be honest) to manage the
namespace of URL schemes.  A lot of very intelligent and conscientious
people have contributed to that work.  To be frank, I wouldn't know if this
sort of namespace has been in use in the broadcast industry for the last ten
thousand years.  But I do know that the introduction of a new URL scheme
into the Internet Architecture is a Big Deal for those who produce
interoperable implementations in that domain, and I took on the work of
URLREG because I agreed with the underlying charter from the IESG: we needed
to find some way to bring order to and minimize confusion in that process --
the whole point of a "standards" body.  

Perhaps what we've found is that the definition of "Informational" in RFC
2026 needs to be updated; perhaps what we're saying is that the language of
draft-ietf-urlreg-procedures-07.txt needs to be tightened up regarding
Informational RFCs and URL schemes.  But the spirit of all of this is:
should we, the Internet community, review and exercise critical judgement
upon new URL schemes within the Internet Architecture?  What I've been
hearing over the last three years of chairing the URLREG group is: hell, yes
-- let's figure out how.  :-)  What I've been reading recently is that some
people think that draft-zigmond-tv-url-02.txt shouldn't be subject to such
critique.  And that just doesn't make any sense to me.   

In other words: I think this IS about Dan's paper, AND the *purpose* of an
RFC.  This draft purports to define and register a URL scheme for use on the
Internet, and it does not comply with the (draft) process for same.  Without
process (arguendo, the drafts having not yet reached RFC status), how can
one say it meets a standard, ANY standard?  Assuming the draft process, it
does not meet that standard (and the community is obviously willing to
provide input and feedback).  And if it doesn't apply to the Internet, this
entire discussion is moot -- it should not be a matter of concern to the
Internet community, nor the subject of our standards documents.  

I've read other drafts that purported to propose URL schemes, and they made
NO sense within the context of the Internet.  I won't go anywhere near that
far about Dan's draft, but I must concur with several others that it does
not meet the process standards we worked for three years to eludicate, which
standards I believe are reasonable and useful to the Internet as a whole.  

John, you're right: the RFC "rubber stamp" is too powerful to wield without
much thought and consideration -- isk 

Ian King <[email-masked]>
Speech Product Group
MICROSOFT CORPORATION

-----Original Message-----
From: John W. Noerenberg [mailto:[email-masked]]
Sent: Thursday, August 26, 1999 8:09 PM
To: Keith Moore
Cc: [email-masked]; 'Keith Moore'; 'Gunnar Lindberg';
[email-masked]; [email-masked]
Subject: Re: imparting clues to the trade press

At 9:30 PM -0400 8/26/99, Keith Moore wrote:
> > It seems to me that four years additional experience ought to tell us
>> confusion over the meaning of an RFC label isn't growing any less.
>
>no, but it's not necessarily getting any worse either.

If it was getting worse, would you look more kindly on changing our
practice?

>
>> It reduces the time spent in debates over
>> paper's like Dan Zigmond's
>
>no it doesn't.   ANY publication by IETF of this document in its
>current form would be inappropriate.  The issue here is not one of
>document labelling,  the issue is whether IETF will publish,
>and effectively register (bypassing its established procedure),
>a specification for a tv: URL that is known to have severe deficiencies.

But Dan's paper doesn't claim to be a specification.  It says quite 
clearly it is a description of current practice.  I don't know Dan, 
but based on what I find in the document, there is no attempt to 
deceive anyone into thinking he was proposing his description as a 
standard specification.  What alarmed me is the response by people 
claiming to speak for their organization and apparently unfamiliar 
with IETF practice endorsing the paper as a specification for their 
industry.  The only destination for this paper beyond an I-D is as an 
Informational RFC.  Regardless of the immediate suitability of Dan's 
paper as an RFC, I find the consequences of it becoming *any* RFC 
distasteful (Dan, this is no reflection on what you've written) in 
light of other's misinterpretation.

This is not about Dan's paper, it's about the meaning of "RFC".

Consider the power of the label.

AltaVista found 1463 web pages mentioning RFC822 since the beginning 
of this year.  There were 4 references to STD11.  This is the *same* 
document!  (Ok, I didn't count the reference to dance studio STD11 at 
Danceworks.com...)  References to *any*  IETF BCP was listed on only 
311 pages.  Keith, you are absolutely right, an RFC label is a 
powerful instrument.  Granting it to a document must be carefully 
weighed.   I deeply respect the work you and all the members of the 
IESG do in judging the crushing weight of documents that cross your 
desk.

But work such as Dan's -- properly done -- or perhaps the 
hypothetical paper described by Rahmat M. Samik-Ibrahim, deserves a 
place in the pantheon of IETF documents.  They deserve respect as 
informational documents.  They must not be subject to the misuse, 
inadvertent or otherwise, promised by the behavior of those endorsing 
draft-zigmond-tv-url-02.

john noerenberg
[email-masked]
   ----------------------------------------------------------------------
   The man that can most truly be accounted brave is he who best
   knows the meaning of what is sweet in life and what is terrible,
   and then goes out undeterred to meet what is to come.
   -- Pericles, "Funeral Oration", 479 B.C.
   ----------------------------------------------------------------------