Re: draft-freed-mime-p4-00.txt

> 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