Subject: Fwd: Update: experiences with SOAP media type registration

From: Mark Nottingham <[email-masked]>
Date: Mon, 3 Nov 2003 09:15:06 -0800

I've been asked to forward this to the IETF main list FYI.

Begin forwarded message:

> From: Mark Nottingham <[email-masked]>
> Date: November 2, 2003 5:44:28 PM PST
> To: [email-masked]
> Cc: Xml-Dist-App@W3. Org <[email-masked]>
> Subject: Update: experiences with SOAP media type registration
> Reply-To: [email-masked]
>
> 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).
>
> 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).
>
> 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.
>
> 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.
>
> 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).
>
>
> 1.   
> https://datatracker.ietf.org/public/pidtracker.cgi? 
> command=view_id&dTag=8198&rfc_flag=0
>
>
>
> On Sep 8, 2003, at 2:32 PM, Mark Nottingham wrote:
>
>> [ note that followups are set to public-ietf-w3c only]
>>
>> The XML Protocol Working Group, as part of its work, needs to  
>> register the "application/soap+xml" media type with IANA. Although  
>> this task has been shared by many people, I've been responsible for  
>> driving the actual registration over the last few months. This note  
>> documents my experiences with the registration process, as directed  
>> by an action item given to me by the XML Protocol WG on 03 Sep 2003.
>>
>> Our approach to registration was informed by a number of sources:
>>   1) WG members' previous experiences with media type registration  
>> (myself, Mark Baker, Yves Lafon)
>>   2) RFC2048, Multipurpose Internet Mail Extensions (MIME) Part Four:  
>> Registration Procedures
>>   3) W3C guidelines (although we were not immediately aware of these)
>>   4) Feedback from the IESG (or individuals comprising it or acting  
>> on its behalf) and RFC Editor.
>>
>> Previous experiences were mixed; at times, the RFC Editor and/or IESG  
>> appear to have operated under different procedures. Based on them, we  
>> initially requested that the RFC Editor publish the I-D as an  
>> Informational RFC, believing that any necessary clearance by the IESG  
>> would be gained in due course. This proved not to be the case (see  
>> timeline).
>>
>> RFC2048 is ambiguous from a process standpoint, regarding  
>> registration of IETF-tree media types; it says;
>>
>> [[[
>> 2.3.  Registration Procedure
>>    [...]
>>    For registration in the IETF tree, the normal IETF processes should
>>    be followed, treating posting of an internet-draft and announcement
>>    on the ietf-types list (as described in the next subsection) as a
>>    first step.
>>   [...]
>> 2.3.2.  IESG Approval
>>
>>    Media types registered in the IETF tree must be submitted to the  
>> IESG
>>    for approval.
>>
>> 2.3.3.  IANA Registration
>>
>>    Provided that the media type meets the requirements for media types
>>    and has obtained approval that is necessary, the author may submit
>>    the registration request to the IANA, which will register the media
>>    type and make the media type registration available to the  
>> community.
>> ]]]
>>
>> However, it does not indicate when in relation to RFC publication  
>> IESG approval must be requested, nor does it say how to go about  
>> gaining IESG approval.
>>
>>
>> W3C guidelines <http://www.w3.org/2002/06/registering-mediatype>  
>> don't specify the full process for RFC publication, and advise  
>> pinging the IESG secretary; upon doing so, we encountered problems  
>> (see timeline).
>>
>>
>> * Timeline
>>   17 Jun 2003 - request for publication as an Internet-Draft sent to  
>> internet-drafts (draft had been previously circulated on ietf-types  
>> list, and changes to -03 were only editorial)
>>   18 Jun 2003 - acknowledgement of receipt
>>   09 Jul 2003 - request for publication as an Informational RFC sent  
>> to rfc-editor
>>   10 Jul 2003 - acknowledgement of receipt
>>   21 Aug 2003 - rfc-editor feedback stating that IESG approval must  
>> be requested by the author, and that the document's reference of a  
>> W3C specification may not meet the publication requirement (see  
>> attached)
>>   21 Aug 2003 - query sent to RFC Editor and IESG regarding proper  
>> procedure and appropriate use of references to W3C materials (not  
>> acknowledged or answered as of yet)
>>   29 Aug 2003 - request for last call / approval by the IESG sent to  
>> iesg-secretary
>>   29 Aug 2003 - acknowledgement of receipt
>>   08 Sep 2003 - Statement from [email-masked] that only an AD can  
>> request a Last Call, and that there are procedural issues regarding  
>> this type of publication.  (see attached)
>>
>> In short, the process for non-WG submitted IETF tree media type  
>> registrations is unclear to both the RFC Editor and the IESG  
>> secretary at this time.
>>
>>
>> <draft-baker-soap-media-reg-03>
>>
>> <Re: [iesg-secretary #13379] Last Call for>
>>
>>
>> --
>> Mark Nottingham   Principal Technologist
>> Office of the CTO   BEA Systems
>

---

From: [email-masked]
Date: Mon, 03 Nov 2003 12:03:11 -0800 (PST)

> 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.

> > 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.

> > 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.)

> > 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.

> > to be in more constant contact with the IESG to ascertain the status

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.

> > individual queries to members of the IESG are often not responded to).

This is precisely what the datatracker is for.

				Ned

---

From: Mark Nottingham <[email-masked]>
Date: Mon, 3 Nov 2003 14:13:05 -0800

> were handled "informally" here.

Putting aside the delays, I was specifically referring to:
   - The lack of clarity in the process for registering media types  
leading to ad hoc administration. If draft-freed-mime-p4-04 is adopted,  
this concern will be somewhat mitigated.
   - Your insistence that Harold's note in the datatracker [1] served as  
adequate notice that the draft was rejected, even though he is not the  
responsible A-D, and even though the document was still listed as  
"publication requested."

> This is precisely what the datatracker is for.

And I recommended that the W3C use more direct channels, because it's  
been demonstrated that the datatracker isn't reliable, and you've  
stated that it's the preferred method of communication to draft  
authors.

Regards,

1.  
<https://datatracker.ietf.org/public/pidtracker.cgi? 
command=view_id&dTag=8198&rfc_flag=0> see comment on 9-11-03 (result of  
a POST, so it can't be linked).