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