Subject: Re: [dispatch] draft-bakker-sipping-3gpp-ims-xml-body-handling-07

From: John-Luc Bakker <[email-masked]>
Date: Thu, 7 Jun 2012 19:53:30 +0000

Hi Gonzalo,

Thanks for reviewing and pointing out the approach. 

The draft proposes two new content disposition types, applicable to the MIME type registered here "http://www.iana.org/assignments/media-types/application/3gpp-ims+xml".
The MIME type was first agreed and mentioned in 3GPP documents on or before February 2002.

The XML contents associated with the MIME type is used by different UAs in the IMS (as pointed out in the draft), for different purposes. Only late 2007 it was spotted that undesirable behavior may be caused when incompatible content disposition types are used. At that time it was found undesirable to introduce new mime types; those parts of the 3GPP documents were seen as "stable" and changing the parts would cause backwards incompatibility with UAs conforming to the 3GPP specifications.

Summarizing, this draft seeks to "reserve" two content disposition types for a content type used by "applications that use the 3GPP IM CN Subsystem as defined by 3GPP (literally copied from the IANA registrar for this MIME type: "http://www.iana.org/assignments/media-types/application/3gpp-ims+xml")". Yes, multiple MIME types have been considered but 3GPP participants could not agree that approach.

Kind regards,

	John-Luc

-----Original Message-----
From: Gonzalo Camarillo [mailto:[email-masked]] 
Sent: Wednesday, May 30, 2012 3:19 AM
To: John-Luc Bakker
Cc: [email-masked]
Subject: Re: [dispatch] draft-bakker-sipping-3gpp-ims-xml-body-handling-07

Hi John Luc,

an additional clarifying question on this draft. What the draft proposes to do with three new disposition types, could also be done with three different media types, which could be registered in the vendor tree. In fact, all registrations under Meredith expect the one related to this draft are in the vendor tree:

http://www.iana.org/assignments/media-types/application/index.html

Registering media types in the vendor tree is straight forward:

http://tools.ietf.org/html/rfc4288#section-3.2

Have you considered such an approach at all?

Thanks,

Gonzalo

