Subject: Re: draft-freed-mime-p4-00.txt
From: Joseph Reagle <[email-masked]>
To: John C Klensin <[email-masked]>, Chris Lilley <[email-masked]>, "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>
Cc: "[email-masked]" <[email-masked]>, Dan Kohn <[email-masked]>, "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>
Date: Wed, 26 Feb 2003 19:45:29 -0500
List-Id: <ietf-xml-mime.imc.org>

On Wednesday 26 February 2003 19:11, John C Klensin wrote:
> Joseph,
>
> For whatever it is worth, a registration in the "no prefix" (IETF) tree
> _is_ an endorsement.  I think it would be quite unfortunate to lose that.

If this is the case, perhaps the text should be changed to read:

   3.2.8 Publication Requirements
   Other than /-IETF-/ registrations in the standards tree, the registration
   of a data type does not imply endorsement, approval, or
   recommendation by the IANA or the IETF or even certification that the
   specification is adequate. 

> As a general observation, we need to be careful to not overgeneralize
> from the W3C experience and relationships.  There _is_ a special
> relationship between W3C and IETF, including the regular coordination
> efforts.   If we need to reflect that relationship in registration
> procedures as a special case (I hope that isn't necessary, but am still
> trying to think the comments through), then we should do that, probably
> in a separate document.  This one also has to cover organizations and
> relationships that, bluntly, we may trust less than we trust the W3C.

However, I'm not advocating the proposal above, it's only closer to what you 
seem to be suggesting. While I appreciate the special relationship between 
the IETF and W3C, it *is* possible to conceive that a media type definition 
from some other standards group (including the W3C) in the "no prefix" tree 
might have something in it that the IETF doesn't exactly agree with. While 
the IETF might trust the W3C enough to invite it to exist in the "no 
prefix" tree, I would not presume that means the IETF "endorses" every 
registration of the W3C, only that it probably won't screw up too bad (from 
the IETF point of view <grin/>) and if there is an issue we can work 
together to resolve it.

Regardless, this isn't a biggie, it just seems simpler to me to not look for 
"endorsements" in the tree in any case, but instead look at the 
status/level and quality of the spec, and if the IETF and W3C are 
comfortable sitting next to each other on a branch, that's that. <smile/>

Date: Wed, 26 Feb 2003 23:00:16 +0100
From: Chris Lilley <[email-masked]>
Reply-To: Chris Lilley <[email-masked]>
Organization: W3C
To: [email-masked]
CC: Joseph Reagle <[email-masked]>, [email-masked], [email-masked], Dan Kohn <[email-masked]>, <[email-masked]>, <[email-masked]>, <[email-masked]>
Subject: Re: draft-freed-mime-p4-00.txt
Sender: [email-masked]

On Wednesday, February 26, 2003, 8:42:20 PM, ned+xml-mime wrote:

> Joseph Reagle wrote:
>> Please note that that document provides guidance for registration in the
>> present (interim) context of RFC2048 -- not necessarily the policy when
>> draft-freed-mime-p4-00.txt would be operational. For instance, it's not
>> clear to me that we would still have to generate even "stub" ietf-drafts
>> once it is operational. I nope that sending emails to the various lists
>> with a reference to the W3C document will be sufficient.

nxmmc> Actually, it should be quite clear that this will no longer be
nxmmc> necessary.

Re-reading this, I agree that the statement is not entirely clear and
could use some editing to convey what Ned confirms is the intended
meaning.

"The normal IETF processes should be followed for all registrations in
the standards tree, with the posting of an internet-draft being a
necessary first step. "

That could clearly be misinterpreted that an I-D is necesasary in all
cases, even though it says should not SHOUL

"Proposed registrations in the standards tree by other standards
bodies should be communicated to the IESG (at [email-masked]). "

This is clear and leads me to believe that rewording the first
statement as

"The normal IETF processes should be followed for all registrations in
the IETF tree, with the posting of an internet-draft being a
necessary first step. "

would convey the intended meaning. It looks like a simple editorial
oversight in the generalization from 'IETF' to 'standards'.

-- 
 Chris                            mailto:[email-masked]

From: Joseph Reagle <[email-masked]>
Organization: W3C
To: Chris Lilley <[email-masked]>, [email-masked], [email-masked]
Subject: Re: draft-freed-mime-p4-00.txt
Date: Wed, 26 Feb 2003 16:56:54 -0500
Cc: [email-masked], [email-masked], Dan Kohn <[email-masked]>, <[email-masked]>, <[email-masked]>, <[email-masked]>
Sender: [email-masked]

