Re: Comments regarding draft-freed-mime-p4-04.txt

[ned.freed@mrochek.com]

> I have been asked to comment on draft-freed-mime-p4-04 as the person in
> the W3C's XML Protocols Working Group (XMLP) primarily responsible for
> shepherding the registration of the "application/soap+xml" media type.

> First of all, let me say that I believe that the general approach taken
> in draft-freed-mime-p4-04 will greatly assist other, non-IETF standards
> organisations in the registration of their media types.

> However, I do have some concerns with the present draft's lack of
> clarity regarding the timing of such registrations.

I'm afraid almost all of what you're asking for here was very intentionally
omitted from the document.

> In particular, at what point should a standards organisation contact
> the IESG regarding registration?

Given that every standards body has their own set of procedures they follow, I
don't see how this can be specified in any useful way. Nor is it clear to me
that the timing would be the same for all specification within a single
standards body.

The only rule I think makes sense is that registrations have to meet all the
criteria specified in this document, including things like the specification
being available. But I cannot see how reiterating once more that the
registration rules already specified in the document have to be followed in
this case helps in any material way.

> Section 3.1.1 states that
> "Registrations in the standards tree MUST be approved by the IESG and
> MUST correspond to a formal publication by a recognized standards
> body." Does "formal" imply "final" here, or should earlier drafts be
> submitted for feedback?

It is intentionally vague, allowing either. And there's also the ietf-types
that can be used for review prior to asking for registration. Again, I see
little point in reiterating the options open for registration review.

> Also, some indication of how one determines
> what are "recognized standards bod[ies]" would be helpful to those
> unfamiliar with the IETF.

It is up to the IESG to make these determinations. And given that the set
of determinations the IESG has made is currently empty, trying to
write down a set of rules for this is premature at this point.

After there's some experience with the new procedure it probably makes
sense to write something down about this, either in a revision to this
document or in a separate document (which could be an IESG statement
and not an RFC).

> Additionally, some indication of the expected processing time (or,
> ideally, service guarantees) would help other standards organisations
> in planning (especially if the media type registration is required
> before a document can be considered final; this might lead to an
> unfortunate catch-22 situation).

I'm sorry, but I regard such indications as a complete waste of time in the
best case and actively harmful in the worst case. I'd basically be pulling a
number out of the air. It may be right or it may be wrong. And if it is wrong,
there's not much that can be done about it.

I will also point out that past experience with writing down this
sort of thing for other registration processes has not been good.

> The resolution of the issues above, as applied to
> draft-freed-mime-p4-04, would have greatly helped XMLP in its
> registration of "application/soap+xml" (and I hope that it will assist
> us in our future registration(s)).

None of the above issues had anything to do with delays in registration of
application/soap+xml. This particular registration has been delayed because the
document that specified it, draft-baker-soap-media-reg-03.txt, was written to
conform to a tentative registration scheme proposed on a w3c telechat that was
subsequently flatly rejected by the IESG.

As I have explained repeatedly to the various people who asked about this, the
minute the IESG rejected this approach this draft became a nonstarter. At that
point there were two paths forward: (1) Wait for the rules to change and for
the draft to become superfluous or (2) Rewrite the draft to follow the old
rules and include a registration form. The fact that no new draft ever appeared 
was an implicit acknowledgment that the first course of action was the one
being followed.

You will also find notes to this effect in the public datatracker made some
time back. I do note that the document wasn't marked "revised ID needed, which
it should have been, so I just corrected that.

> While reviewing the draft, I also noticed that in Section 3.5,
> "index.html" is not necessary, and implies (to many people) a specific
> format and (to many Web servers) a particular implementation.
> Considering the likely longevity of this as an RFC, I'd suggest
> "http://www.iana.org/assignments/media-types/";.

Fair enough, I'll remove the index.html from the URL in the next
revision. This actually pointed out to me that the change from using the
isi.edu domain and ftp: URLs to the iana.org domain and http: URLs wasn't
noted in the revision history, and I just corrected that as well.

				Ned