On 28/05/2012 1:45 PM, Gonzalo Camarillo wrote:
> Hi John Luc,
> 
> checking the history of this draft, there were some discussions around 
> a late IPR disclosure some time ago:
> 
> http://www.ietf.org/mail-archive/web/ietf/current/msg59428.html
> 
> Was there any conclusion?
> 
> Thanks,
> 
> Gonzalo
> 
> On 16/05/2012 1:37 AM, John-Luc Bakker wrote:
>> Hi,
>>
>> Thanks for reviewing the draft.
>> Please see inline.
>>
>> Kind regards,
>>
>>         John-Luc
>>
>> -----Original Message-----
>> From: Gonzalo Camarillo [mailto:[email-masked]]
>> Sent: Wednesday, April 18, 2012 6:08 AM
>> To: John-Luc Bakker
>> Cc: Paul Kyzivat; [email-masked]
>> Subject: Re: draft-bakker-sipping-3gpp-ims-xml-body-handling-07
>>
>> Hi John Luc,
>>
>> it is important that the DISPATCH community understands how you would like to progress this draft so that they provide their input. Per RFC 2183, the registration of disposition types requires a Standards Track or an IESG-Approved Experimental RFC:
>>
>> http://www.iana.org/assignments/mail-cont-disp/mail-cont-disp.xml#mai
>> l-cont-disp-1
>>
>> You draft seems to aim to become an Experimental RFC, right?
>>
>> JL: Yes, that is the intention.
>>
>> I guess the reasons for this RFC to be Experimental are given in 
>> Section
>> 1 of the draft, right?
>>
>> http://tools.ietf.org/html/draft-bakker-sipping-3gpp-ims-xml-body-han
>> dling-08#section-1
>>
>> JL: Yes.
>>
>> I assume you considered Section 8 of RFC 5621 when deciding disposition types were the right tool for what you need to do:
>>
>> http://www.iana.org/assignments/media-types/application/3gpp-ims+xml
>>
>> JL: Yes. And in addition, the ' 3GPP IM CN Subsystem XML body' has been around longer than RF 5621.
>>
>> Thanks,
>>
>> Gonzalo
>>
>>
>> On 09/04/2012 5:47 PM, John-Luc Bakker wrote:
>>> Dear Paul, Gonzalo,
>>>
>>> I received an editorial comment on this draft. The draft is referring to sections 2.2, 2.3 and 2.1. These references should have been 4.2.1, 4.2.2 and 4.2.3.
>>>
>>> Have you had an oppertunity to further digest the draft in light of our previous offline discussion?
>>>
>>> Kind regards,
>>>
>>>       John-Luc
>>>
>>> -----Original Message-----
>>> From: John-Luc Bakker
>>> Sent: Tuesday, March 27, 2012 12:37 PM
>>> To: Paul Kyzivat; [email-masked]
>>> Cc: [email-masked]
>>> Subject: draft-bakker-sipping-3gpp-ims-xml-body-handling-07 (was: RE:
>>> [dispatch] I-D Action:
>>> draft-bakker-sipping-3gpp-ims-xml-body-handling-07.txt)
>>>
>>> Dear all,
>>>
>>> I have just made revision 8 of draft-bakker-sipping-3gpp-ims-xml-body-handling available following offline discussion. Biggest addition is the new section 2.1 which aims to further motivate the need for the ID.
>>>
>>> You can find the HTML formatted version here:
>>> http://tools.ietf.org/html/draft-bakker-sipping-3gpp-ims-xml-body-ha
>>> nd
>>> ling-08
>>>
>>> I am looking forward to hearing about any concerns you may have.
>>>
>>> Kind regards,
>>>
>>> John-Luc
>>>
>>> -----Original Message-----
>>> From: [email-masked] [mailto:[email-masked]] 
>>> On Behalf Of John-Luc Bakker
>>> Sent: Tuesday, March 20, 2012 1:53 PM
>>> To: Paul Kyzivat; [email-masked]
>>> Cc: [email-masked]; sipping
>>> Subject: Re: [dispatch] I-D Action:
>>> draft-bakker-sipping-3gpp-ims-xml-body-handling-07.txt
>>>
>>> Hi,
>>>
>>> Thanks, Paul for reviewing the draft.
>>> Appologies for having delayed this response.
>>>
>>> Let me address first the question about this being a SIPPING draft: I intend to ask Gonzallo to sponsor this draft. To collect any further comments and ensure visibility (sine the sipping list is obsolete), I have copied the DISPATCH list.
>>>
>>> See also inline with <JL>.
>>>
>>> -----Original Message-----
>>> From: Paul Kyzivat [mailto:[email-masked]]
>>> Sent: Saturday, December 03, 2011 12:11 PM
>>> To: John-Luc Bakker
>>> Cc: sipping
>>> Subject: Re: I-D Action:
>>> draft-bakker-sipping-3gpp-ims-xml-body-handling-07.txt
>>>
>>> I'm commenting on this on the (now obsolete) sipping list because 
>>> this has sipping in its name. This may not be the best place. I 
>>> suppose an alternative is rai.
>>>
>>> ISTM that there are three degrees of freedom here for identifying 
>>> how to process these bodies:
>>> - content-disposition
>>> - content-type
>>> - the actual content of the body
>>>
>>> Of these, the content-disposition is the most heavy weight in terms 
>>> of mechanism, while the actual content of the body is the least heavy-weight.
>>>
>>> So, I wonder why you have chosen to use one content-type, that seems 
>>> to already contain distinct representations for the differing 
>>> behaviors of interest, and yet use distinct content-dispositions. I 
>>> think you could use a single content-disposition and get the same effect.
>>>
>>> I guess multiple content-dispositions might make sense if they are 
>>> processed by different entities, so that only the intended entities 
>>> need decode the body.
>>>
>>> <JL> The reason for having two content dispositions is because there are different behaviors for the same content-type when received by different entities.
>>> <JL> There are two different entities that apply a different behavior when receiving the body, say behavior A and behavior B. However, XML elements present in the body trigger behavior A (in the abstract of the draft, behavior (2)) by entity A and if not present, no further behavior by entity A is specified in this draft. Other XML elements present in the body trigger one of a set of behaviors B (in the abstract of the draft, behaviors (1) and (3)) by entity B and if not present, no further behavior by entity B is specified in this draft.
>>>
>>> It would also make sense if the same identical body representation 
>>> was processed differently based on the content-disposition.
>>>
>>> <JL> The bodies triggering the different behaviors are indeed not identical.
>>> <JL> However, the content-dispositions are processed by different entities, which is a reason for proposing these content-disposition values.
>>>
>>> But I don't think either of those is the case here. So I would find it helpful if this draft explained why it chooses to use multiple content-dispositions.
>>>
>>> <JL> The draft illustrates that, in IMS, different entities receive bodies with the content-type, and apply different behaviors. The draft further suggests that the applicability of these values may be limited to IMS. Do you see a need for a general discussion of this approach since the applicability is limited to IMS?
>>>
>>> I also think it would be useful to say something about how you 
>>> expect the handling parameter to be used with these dispositions. If 
>>> handling=required (the default) is used, then any UA that gets this 
>>> must fail the request unless it is able to handle the body. If 
>>> handling=optional is specified, then that need not be so.
>>>
>>> <JL> The handling parameter is mentioned in RFC 3261 and this draft refers to that RFC. RFC 3261 refers to RFC 3204. This draft does not change the behavior and interpretation of the parameter and its values. It should not be necessary to repeat what has already been documented in RFC 3261. Do you see different behavior that goes beyond what has been documented?
>>>
>>>       Thanks,
>>>       Paul
>>>
>>> On 12/3/11 5:08 AM, [email-masked] wrote:
>>>>
>>>> A New Internet-Draft is available from the on-line Internet-Drafts directories.
>>>>
>>>>      Title           : Specification of 3GPP IM CN Subsystem XML body handling
>>>>      Author(s)       : John-Luc Bakker
>>>>      Filename        : draft-bakker-sipping-3gpp-ims-xml-body-handling-07.txt
>>>>      Pages           : 7
>>>>      Date            : 2011-12-02
>>>>
>>>>     This document registers new disposition-types for the Content-
>>>>     Disposition header field that apply to the application/3gpp-ims+xml
>>>>     body used by 3GPP.  The applicability of these content-disposition
>>>>     values are limited to 3GPP IMS.  The application/3gpp-ims+xml body
>>>>     has the following three distinct uses: (1) for redirecting the
>>>>     emergency session to use a different domain (e.g. using a Circuit
>>>>     Switched call), (2) for delivering user profile specific information
>>>>     from the SIP registrar to an Application Server, and (3) for causing
>>>>     a UAC to attempt to re-register with the IMS.
>>>>
>>>>
>>>> A URL for this Internet-Draft is:
>>>> http://www.ietf.org/internet-drafts/draft-bakker-sipping-3gpp-ims-x
>>>> ml
>>>> -body-handling-07.txt
>>>>
>>>> Internet-Drafts are also available by anonymous FTP at:
>>>> ftp://ftp.ietf.org/internet-drafts/
>>>>
>>>> This Internet-Draft can be retrieved at:
>>>> ftp://ftp.ietf.org/internet-drafts/draft-bakker-sipping-3gpp-ims-xm
>>>> l-
>>>> body-handling-07.txt
>>>>
>>>> _______________________________________________
>>>> I-D-Announce mailing list
>>>> [email-masked]
>>>> https://www.ietf.org/mailman/listinfo/i-d-announce
>>>> Internet-Draft directories: http://www.ietf.org/shadow.html or 
>>>> ftp://ftp.ietf.org/ietf/1shadow-sites.txt
>>>>
>>>
>>>
>>> --------------------------------------------------------------------
>>> - This transmission (including any attachments) may contain 
>>> confidential information, privileged material (including material protected by the solicitor-client or other applicable privileges), or constitute non-public information. Any use of this information by anyone other than the intended recipient is prohibited. If you have received this transmission in error, please immediately reply to the sender and delete this information from your system. Use, dissemination, distribution, or reproduction of this transmission by unintended recipients is not authorized and may be unlawful.
>>> _______________________________________________
>>> dispatch mailing list
>>> [email-masked]
>>> https://www.ietf.org/mailman/listinfo/dispatch
>>>
>>> --------------------------------------------------------------------
>>> - This transmission (including any attachments) may contain 
>>> confidential information, privileged material (including material protected by the solicitor-client or other applicable privileges), or constitute non-public information. Any use of this information by anyone other than the intended recipient is prohibited. If you have received this transmission in error, please immediately reply to the sender and delete this information from your system. Use, dissemination, distribution, or reproduction of this transmission by unintended recipients is not authorized and may be unlawful.
>>>
>>
>>
>> ---------------------------------------------------------------------
>> This transmission (including any attachments) may contain confidential information, privileged material (including material protected by the solicitor-client or other applicable privileges), or constitute non-public information. Any use of this information by anyone other than the intended recipient is prohibited. If you have received this transmission in error, please immediately reply to the sender and delete this information from your system. Use, dissemination, distribution, or reproduction of this transmission by unintended recipients is not authorized and may be unlawful.
>>
>>
> 
> _______________________________________________
> dispatch mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dispatch
> 
> 