On Wednesday 26 February 2003 16:41, Chris Lilley wrote:
> nxmmc> The IETF has this concept of recommending something in an RFC.
> nxmmc> I think that's close enough to an endorsement that I don't want
> nxmmc> to say the IETF never endorses anything.
>
> This is well put. Equally, W3C has a concept of recommending something
> and indeed our full standards track documents are called
> Recommendations to emphasise this.
>
> Perhaps Joseph is saying that an implied disclaimer of 'anything not
> in the IETF tree may be inadequate' does not add anything and is
> harmful, just as the W3C saying 'anything in the IETF tree is not a
> W3C Rec and might not be any good' would be harmful.

I don't disagree with this, but it was not quite my point. To me it seemed 
that the statement was not needed because nothing in the IANA registry need 
necessarily be seen as an endorsement. It's simpler for me to see the 
registry as a location for a non-colliding token with reference to a 
definition: a registration request or specification. If you want to know 
the endorsement associated with the definition, go read that. There you can 
see if it's a vendor registration request, an InfoRFC, Proposed Standard, 
Standard, Candidate REC, REC, obsoleted, deprecated, etc.

Date: Wed, 26 Feb 2003 22:41:58 +0100
From: Chris Lilley <[email-masked]>
Reply-To: Chris Lilley <[email-masked]>
Organization: W3C
To: [email-masked], [email-masked]
CC: Joseph Reagle <[email-masked]>, [email-masked], [email-masked], Dan Kohn <[email-masked]>, <[email-masked]>, <[email-masked]>, <[email-masked]>
Subject: Re: draft-freed-mime-p4-00.txt
Sender: [email-masked]

On Wednesday, February 26, 2003, 8:42:20 PM, ned+xml-mime wrote:

> Joseph Reagle wrote:
>> On Wednesday 26 February 2003 12:54, Dan Kohn wrote:
>> > This looks very good.  It still might be useful to provide a little more
>> > of the information from
>> > <http://www.w3.org/2002/06/registering-mediatype> to give hints to other
>> > standards bodies about the ordering of their draft, to publishing an
>> > I-D, [snip]

>> For instance, it's not clear to me that we would still have to
>> generate even "stub" ietf-drafts once it is operational. I nope
>> that sending emails to the various lists with a reference to the
>> W3C document will be sufficient.

nxmmc> Actually, it should be quite clear that this will no longer be
nxmmc> necessary.

Great.

>>    3.2.8 Publication Requirements
>>    Other than IETF registrations in the standards tree, the registration
>>    of a data type does not imply endorsement, approval, or
>>    recommendation by the IANA or the IETF or even certification that the
>>    specification is adequate.

>> jmr: Could this be simplified by saying that, "presense in the standards
>> tree does not necessary imply endorsement by IANA or IETF." One should not
>> look at the tree for endorsement at all, but, at the specification's
>> level/maturity (draft, proposed draft, standard, Recommendation, etc.)
>> within their organization.

nxmmc> The IETF has this concept of recommending something in an RFC.
nxmmc> I think that's close enough to an endorsement that I don't want
nxmmc> to say the IETF never endorses anything.

This is well put. Equally, W3C has a concept of recommending something
and indeed our full standards track documents are called
Recommendations to emphasise this.

Perhaps Joseph is saying that an implied disclaimer of 'anything not
in the IETF tree may be inadequate' does not add anything and is
harmful, just as the W3C saying 'anything in the IETF tree is not a
W3C Rec and might not be any good' would be harmful.

-- 
 Chris                            mailto:[email-masked]

Date: Wed, 26 Feb 2003 12:14:51 -0800 (PST)
From: [email-masked]
Subject: Re: draft-freed-mime-p4-00.txt
To: Dan Kohn <[email-masked]>
Cc: [email-masked], [email-masked], [email-masked], [email-masked], [email-masked]
Sender: [email-masked]

> http://www.ietf.org/internet-drafts/draft-freed-mime-p4-00.txt

> This looks very good.  It still might be useful to provide a little more
> of the information from
> <http://www.w3.org/2002/06/registering-mediatype> to give hints to other
> standards bodies about the ordering of their draft, to publishing an
> I-D, to last calls, to their publication, to informational RFC
> publication.  I believe this caused some confusion with the W3C until it
> was worked out, and informatively referencing the W3C process might even
> be useful.

I actually this it is sort of the other way around -- this procedure needs to
be updated to reflect the new draft. I don't see anything in the W3C procedure
that really belongs in registration procedure and which isn't already there.

> Also, RFC 3023 updated RFC 2048.  Could you please reference RFC 3023
> and explicitly mention the prohibition from RFC 3023 that, "media
> subtypes that do not represent XML MIME entities MUST NOT be allowed to
> register with a '+xml' suffix".

Good idea. Added.

> You might reference this whole paragraph from section 7 of RFC 3023:

