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

From: John-Luc Bakker <[email-masked]>
Date: Tue, 15 May 2012 22:37:17 +0000

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#mail-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-handling-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-hand
> 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-xml
>> -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-xml-
>> 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.

---

From: Gonzalo Camarillo <[email-masked]>
Date: Mon, 28 May 2012 13:45:49 +0300

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

---

From: Gonzalo Camarillo <[email-masked]>
Date: Wed, 30 May 2012 11:18:36 +0300

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

---

From: Cullen Jennings <[email-masked]>
Date: Thu, 31 May 2012 07:21:36 -0600

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

---

From: Cullen Jennings <[email-masked]>
Date: Thu, 31 May 2012 07:40:42 -0600

> Was there any conclusion?

Just to be very clear, sending this with my individual contributor hat on here ...

My recollection was there was some discussion of ways to solve this problem that would avoid the IPR disclosed. Some people expressed concerns with that which led to some discussion that indicated it was not 100% clear to everyone what the problem being solved was.  No conclusion was ever made on which way to proposed. John-Luc, does that roughly match what you remember?

Thanks, Cullen

---

From: Andrew Allen <[email-masked]>
Date: Thu, 31 May 2012 15:50:17 +0000

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.

Andrew

> Behalf Of Cullen Jennings
> Sent: Thursday, May 31, 2012 8:22 AM
> To: John-Luc Bakker
> Cc: [email-masked]
> Subject: Re: [dispatch] draft-bakker-sipping-3gpp-ims-xml-body-handling-
> 07
> 
> 
> 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"
> 
>

---

From: Adam Roach <[email-masked]>
Date: Thu, 31 May 2012 11:34:35 -0500

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

Indulge me as I pass along a joke.

A newly convicted inmate shows up at prison on his first day. During 
lunch, he noticed that a man would shout out a number--"a hundred and 
twelve" or "thirteen" or "seventy-eight"--and the whole room would burst 
out in peals of laughter. Perplexed, the new prisoner asked one of his 
colleagues what everybody was laughing about. "Jokes," the old prisoner 
said. "We've heard the same jokes so many times that we know them all by 
heart. In fact, we've heard them so many times that given each of them a 
number. So instead of telling each other the jokes, we just call out the 
number to the joke we want to tell. Saves a lot of time."

Eager to fit in, the new inmate waited for a pause in the conversations 
around him and yelled, "Forty-six!" Everybody stopped and stared. Nobody 
laughed. Near the corner of the table, the man heard one prisoner say to 
another, "Some guys don't know how to tell a joke."

Anyway, as much as I'd like to just say "thirty-seven" and get it over 
with, we've not quite progressed to this point in RAI. But we're getting 
close. So the shorthand I'm going to use is "anything you do in a walled 
garden will eventually leak out into the public Internet." If you want 
the long form of this argument, it exists in various IETF mailing list 
archives many times over.

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

You're slightly correct. There is no carte blanche loophole that allows 
external SDOs to make arbitrary changes to SIP's overall processing.

The actual policy, documented in RFC 5727, is that such extensions are 
okay as long as they meet certain criteria. The addition of new header 
fields, like those you discuss above, is allowed outside of standards 
track documents as long as they are "of a purely informational nature 
and [do] NOT significantly change the behavior of SIP entities that 
support [them]."

I think something as profound as new behavior that redirects clients to 
use a completely different mode of communication falls way, way outside 
the spirit and letter of what is allowed by this process. I think that 
is very much an update to standardized behavior, and as such requires a 
standards-track specification.

> 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 ma…

It's a bit specious to claim that any kind of IETF-related work has been 
going on for that long. As far as I can tell, there have been a grand 
total of three (!) messages on the SIPPING list on this topic. One, in 
August of 2008, from John-Luc, announcing the document; another from him 
in March of 2011, doing the same for the -06 version; and a third, from 
Paul Kyzivat, in December of 2011. Given that the earliest substantive 
thing said on this document was five months ago, your "4 year" statistic 
is way out of line. And, honestly, if you're looking for places where 
delays exist, you might consider that it took the document author over 
four months to respond to those comments.

On the topic of RFC 3113, I think you'll find that it also has language 
around 3GPP's use of IETF standards:

    3GPP recognizes that additions or modifications might be
    needed in order to make the IETF internet specification fulfill the
    needs of 3GPP.  In such cases, 3GPP will take its concerns directly
    to the appropriate IETF working groups for resolution, or to an
    appropriate Area Director if no appropriate working group can be
    found.

Note that this agreement talks about 3GPP bringing the need for changes 
to the IETF. Not fully-formed solutions for ratification. When this body 
handling work showed up at the IETF, it was already specified down to 
the syntax level. That is never a recipe for success. When it comes to 
IETF protocols, what *works* is bringing in a *problem*, and then 
working on a solution together.

> 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'm not sure I see how a draft that has generated a sum total of 
thirteen email messages in its entire existence, a draft that has a 
four-month turn-around time for responses from its author -- I'm not 
sure how a draft meeting that description is supposed to be interpreted 
as urgent.