---------------------------------------------------------------------
This transmission (including any attachments) may contain confidential information, privileged material (including material protected by the solicitor-client or other applicable privileges), or constitute non-public information. Any use of this information by anyone other than the intended recipient is prohibited. If you have received this transmission in error, please immediately reply to the sender and delete this information from your system. Use, dissemination, distribution, or reproduction of this transmission by unintended recipients is not authorized and may be unlawful.

---

From: Cullen Jennings <[email-masked]>
Date: Thu, 7 Jun 2012 11:47:55 -0700

I did not suggest it should be standards track. I objected to it being experimental. 

On May 31, 2012, at 8:50 , Andrew Allen wrote:

> Cullen
> 
> Do you include 3GPP IMS as part of the internet now? I thought at least some people in IETF regarded it as a "walled garden".
> 
> My understanding is that the scope of this is for 3GPP IMS usage only and specifically related to 3GPP IMS emergency calls and 3GPP IMS fault recovery procedures. This 3GPP specific XML body and the associated procedures are very specific to 3GPP IMS and not generally applicable to the internet.
> 
> I thought it was decided a long time ago that not every 3GPP IMS specific thing needed to be standards track. Hence P-headers (e.g RFC 3455,.....), and now expert reviews for many things that are needed to meet 3GPP special requirements. Such things which are not standards track will also be deployed in the same billion devices. So I don't think the potential number of devices that functionality will be deployed in is a criteria for determining whether that functionality should be standards track or not.
> 
> My understanding was that RAI area was trying to move away from WGs spending a lot of energy working on 3GPP specific things that were not generally applicable (not the other way around) hence the move to expert reviews for some things that used to require work in SIPPING.
> 
> RFC 3113 defines cooperation between 3GPP and IETF. I don't think it is really in the spirit of this agreement that over 4 years after the initial draft submission suggestions are just now being made that this should be standards track.
> 
> Lack of progression of this draft (and some others) is having a negative impact on the deployment of the billion devices. An entire industry cannot tolerate continuing delay. I fear that if we cannot soon progress these drafts to RFC status we will very soon end up in a situation that a billion devices will be deployed with types and identifiers that are not IANA registered and that cannot be good for 3GPP or the internet.

Right - then perhaps some people should get series about discussing what the issues are and how to solve them instead of insisting we rubber stamp some draft that makes no sense. 

> Andrew
>> From: [email-masked] [mailto:[email-masked]] On
>> Behalf Of Cullen Jennings
>> Sent: Thursday, May 31, 2012 8:22 AM
>> To: John-Luc Bakker
>> Cc: [email-masked]
>> On May 15, 2012, at 4:37 PM, John-Luc Bakker wrote:
>> 
>>> http://tools.ietf.org/html/draft-bakker-sipping-3gpp-ims-xml-body-
>> handling-08#section-1
>> 
>> I think something intended to be production deployed on the order of a
>> billion devices on the internet is not appropriate to be called
>> "experimental"
>> 
>>