>    [T]hose registering [XML] media types SHOULD use the '+xml'
>    convention unless they have a particularly compelling reason not
> to....
>    The registrar for the IETF tree will encourage new XML-
>    based media type registrations in the IETF tree to follow this
>    guideline.  Registrars for other trees SHOULD follow this convention
>    in order to ensure maximum interoperability of their XML-based
>    documents.  Similarly, media subtypes that do not represent XML MIME
>    entities MUST NOT be allowed to register with a '+xml' suffix.

Rather than reiterall the rules for XML media type registration I've
added a section that refers to RFC 3023.

				Ned

From: Joseph Reagle <[email-masked]>
Organization: W3C
To: [email-masked]
Subject: Re: draft-freed-mime-p4-00.txt
Date: Wed, 26 Feb 2003 15:02:41 -0500
Cc: [email-masked], [email-masked], Dan Kohn <[email-masked]>, [email-masked], [email-masked], [email-masked]
Sender: [email-masked]

On Wednesday 26 February 2003 14:42, [email-masked] wrote:
> > Please note that that document provides guidance for registration in
> > the present (interim) context of RFC2048 -- not necessarily the policy
> > when draft-freed-mime-p4-00.txt would be operational. For instance,
> > it's not clear to me that we would still have to generate even "stub"
> > ietf-drafts once it is operational. I nope that sending emails to the
> > various lists with a reference to the W3C document will be sufficient.
>
> Actually, it should be quite clear that this will no longer be
> necessary.

It's clear that an RFC track is no longer REQUIRED for the IESG to direct 
IANA to create an entry for the standards tree. But it's not clear how one 
asks, absent the RFC, the IESG to take the action. Once the new policy is 
in place I will want to provide some very simple, walk-me-through-it, steps 
for the W3C of how one goes about getting the IESG to take the action.

From: John Cowan <[email-masked]>
Subject: Re: draft-freed-mime-p4-00.txt
To: [email-masked] (Joseph Reagle)
Date: Wed, 26 Feb 2003 14:46:31 -0500 (EST)
Cc: [email-masked], [email-masked], [email-masked] (Dan Kohn), [email-masked], [email-masked], [email-masked]
Sender: [email-masked]

Joseph Reagle scripsit:

> I just noted and read this and had a few small comments:

An even smaller one.  In 3.1.5:

#    From time to time and as required by the community, the IANA may,
#   with the advice and consent of the IESG, create new top-level
#   registration trees.

It's "by and with the advice and consent", i.e. by the advice and with the
consent.  This phrase is very old; in the U.S. Constitution the President
makes treaties "b. and w. the a. and c. of the Senate", and in the
U.K. and the Dominions, laws are enacted "by the Queen's most Excellent
Majesty, b. and w. the A.  and C. of the Lords Spiritual and Temporal,
and Commons, in this present Parliament assembled", and have been since
at least 1689 (the English Bill of Rights) and probably much longer.

-- 
John Cowan  [email-masked]  www.ccil.org/~cowan  www.reutershealth.com
"If I have seen farther than others, it is because I was standing on
the shoulders of giants."
        --Isaac Newton

Date: Wed, 26 Feb 2003 11:42:20 -0800 (PST)
From: [email-masked]
Subject: Re: draft-freed-mime-p4-00.txt
To: Joseph Reagle <[email-masked]>
Cc: [email-masked], [email-masked], Dan Kohn <[email-masked]>, [email-masked], [email-masked], [email-masked]
Sender: [email-masked]

> On Wednesday 26 February 2003 12:54, Dan Kohn wrote:
> > This looks very good.  It still might be useful to provide a little more
> > of the information from
> > <http://www.w3.org/2002/06/registering-mediatype> to give hints to other
> > standards bodies about the ordering of their draft, to publishing an
> > I-D, to last calls, to their publication, to informational RFC
> > publication.  I believe this caused some confusion with the W3C until it
> > was worked out, and informatively referencing the W3C process might even
> > be useful.

> Please note that that document provides guidance for registration in the
> present (interim) context of RFC2048 -- not necessarily the policy when
> draft-freed-mime-p4-00.txt would be operational. For instance, it's not
> clear to me that we would still have to generate even "stub" ietf-drafts
> once it is operational. I nope that sending emails to the various lists
> with a reference to the W3C document will be sufficient.

Actually, it should be quite clear that this will no longer be
necessary.

> > http://www.ietf.org/internet-drafts/draft-freed-mime-p4-00.txt

> I just noted and read this and had a few small comments:

>    3.2.8 Publication Requirements
>    Other than IETF registrations in the standards tree, the registration
>    of a data type does not imply endorsement, approval, or
>    recommendation by the IANA or the IETF or even certification that the
>    specification is adequate.