/a

---

From: Michael Hammer <[email-masked]>
Date: Thu, 31 May 2012 17:40:51 +0000

Adam,

WRT the 1 billion devices versus the 3 billion phones.

The joke that came to mind was the challenge to an assorted group of
professions to design the smallest fence that would encircle a herd of
sheep.

I'll spare you the first few attempts.

When it came time for the mathematician, he thought a second then built a
fence around himself then said, "I define everything on the other side of
the fence to be on the inside."

It may be news to some, but mobile devices are the Internet access today.

If it is a good idea, it should be adopted for wider Internet use, even if
it came from the 3GPP.

I'll pass on the moment about the evaluation of the immediate draft.

Mike

From: [email-masked] [mailto:[email-masked]] On Behalf
Of Adam Roach
Sent: Thursday, May 31, 2012 12:35 PM
To: [email-masked]
Subject: Re: [dispatch] draft-bakker-sipping-3gpp-ims-xml-body-handling-07

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

A newly convicted inmate shows up at prison on his first day. During lunch,
he noticed that a man would shout out a number-"a hundred and twelve" or
"thirteen" or "seventy-eight"-and the whole room would burst out in peals of
laughter. Perplexed, the new prisoner asked one of his colleagues what
everybody was laughing about. "Jokes," the old prisoner said. "We've heard
the same jokes so many times that we know them all by heart. In fact, we've
heard them so many times that given each of them a number. So instead of
telling each other the jokes, we just call out the number to the joke we
want to tell. Saves a lot of time."

Anyway, as much as I'd like to just say "thirty-seven" and get it over with,
we've not quite progressed to this point in RAI. But we're getting close. So
the shorthand I'm going to use is "anything you do in a walled garden will
eventually leak out into the public Internet." If you want the long form of
this argument, it exists in various IETF mailing list archives many times
over.

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.

The actual policy, documented in RFC 5727, is that such extensions are okay
as long as they meet certain criteria. The addition of new header fields,
like those you discuss above, is allowed outside of standards track
documents as long as they are "of a purely informational nature and [do] NOT
significantly change the behavior of SIP entities that support [them]." 

I think something as profound as new behavior that redirects clients to use
a completely different mode of communication falls way, way outside the
spirit and letter of what is allowed by this process. I think that is very
much an update to standardized behavior, and as such requires a
standards-track specification.

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.

It's a bit specious to claim that any kind of IETF-related work has been
going on for that long. As far as I can tell, there have been a grand total
of three (!) messages on the SIPPING list on this topic. One, in August of
2008, from John-Luc, announcing the document; another from him in March of
2011, doing the same for the -06 version; and a third, from Paul Kyzivat, in
December of 2011. Given that the earliest substantive thing said on this
document was five months ago, your "4 year" statistic is way out of line.
And, honestly, if you're looking for places where delays exist, you might
consider that it took the document author over four months to respond to
those comments.

Note that this agreement talks about 3GPP bringing the need for changes to
the IETF. Not fully-formed solutions for ratification. When this body
handling work showed up at the IETF, it was already specified down to the
syntax level. That is never a recipe for success. When it comes to IETF
protocols, what *works* is bringing in a *problem*, and then working on a
solution together.

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'm not sure I see how a draft that has generated a sum total of thirteen
email messages in its entire existence, a draft that has a four-month
turn-around time for responses from its author -- I'm not sure how a draft
meeting that description is supposed to be interpreted as urgent.

/a

---

From: Adam Roach <[email-masked]>
Date: Thu, 31 May 2012 13:30:45 -0500

On 5/31/12 12:40, May 31, Michael Hammer wrote:
>
> Adam,
>
> WRT the 1 billion devices versus the 3 billion phones...
>
> When it came time for the mathematician, he thought a second then 
> built a fence around himself then said, "I define everything on the 
> other side of the fence to be on the inside."
>
> If it is a good idea, it should be adopted for wider Internet use, 
> even if it came from the 3GPP.
>

Sure, why not. If the problem exists, the solution should be the same 
everywhere.

But that really *does* point away from an experimental solution, and 
more towards something standards-track.

It points away from a "works in my network but maybe not it yours" 
solution, and towards a "works in the Internet at large" solution.

Right?

/a

---

From: Michael Hammer <[email-masked]>
Date: Thu, 31 May 2012 19:57:01 +0000

Agree.  Absolutely.

Mike

From: Adam Roach [mailto:[email-masked]] 
Sent: Thursday, May 31, 2012 2:31 PM
To: Michael Hammer
Cc: [email-masked]
Subject: Re: [dispatch] draft-bakker-sipping-3gpp-ims-xml-body-handling-07

Adam,

But that really *does* point away from an experimental solution, and more
towards something standards-track.

It points away from a "works in my network but maybe not it yours" solution,
and towards a "works in the Internet at large" solution.

Right?

/a