I've been asked to forward this to the IETF main list FYI.
This has been discussed extensively in private email. I'm therefore hesitant to
respond since it is all too likely we've reached the point of diminishing
returns. However, there are a number of inaccuracies and overgeneralizations
here that I cannot let stand.
> From: Mark Nottingham <mark(_dot_)nottingham(_at_)bea(_dot_)com>
> Date: November 2, 2003 5:44:28 PM PST
> To: public-ietf-w3c(_at_)w3(_dot_)org
> Cc: Xml-Dist-App(_at_)W3(_dot_) Org <xml-dist-app(_at_)w3(_dot_)org>
> Subject: Update: experiences with SOAP media type registration
> Reply-To: public-ietf-w3c(_at_)w3(_dot_)org
>
> Since sending the message below, the IESG considered and rejected the
> registration of the application/soap+xml media type, apparently
> because the draft did not actually contain its registration (instead,
> it referenced the registration in the SOAP specifications), and
> because it referenced works in progress (e.g., the SOAP 1.2
> specifications, which were not REC at the time).
More specifically, media type registrations in the *IETF* tree currently
require publication of an RFC containing the registration template.
Registrations in other trees do not impose this requirement.
I mention this because people registering media types often seem unaware of the
existance of registration options besides the IETF tree.
> Unfortunately, the IESG did not notify the authors of the
> Internet-Draft of the decision made by e-mail; Ned Freed has said that
> the rejection was communicated to people "on the W3C concalls," but
> this information didn't filter down to the WG. (If anyone has
> information about this, please contact me; we still need to resolve
> the registration of application/soap+xml).
I first note in passsing that all of the feedback regarding this document
occurred before the formal request for publication.
Second, I have explained repeatedly that there are two possible approaches
that can be taken from here:
(1) Change the registration document to include the necessary template.
(2) Wait for the changes proposed in draft-freed-mime-p4-04.txt to go
into effect, in which case theory says no RFC will be required for
this registration. (Of course this presupposes that the procedural
change is approved. I know of no reason why it shouldn't be, but even so
it should be kept in mind that the remaining process isn't a rubber stamp.)
> A note was placed in the IESG's Web datatracker[1], but this was a
> comment from another IESG member about the shortcomings of the Draft,
> not an actual decision regarding the status of the Draft, which was
> only updated after Ned discovered the omission and changed the
> document's status. No e-mail notification of any of this (except as
> below) has been received by the Draft's authors.
Email notification of changes is a datatracker feature we've always wanted and
planned for. However, it has only recently been implemented. (Much as we'd like
to have everything we want and need right when we want and need it, there are
operational and implementation realities that have to be taken into account.)
And of course it also requires that appropriate email addresses be entered in
the state change notice field in order to be effective. The newness of this
feature necessarily means that older documents may not have had appropriate
email addresses set, and that in turn may mean the necessary information to
send notices didn't exist.
This particular document didn't have appropriate email addresses set. This is
the first time this omission has been brought to my attention. Now that it has
been I have added the author's email addresses from the draft to the state
change notice field.
In the future documents that are added should have the state change notice
field set to whatever addresses appear in the draft, so this should no
longer be a problem.
> I (and therefore the WG) only found out about this because of e-mail
> discussion following from comments I made to regarding
> draft-freed-mime-p4-04; if I had not made those comments, I'm
> reasonably certain we still wouldn't know the status of the I-D.
> I'd also note that the IESG appears to administer its responsibilities
> in a more informal fashion than the W3C does (e.g., the Draft wasn't
> added to the datatracker until September 11, e-mailing the authors of
> a Draft about its status isn't seen as necessary, and it's thought
> adequate notification of a problem when an IESG member comments
> without changing a Draft's status). As a result, it may be necessary
> to be in more constant contact with the IESG to ascertain the status
> of a particular Draft.
The normal way this is done per RFC 2048 is for the document to the submitted
directly to the IESG. Submitting a document this way brings it to the attention
of the secretariat and causes it to be added to the next IESG agenda for
assignment to an appropriate area director.
As it happens I was out on sick leave throughout this time so I can only
reconstruct what happened in this case from your records and from what I see in
the datatracker. (My being out on sick leave also probably contributed to some
of the delays that were experienced.)
Rather than contact the IESG, as RFC 2048 calls for, you elected instead to
present the document to the RFC editor. The RFC Editor responded and directed
you to the IESG for approval. You then followed up with the IESG. However, you
appear to have done this at the worst time possible: 21-Aug-2003, the day of an
IESG meeting. This meant that the best case time for consideration of this
document would have been the 4-Sep-2003 call. For whatever reason the
document didn't make the agenda for this call, but it was on the next one,
and prior to that the document was added to the datatracker.
In any case, aside from some delays I see no indication that things
were handled "informally" here.
> My recommendation to future W3C WGs that need to register media types
> would be to co-ordinate with the W3C liaison to get a periodic update
> of their Drafts' status from the IESG (anecdotal evidence shows that
> individual queries to members of the IESG are often not responded to).
This is precisely what the datatracker is for.
Ned