> jmr: Could this be simplified by saying that, "presense in the standards
> tree does not necessary imply endorsement by IANA or IETF." One should not
> look at the tree for endorsement at all, but, at the specification's
> level/maturity (draft, proposed draft, standard, Recommendation, etc.)
> within their organization.

The IETF has this concept of recommending something in an RFC. I think that's
close enough to an endorsement that I don't want to say the IETF never
endorses anything.

>    3.2.8 ... The stanards
>    3.3.3 ... whateveer

>    4.1.3 Publication Requirements
>    All access types MUST be described by an RFC.

> To be clear, IETF is reserving transfer encodings and access types to its
> own process and are not forseen to be developed by other standards
> organizations? (I don't forsee it being otherwise, just wanted to be sure.)

Yes, that's indeed the case.

				Ned

From: Joseph Reagle <[email-masked]>
Organization: W3C
To: <[email-masked]>, <[email-masked]>, "Dan Kohn" <[email-masked]>
Subject: Re: draft-freed-mime-p4-00.txt
Date: Wed, 26 Feb 2003 14:19:39 -0500
Cc: <[email-masked]>, <[email-masked]>, [email-masked]
Sender: [email-masked]

On Wednesday 26 February 2003 12:54, Dan Kohn wrote:
> This looks very good.  It still might be useful to provide a little more
> of the information from
> <http://www.w3.org/2002/06/registering-mediatype> to give hints to other
> standards bodies about the ordering of their draft, to publishing an
> I-D, to last calls, to their publication, to informational RFC
> publication.  I believe this caused some confusion with the W3C until it
> was worked out, and informatively referencing the W3C process might even
> be useful.

Please note that that document provides guidance for registration in the 
present (interim) context of RFC2048 -- not necessarily the policy when 
draft-freed-mime-p4-00.txt would be operational. For instance, it's not 
clear to me that we would still have to generate even "stub" ietf-drafts 
once it is operational. I nope that sending emails to the various lists 
with a reference to the W3C document will be sufficient.

> http://www.ietf.org/internet-drafts/draft-freed-mime-p4-00.txt

I just noted and read this and had a few small comments:

   3.2.8 Publication Requirements
   Other than IETF registrations in the standards tree, the registration
   of a data type does not imply endorsement, approval, or
   recommendation by the IANA or the IETF or even certification that the
   specification is adequate. 

jmr: Could this be simplified by saying that, "presense in the standards 
tree does not necessary imply endorsement by IANA or IETF." One should not 
look at the tree for endorsement at all, but, at the specification's 
level/maturity (draft, proposed draft, standard, Recommendation, etc.) 
within their organization.

   3.2.8 ... The stanards 
   3.3.3 ... whateveer

   4.1.3 Publication Requirements
   All access types MUST be described by an RFC.  

To be clear, IETF is reserving transfer encodings and access types to its 
own process and are not forseen to be developed by other standards 
organizations? (I don't forsee it being otherwise, just wanted to be sure.)

Content-Class: urn:content-classes:message
Subject: draft-freed-mime-p4-00.txt
Date: Wed, 26 Feb 2003 09:54:17 -0800
Importance: normal
From: "Dan Kohn" <[email-masked]>
To: <[email-masked]>, <[email-masked]>
Cc: <[email-masked]>, <[email-masked]>, <[email-masked]>
Sender: [email-masked]

http://www.ietf.org/internet-drafts/draft-freed-mime-p4-00.txt

This looks very good.  It still might be useful to provide a little more
of the information from
<http://www.w3.org/2002/06/registering-mediatype> to give hints to other
standards bodies about the ordering of their draft, to publishing an
I-D, to last calls, to their publication, to informational RFC
publication.  I believe this caused some confusion with the W3C until it
was worked out, and informatively referencing the W3C process might even
be useful.

Also, RFC 3023 updated RFC 2048.  Could you please reference RFC 3023
and explicitly mention the prohibition from RFC 3023 that, "media
subtypes that do not represent XML MIME entities MUST NOT be allowed to
register with a '+xml' suffix".  

You might reference this whole paragraph from section 7 of RFC 3023:

   [T]hose registering [XML] media types SHOULD use the '+xml'
   convention unless they have a particularly compelling reason not
to....
   The registrar for the IETF tree will encourage new XML-
   based media type registrations in the IETF tree to follow this
   guideline.  Registrars for other trees SHOULD follow this convention
   in order to ensure maximum interoperability of their XML-based
   documents.  Similarly, media subtypes that do not represent XML MIME
   entities MUST NOT be allowed to register with a '+xml' suffix.

          - dan
--
Dan Kohn <mailto:[email-masked]>
<http://www.dankohn.com/>  <tel:+1-650-327-2600>