Subject: Re: [Sip] Multiple body-parts in one INFO

From: "Christer Holmberg" <[email-masked]>
Date: Mon, 1 Dec 2008 12:14:38 +0100

Hi, 

>>Sounds ok.
>>But, doesn't the Info-Package header syntax still have to allow the 
>>piggy-backer to:
>>1) List multiple info packages
>>2) For each listed info package, provide the cid
> 
>Nope.  We've already said we're going to not bother doing 
>multiple packages. (or at least I think people have agreed 
>with that, I hope)
>
>So the next question was on multiple body-parts.

I still want to see why we, if we are going to allow multiple body
parts, can't allow multiple info packages, but let's leave that for a
moment...

>Since INVITE, UPDATE, PRACK, SUBSCRIBE/NOTIFY, MESSAGE, and legacy
INFO, can all carry bodies and not one of 
>them defined a CID mechanism for the body part that was specific to
their message method context, we shouldn't need 
>to for INFO either.

Yes. And, if we are going to use CID, it means yet another RFC to
support.

What's wrong with using Content-Disposition?

>A "piggy-backer" is an extension to SIP that piggy-backs 
>bodies onto any message method types.  Geolocation is an 
>example of one.  Since it's the responsibility of the 
>piggy-backer to handle identifying its specific body-part and 
>dis-ambiguating it from the method's, we don't have to do 
>anything.  In other words, Geolocation would already have to 
>deal with current INFO message and body syntax.
> 
>For example, let's suppose someone creates an INFO package 
>for sending virtual location information in a game, using a 
>content-type of application/pidf+xml.  (whether they should 
>have done it in SIP vs. the media layer is orthogonal)  And 
>let's suppose for whatever reason the SIP stack always adds 
>Geolocation information of the UA's physical location.
>Here is what it would look like:

But, what if the information the piggy-backer wants to send also uses
info packages?

Regards,

Christer
_______________________________________________
Sip mailing list  https://www.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use [email-masked] for questions on current sip
Use [email-masked] for new developments on the application of sip

---

From: Eric Burger <[email-masked]>
Date: Mon, 1 Dec 2008 09:12:35 -0500

Just because everyone else got it wrong does not mean we have to be  
wrong, too...

---

From: Paul Kyzivat <[email-masked]>
Date: Mon, 01 Dec 2008 09:17:55 -0500

Hadriel Kaplan wrote:
>> -----Original Message-----
>> From: Christer Holmberg [mailto:[email-masked]]
>> Sent: Sunday, November 30, 2008 4:58 PM
>>
>> Sounds ok.
> Nope.  We've already said we're going to not bother doing multiple packages. (or at least I think people have agreed with that, I hope)
> So the next question was on multiple body-parts.  Since INVITE, UPDATE, PRACK, SUBSCRIBE/NOTIFY, MESSAGE, and legacy INFO, can all carry bodies and not one of them defined a CID mechanism for the body part that was specific to their message method context, we shouldn't need to for INFO either.

The problem is that none of them really considered the impact of 
multiple body parts, so it is anything but clear how an application is 
supposed to decipher one of these messages when it does contain multiple 
body parts. We are going to find that when combined with body parts for 
other purposes, implementations will do a variety of things. (That 
includes existing legal usages, such as body parts with C-D of "alert", 
which have been defined for a long time but never used.)

The body-handling draft tries to sort this out. But based on that we 
need to do better going forward than we did in the past.

Things were only "simple" in the past because we left things unspecified 
that needed to be specified.

You can have your "simple" solution here, analogous to the historic 
mechanism, by explicitly defining that body part(s?) with the 
content-disposition of "render" are to be considered to be the 
info-package payload. I say "render" because that is the *default* C-D, 
so it keeps things "simple" since it can be omitted. However you then 
should specify what happens if there are multiple body parts with C-D of 
"render". Also, you then need to specify whether a multipart body with a 
C-D of "render" should be viewed (in total) as the info-package payload, 
or whether some contained part of it should be the payload.

Personally, I would rather go with something less "simple" but more 
explicit here. Either a special C-D, or the CID reference.

	Thanks,
	Paul

> A "piggy-backer" is an extension to SIP that piggy-backs bodies onto any message method types.  Geolocation is an example of one.  Since it's the responsibility of the piggy-backer to handle identifying its specific body-part and dis-ambiguating it from the method's, we don't have to do anything.  In other words, Geolocation would already have to deal with current INFO message and body syntax.
> 
> For example, let's suppose someone creates an INFO package for sending virtual location information in a game, using a content-type of application/pidf+xml.  (whether they should have done it in SIP vs. the media layer is orthogonal)  And let's suppose for whatever reason the SIP stack always adds Geolocation information of the UA's physical location.
> ----BEGIN----
> INFO sip:[email-masked] SIP/2.0
> Call-ID: [email-masked]
> From: <sip:[email-masked]>;tag=27285
> To: <sip:[email-masked]>;tag=GR52RWG346-34
> CSeq: 2 INFO
> Via: SIP/2.0/UDP 192.168.1.1:5060;branch=z9hG4bK-6110000000000893
> Max-Forwards: 70
> Info-Package: virtual-loc
> Geolocation: <cid:whereami@invalid>
> Content-Length: [whatever]
> Content-Type: multipart/mixed;boundary="boundary1"
> 
> --boundary1
> Content-Type: application/pidf+xml
> 
> [xml stuff goes here]
> --boundary1
> Content-Type: application/pidf+xml
> Content-Disposition: by-reference
> Content-ID: whereami@invalid
> 
> [xml stuff goes here]
> --boundary1--
> ----END----

---

From: "Christer Holmberg" <[email-masked]>
Date: Mon, 1 Dec 2008 15:18:13 +0100

Wrong where/what/how? 

> From: [email-masked] [mailto:[email-masked]] On 
> Behalf Of Eric Burger
> Sent: 1. joulukuuta 2008 16:13
> To: Hadriel Kaplan
> Cc: SIP List
> Subject: Re: [Sip] Multiple body-parts in one INFO
> 
> Just because everyone else got it wrong does not mean we have 
> to be wrong, too...
> 
> >> Nope.  We've already said we're going to not bother doing multiple 
> >> packages. (or at least I think people have agreed with 
> that, I hope)
> >>
> bodies onto 
> >> any message method types.  Geolocation is an example of 
> one.  Since 
> >> it's the responsibility of the piggy-backer to handle 
> identifying its 
> >> specific body-part and dis-ambiguating it from the 
> method's, we don't 
> >> have to do anything.  In other words, Geolocation would 
> already have 
> >> to deal with current INFO message and body syntax.
> >>
> >> For example, let's suppose someone creates an INFO package for 
> >> sending virtual location information in a game, using a 
> content-type 
> >> of application/pidf+xml.  (whether they should have done it in SIP 
> >> vs. the media layer is orthogonal)  And let's suppose for whatever 
> >> reason the SIP stack always adds Geolocation information 
> of the UA's 
> >> physical location.
> > This list is for NEW development of the core SIP Protocol Use 
> > [email-masked] for questions on current sip Use 
> > [email-masked] for new developments on the application of sip
> 
>

---

From: Eric Burger <[email-masked]>
Date: Mon, 1 Dec 2008 09:31:58 -0500

Wrong because there is no explicit linking of a body part to what that  
body part belongs to.

Content-Disposition is absolutely the wrong thing.  The original  
Content-Disposition is about whether you wait for the whole message to  
arrive before rendering, and if you render the part where you find it  
or as an attachment.  SIP has bent this totally out of shape beyond  
recognition, almost to the point where it really is Message-Context.

Perhaps that is the answer?  Do-as-I-say (Message-Context), not Do-as- 
I-mean (Content-Disposition)?

---

From: Hadriel Kaplan <[email-masked]>
Date: Mon, 1 Dec 2008 10:52:38 -0500

> Sent: Monday, December 01, 2008 6:15 AM
>
>

That's illogical, I think.  An "Info Package" is inexorably linked to an INFO message context use.  A piggy-backer could certainly use the same content-type, with even the same semantics as a package, but it's not an "Info-Package".

It's like asking if one can use a RFC 4235 Dialog Event Package with an INFO message.  The answer is no - Event Packages are tied to a Subscribe/Notify usage.  You could use an "application/dialog-info+xml" body in an INFO I suppose, but you're not actually using/doing the "Dialog Event Package", and you'd have to define an Info-Package for that body type with whatever semantics apply.

-hadriel

---

From: Hadriel Kaplan <[email-masked]>
Date: Mon, 1 Dec 2008 11:22:26 -0500

> From: Paul Kyzivat [mailto:[email-masked]]
> Sent: Monday, December 01, 2008 9:18 AM
>
> Hadriel Kaplan wrote:
> > So the next question was on multiple body-parts.  Since INVITE, UPDATE,
> PRACK, SUBSCRIBE/NOTIFY, MESSAGE, and legacy INFO, can all carry bodies
> and not one of them defined a CID mechanism for the body part that was
> specific to their message method context, we shouldn't need to for INFO
> either.
>

There are two aspects to this:
1) Legacy/deployed code.  There's a crapload of it out there, doing what sub/not/publish/message/info/etc. said to do.  That code is deployed - there is NOTHING we can define to change their behavior, because the code is what the code is.  So as I said before, we can't go turn back the clock.  Any piggy-backer that would create multiple body parts where none existed before has the responsibility to make itself work with that legacy code, not the other way around.  That's not a problem we can fix.

2) New INFO code.  I think we all agree that this draft must reference the body-handling draft as normative to support.  The next question is if the draft needs to make any other specific normative requirements for handling of anything other than what the body-handling draft says.  If it does, then I would assert such extra normative requirements are necessary for Subscribe/Notify/Message/etc. too, and thus deserve their own, separate draft that covers all of those message types, instead of one specific for INFO.  A separate draft like, oh... body-handling?  :)

-hadriel

---

From: Paul Kyzivat <[email-masked]>
Date: Mon, 01 Dec 2008 13:04:46 -0500

Hadriel Kaplan wrote:
> 1) Legacy/deployed code.  There's a crapload of it out there, doing what sub/not/publish/message/info/etc. said to do. 

And doing what it *thought* it should do in cases where the specs didn't 
say.

I suspect that the majority of the deployed code won't do anything good 
with multipart, though I see from the SIPit reports that support is 
getting there in things that are being brought to SIPit. (May not be the 
majority of what is deployed.)

> That code is deployed - there is NOTHING we can define to change their behavior, because the code is what the code is.  So as I said before, we can't go turn back the clock.  Any piggy-backer that would create multiple body parts where none existed before has the responsibility to make itself work with that legacy code, not the other way around.  That's not a problem we can fix.
> 

For use with info-packages, we still have to define how the info package 
body part is identified by the recipient. Simply saying that it should 
be done the same way that old INFO, NOTIFY, and MESSAGE do it, when that 
hasn't been well defined, isn't a sufficient solution.

The bottom line is that we have *nothing* that says "this is how you 
identify the body part(s) that are supposed to be processed based on the 
definition of the type of message that contains them". Yet that is what 
we need here. (And what we should have had for MESSAGE and NOTIFY as 
well, among others.)

There is also what should be done for new implementations of legacy 
INFO, and to upgrade existing implementations of the legacy INFO.

All the code has to continue supporting legacy INFO. Even after almost 
everybody has upgraded their code to support multipart, legacy INFO 
usage will almost certainly continue. So there can then be cases where 
legacy info use is combined with body parts used for other purposes. We 
should be clear how that should work. And it must be defined in such a 
way that interoperation with old implementations of INFO still works.

The mechanism used to identify the body part for legacy info *could* be 
entirely distinct from the mechanism used for identifying an 
info-package. But if a common mechanism works for both, that would be nice.

	Thanks,
	Paul

---

From: Hadriel Kaplan <[email-masked]>
Date: Mon, 1 Dec 2008 13:28:50 -0500

> Sent: Monday, December 01, 2008 1:05 PM
>
> [snip]

Since, as you said, legacy INFO (or legacy anything really) has basically undefined behavior for multiple body-parts, how can we reasonably define a mechanism that works for multiple body parts with legacy code?

I think the answer is: don't change it.  One way to not change it, as you've already pointed out in a previous email, is to simply say anything with a Content-Disposition of "render" is for the package, unless the package defines a specific Content-Disposition for itself. (as SIP-T/SIP-I does, for example)

-hadriel

---

From: "Christer Holmberg" <[email-masked]>
Date: Mon, 1 Dec 2008 20:52:51 +0100

Hi, 

body part belongs to.
Content-Disposition is about whether you wait for the whole message to
arrive before rendering, and if you render the part where you find 
>it or as an attachment.  SIP has bent this totally out of shape beyond

So, maybe we should use Content-Type, then?

Regards,

Christer

>> From: [email-masked] [mailto:[email-masked]] On Behalf Of

>> Eric Burger

---

From: "Christer Holmberg" <[email-masked]>
Date: Mon, 1 Dec 2008 21:03:56 +0100

Hi, 

>>I suspect that the majority of the deployed code won't do anything 
>>good with multipart, though I see from the SIPit reports that support 
>>is getting there in things that are being brought to SIPit. (May not 
>>be the majority of what is deployed.)
>>
>>[snip]
>>

>>legacy info use is combined with body parts used for other purposes. 
>>We should be clear how that should work. And it must be defined in 
>>such a way that interoperation with old implementations of INFO still
works.
>
>Since, as you said, legacy INFO (or legacy anything really) has
basically undefined behavior for multiple body-parts, how can we
reasonably define a mechanism that works for multiple body parts with 
>legacy code?

I think I agree with Hadriel on this one :)

Legacy has issues, and people who want to continue using legacy will
have ways of dealing with that. The whole purpose of this work os not to
make legacy better, but to define something which solves the issues with
legacy - Info packages. 

Yes, our document is also supposed to cover legacy, but I don't think we
should specify anything more than what is in the current RFC today.

So, I think the question we shall focus on is: how do we identify that a
body part contains an Info package?

>I think the answer is: don't change it.  One way to not change it, as
you've already pointed out in a previous email, is to simply say
anything with a Content-Disposition of "render" is for the package, 
>unless the package defines a specific Content-Disposition for itself.
(as SIP-T/SIP-I does, for example)

Each package can define what C-D value to use, but based on the
discussion I think that we will not use C-D to actually say "This body
part contains an info package".

Regards,

Christer

---

From: Eric Burger <[email-masked]>
Date: Mon, 1 Dec 2008 16:27:29 -0500

Content-Type doesn't work. See the draft itself or Message-Context RFC.

---

From: Hadriel Kaplan <[email-masked]>
Date: Mon, 1 Dec 2008 17:34:52 -0500

I too am confused about what/whom you feel is wrong.

Is it that you're unhappy that INVITE, ACK, PRACK, UPDATE, SUBSCRIBE, NOTIFY, PUBLISH, MESSAGE, REGISTER and INFO methods can have multiple body parts and there's no clear distinction of which body part applies to the method's context action/purpose?

ISTM somewhat silly to go and fix this for new uses of INFO.  It's like rearranging the deck chairs on the Titanic.  The ship was built to gracefully handle a few holes from usual wear-tear, and you want it to survive a whole iceberg (multiple bodies).  It would be nice to make the boat stronger (ie, change all the RFCs to have body-part contexts), but that ship has already sailed. (oooh, a metaphoric double entendre)

Imagine if we were talking about updating the HTTP POST method for some reason, and while we were doing it we realized some body-parts may not be for the POST context, but could instead be in any HTTP method - like a Geo-Loc body-part for example.
Would we:
(a) Change how POST is formatted, to uniquely identify the mime parts that *are* for POST operation, and only for POST, or
(b) Make the body parts that were *not* part of the POST context uniquely identify themselves as *not* being part of it, no matter the method?

Methinks (b).  (b) is accomplished by having the body-part that is NOT for the INFO package identify itself using a Content-Disposition of "by-reference".

-hadriel

> From: [email-masked] [mailto:[email-masked]] On Behalf Of Eric
> Burger
> Sent: Monday, December 01, 2008 9:32 AM
>

---

From: Dean Willis <[email-masked]>
Date: Mon, 01 Dec 2008 18:04:24 -0600

Hadriel said:

> This "problem" already exists for current SIP messages, and it's up
> to the new extensions that add body-parts to solve it in a
> backward-compatible way for all message methods.  We don't need to
> solve it specifically for INFO.

Hadriel has a point here.

We know that EVERY SIP usage where we end up with two or more
attachments is going to have the attachment-selection problem, aka
"which attachment goes with which extension?"

This isn't just a problem for new work; it's potentially a problem for
several old or ongoing bits of work that result in the potential for
multiple attachments.

Perhaps we should solve this universally in the body handling draft?

--
Dean

---

From: Dean Willis <[email-masked]>
Date: Mon, 01 Dec 2008 18:15:08 -0600

Hadriel Kaplan wrote:
>> -----Original Message----- From: Christer Holmberg
>> [mailto:[email-masked]] Sent: Sunday, November 30,
>> 2008 4:58 PM
>> 
>> Sounds ok. But, doesn't the Info-Package header syntax still have
>> to allow the piggy-backer to: 1) List multiple info packages 2) For
>> each listed info package, provide the cid
> 
> packages. (or at least I think people have agreed with that, I hope) 
> So the next question was on multiple body-parts.  Since INVITE,
> UPDATE, PRACK, SUBSCRIBE/NOTIFY, MESSAGE, and legacy INFO, can all
> carry bodies and not one of them defined a CID mechanism for the body
> part that was specific to their message method context, we shouldn't
> need to for INFO either.

No, I think this means we messed up every one of those methods when we
didn't address the multiple-body problem earlier. The reason it isn't
exploding yet is that the specifications are ahead of the
implementations; when the implementations catch up with the broken
specs, we'll have failures of biblical proportion.

Sometimes we can demux on body-type. This is obviously not a universal
solution. We really need a generic solution that works for all methods,
not just INFO.

---

From: Eric Burger <[email-masked]>
Date: Mon, 1 Dec 2008 19:32:43 -0500

That was my knee-jerk reaction, until I realized that EVERY method  
needs to address the issue. All body-handling can do is give guidance.

One approach is to bastardize Content-Disposition to mean Body-Part- 
Context, in the vein of Message-Context for e-mail (RFC 3458).  Body- 
handling would specify generic SIP stacks to be aware that Content- 
Disposition is how you pair a body part with its intended use. Hope no  
one else wants Content-Disposition: render for anything else...

Another approach is to mandate Content-ID, and give guidance to  
writers of extensions that add body parts to explicitly state how to  
address the relevant body part.

So, one thing is clear: we really screwed up by trying to hack Message- 
Context into Content-Disposition.  Mea Culpa for not noticing it sooner.

---

From: Paul Kyzivat <[email-masked]>
Date: Mon, 01 Dec 2008 19:42:16 -0500

> solution. We really need a generic solution that works for all methods,

Exactly.

Regardless of whether Eric thinks it was appropriate or not, 
Content-Disposition was recruited for this purpose in 3261 via its use 
for "session", "alert", and "icon". And it has been used in a few other 
RFCs in a similar fashion.

For lack of anything better, to remain backward compatible, we probably 
need to consider C-D of "render" as identifying the principal body part 
used by MESSAGE, SUBSCRIBE, NOTIFY, PUBLISH, and presumably *legacy* 
INFO. That works in the case where there is no multipart.

When you introduce multipart to any of those, unless you are careful to 
put some other C-D on the multipart itself, it becomes ambiguous whether 
the multipart as a whole is the principle body for the method, or if it 
should be opened and a part within it sought, because the default 
disposition for the multipart will be "render". We could probably fix 
this by having a special rule for multipart/mixed with "render".

	Thanks,
	Paul

---

From: Dean Willis <[email-masked]>
Date: Mon, 01 Dec 2008 18:41:58 -0600

Hadriel Kaplan wrote:
> 
>> -----Original Message----- From: Paul Kyzivat
>> [mailto:[email-masked]] Sent: Monday, December 01, 2008 1:05 PM
>> 
>> 
>> good with multipart, though I see from the SIPit reports that
>> support is getting there in things that are being brought to SIPit.
>> (May not be the majority of what is deployed.)
>> 
>> [snip]
>> 
>> All the code has to continue supporting legacy INFO. Even after
>> almost everybody has upgraded their code to support multipart,
>> legacy INFO usage will almost certainly continue. So there can then
>> be cases where legacy info use is combined with body parts used for
>> other purposes. We should be clear how that should work. And it
>> must be defined in such a way that interoperation with old
>> implementations of INFO still works.
> 

By detecting the legacy code using a Require option-tag, and failing the
call.

Seriously.

For a very reasonable definition of backward-compatible, that's a
backward-compatible mechanism -- it behaves predictably in the presence
of broken old crap. We can't fix the broken old crap. All we can do is
detect its presence, and work within its limitations if required.

---

From: Hadriel Kaplan <[email-masked]>
Date: Mon, 1 Dec 2008 23:54:17 -0500

> From: Dean Willis [mailto:[email-masked]]
> Sent: Monday, December 01, 2008 7:42 PM
>
>

I am considering contacting the authorities to come find you.  Because you have either gone insane, or your email client has been hijacked. :)
Seriously - you expect us to put in a Require header option-tag when multi-part mime is used, so it can fail against every SIP device that is deployed on the planet??

At that point, I suggest you just change the SIP version number to a new value instead.

-hadriel

---

From: Gonzalo Camarillo <[email-masked]>
Date: Tue, 02 Dec 2008 11:02:57 +0200

Hi Eric,

if you think the body handling draft needs to give guidance on this, 
could you be more specific as to what exact guidance you want to be 
given (i.e., send text if you think the draft should say something about 
this ;o) )?

Thanks,

Gonzalo

Eric Burger wrote:
> That was my knee-jerk reaction, until I realized that EVERY method needs 
> to address the issue. All body-handling can do is give guidance.
> 
> One approach is to bastardize Content-Disposition to mean 
> Body-Part-Context, in the vein of Message-Context for e-mail (RFC 
> 3458).  Body-handling would specify generic SIP stacks to be aware that 
> Content-Disposition is how you pair a body part with its intended use. 
> Hope no one else wants Content-Disposition: render for anything else...
> 
> Another approach is to mandate Content-ID, and give guidance to writers 
> of extensions that add body parts to explicitly state how to address the 
> relevant body part.
> 
> So, one thing is clear: we really screwed up by trying to hack 
> Message-Context into Content-Disposition.  Mea Culpa for not noticing it 
> sooner.
> 
> ------------------------------------------------------------------------
>

---

From: Dean Willis <[email-masked]>
Date: Tue, 02 Dec 2008 15:07:13 -0600

Hadriel Kaplan wrote:
> 
>> -----Original Message----- From: Dean Willis
>> [mailto:[email-masked]] Sent: Monday, December 01, 2008
>> 7:42 PM
>> 
>> 
>> By detecting the legacy code using a Require option-tag, and
>> failing the call. Seriously. For a very reasonable definition of
>> backward-compatible, that's a backward-compatible mechanism -- it
>> behaves predictably in the presence of broken old crap. We can't
>> fix the broken old crap. All we can do is detect its presence, and
>> work within its limitations if required.
> 
> I am considering contacting the authorities to come find you.
> Because you have either gone insane, or your email client has been
> hijacked. :) 

Not a new condition, I'm afraid. If I were completely sane, would I do
this job?

> Seriously - you expect us to put in a Require header
> option-tag when multi-part mime is used, so it can fail against every
> SIP device that is deployed on the planet??

If understanding how to decode the multipart MIME is critical to the
success of the request, then I expect the request to fail if the UAS
cannot decode it. Further, I want it to fail predictably in a way that
the request originator can understand, not in some cryptic
application/version dependent way.

> At that point, I suggest you just change the SIP version number to a

Excellent suggestion. All in favor, please hum now ...

--
Dean

---

From: Hadriel Kaplan <[email-masked]>
Date: Tue, 2 Dec 2008 17:42:24 -0500

> Sent: Tuesday, December 02, 2008 4:07 PM
>

What you are suggesting is that to use multi-part MIME in current SIP methods, we cannot rely on currently deployed system behavior.  So you're basically proposing we either:
1) Never do multi-part MIME.
2) Do a new SIP version.

I'm ok with doing #1, but I don't think things are *that* bad anyway.  I think we can rely on systems to behave sanely enough to do a backwards-compatible multi-part that should work in most cases - for the cases it doesn't, I think it will fail explicitly (with a failure response), and *then* one can argue if you can re-send it without the other body parts, or if you just fail the call hard.  But at least by then you've actually hit an error, and it's not ALL deployed systems that will have the problem.

Although I do wonder about how much of a Red Herring this topic is - what exact use-cases do you guys have for multi-part bodies in SUBSCRIBE, NOTIFY, PUBLISH, and INFO that is not actually defined in a package for them?  Or are we in some theoretical La-La land? [no offense meant - I like La-La land]

-hadriel

---

From: Bob Penfield <[email-masked]>
Date: Tue, 2 Dec 2008 17:58:53 -0500

I was just looking at a traces today from a well known vendor that included many NOTIFY requests with multi-part bodies. One included 16 body parts of two different Content-Types.

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Hadriel Kaplan
Sent: Tuesday, December 02, 2008 5:42 PM
To: Dean Willis
Cc: SIP List
Subject: Re: [Sip] Multiple body-parts in one INFO

-hadriel

---

From: Hadriel Kaplan <[email-masked]>
Date: Tue, 2 Dec 2008 18:02:59 -0500

> From: Bob Penfield
> Sent: Tuesday, December 02, 2008 5:59 PM
>
> I was just looking at a traces today from a well known vendor that
> included many NOTIFY requests with multi-part bodies. One included 16 body
> parts of two different Content-Types.

Excellent - so it works!  What's the problem again?? :)

-hadriel

---

From: Paul Kyzivat <[email-masked]>
Date: Tue, 02 Dec 2008 19:47:02 -0500

Can you post a (anonymized) version? It would be very interesting.

	Thanks,
	Paul

---

From: "Christer Holmberg" <[email-masked]>
Date: Wed, 3 Dec 2008 13:00:48 +0100

Hi,

Most of the multipart cases I've seen have worked fine, because the
Content-Type normally tells everything the receiver needs to know (e.g.
SDP, ISUP, XML-whatever, etc).

I guess the potential problem is when you send things like image/jpeg
etc.

For info packages, I still don't understand why we can't specify a
common content-type value. The body part contains an info package, so
the content-typ is info something.

That way we would solve the how-to-find-info-body-parts problem, and
whatever common stuff then needs to be done for SIP can be done outside
the work of info.

Regards,

Christer  

> Behalf Of Hadriel Kaplan
> Sent: 3. joulukuuta 2008 0:42
> To: Dean Willis
> Cc: SIP List
> option-tag when 
> > > multi-part mime is used, so it can fail against every SIP device 
> > > that is deployed on the planet??
> >
> What you are suggesting is that to use multi-part MIME in 
> current SIP methods, we cannot rely on currently deployed 
> system behavior.  So you're basically proposing we either:
> I'm ok with doing #1, but I don't think things are *that* bad 
> anyway.  I think we can rely on systems to behave sanely 
> enough to do a backwards-compatible multi-part that should 
> work in most cases - for the cases it doesn't, I think it 
> will fail explicitly (with a failure response), and *then* 
> one can argue if you can re-send it without the other body 
> parts, or if you just fail the call hard.  But at least by 
> then you've actually hit an error, and it's not ALL deployed 
> systems that will have the problem.
> 
> Although I do wonder about how much of a Red Herring this 
> topic is - what exact use-cases do you guys have for 
> multi-part bodies in SUBSCRIBE, NOTIFY, PUBLISH, and INFO 
> that is not actually defined in a package for them?  Or are 
> we in some theoretical La-La land? [no offense meant - I like 
> La-La land]
> 
> -hadriel
> [email-masked] for questions on current sip

---

From: Paul Kyzivat <[email-masked]>
Date: Wed, 03 Dec 2008 10:13:08 -0500

> I guess the potential problem is when you send things like image/jpeg

The scary part is that demuxing based on C-T *does* work in a lot of 
simple cases, so it may be used widely. But it doesn't work in general. 
To work generally, it will be necessary to first demux based on C-D.

If we have a lot of implementations basing things on C-T, then they may 
not be inserting, or doing the necessary processing for C-D. That means 
they are likely to break in more complex cases going forward.

> the content-typ is info something.

If you chose a standard C-T for all info-packages, that constrains the 
syntax that it may contain. Yet each package is going to want to choose 
the syntax(es) that it uses. And some of them will want to be standard 
ones, such as image/jpeg. To deal with that your "standard" info C-T 
would have to be a container for an arbitrary mime type. So you have 
simply pushed the problem down a level.

> whatever common stuff then needs to be done for SIP can be done outside

IMO its a really bad way to go.

	Thanks,
	Paul

---

From: "Christer Holmberg" <[email-masked]>
Date: Wed, 3 Dec 2008 20:30:50 +0100

Hi, 

not be inserting, or doing the necessary processing for C-D. That means
they are likely to break in more complex cases going 
>forward.

We can still use C-D.

syntax that it may contain. Yet each package is going to want to choose
the syntax(es) that it uses. And some of them will want to 
>be standard ones, such as image/jpeg. To deal with that your "standard"
info C-T would have to be a container for an arbitrary mime type. So you
have simply pushed the problem down a level.

The syntax can be very simple - for example package name plus a binary
string which can contain whatever (the package defines the exact syntax
within that binary string). It works a little like the SDP fmtp
attribute.

>>whatever common stuff then needs to be done for SIP can be done 
>>outside the work of info.
>

It's simple, and it does not require support of new parameter,
content-ids etc.

Regards,

Christer

>> Hadriel Kaplan
>> What you are suggesting is that to use multi-part MIME in current SIP

>> methods, we cannot rely on currently deployed system behavior.  So 
>> you're basically proposing we either:
>> I'm ok with doing #1, but I don't think things are *that* bad anyway.

>> I think we can rely on systems to behave sanely enough to do a 
>> backwards-compatible multi-part that should work in most cases - for 
>> the cases it doesn't, I think it will fail explicitly (with a failure

>> response), and *then* one can argue if you can re-send it without the

>> other body parts, or if you just fail the call hard.  But at least by

>> then you've actually hit an error, and it's not ALL deployed systems 
>> that will have the problem.
>>
>> Although I do wonder about how much of a Red Herring this topic is - 
>> what exact use-cases do you guys have for multi-part bodies in 
>> SUBSCRIBE, NOTIFY, PUBLISH, and INFO that is not actually defined in 
>> a package for them?  Or are we in some theoretical La-La land? [no 
>> offense meant - I like La-La land]
>>
>> -hadriel

---

From: Paul Kyzivat <[email-masked]>
Date: Wed, 03 Dec 2008 14:50:31 -0500

Christer,

I just think using a single C-T for all packages is a bad idea.
Its quite likely that some packages will support multiple content types. 
Its also quite likely that some/many/most packages will want to use 
*existing* content-types. We already have a mechanism for negotiating 
support for content-types. We should exploit that, not discard it here.

We already have several other ways to skin this cat:
- use cid references and the by-reference c-d for the package body
- define "render" as the c-d for the package body in an INFO
- define a new c-d (e.g. "info-package") for the package body

IMO *all* of those are preferable to bastardizing the C-T for the purpose.

	Thanks,
	Paul

---

From: "Christer Holmberg" <[email-masked]>
Date: Wed, 3 Dec 2008 20:58:20 +0100

Hi,

- CID is too complex, and I think it will prevent some people from
moving from legacy to info packages.

- "Render" as the c-d is probably not 100% waterproof, since other body
types may also use it.

- I DO still strongly support a new c-d for the package body, but it
seems that others have issues with that.

Regards,

Christer 

-----Original Message-----
From: Paul Kyzivat [mailto:[email-masked]] 
Sent: Wednesday, December 03, 2008 9:51 PM
To: Christer Holmberg
Cc: Hadriel Kaplan; Dean Willis; SIP List
Subject: Re: [Sip] Multiple body-parts in one INFO

Christer,

IMO *all* of those are preferable to bastardizing the C-T for the
purpose.

	Thanks,
	Paul

Christer Holmberg wrote:
>>> I guess the potential problem is when you send things like 
>>> image/jpeg etc.
> not be inserting, or doing the necessary processing for C-D. That 
> means they are likely to break in more complex cases going
>> forward.
> 
> We can still use C-D.
> 
>>> common content-type value. The body part contains an info package, 
>>> so the content-typ is info something.
> syntax that it may contain. Yet each package is going to want to 
> choose the syntax(es) that it uses. And some of them will want to
> info C-T would have to be a container for an arbitrary mime type. So 
> you have simply pushed the problem down a level.
> 

> string which can contain whatever (the package defines the exact 
> syntax within that binary string). It works a little like the SDP fmtp

>>> I'm ok with doing #1, but I don't think things are *that* bad
anyway.

---

From: Paul Kyzivat <[email-masked]>
Date: Wed, 03 Dec 2008 15:39:27 -0500

> seems that others have issues with that.

How is CID "too complex"??? The id can be hard coded in most cases. So 
its just some additional boiler plate to add into the request. And it 
adds *1* extra header to the message. Anybody who can't manage that 
shouldn't be sending SIP messages.

I do think that a *new* c-d would be clearer than reusing "render".

I guess my preferences (1-100, 1 best) are:

1) new c-d
2) cid
10) c-d "render"
100) single c-t for info-packages.

	Paul

---

From: Hadriel Kaplan <[email-masked]>
Date: Wed, 3 Dec 2008 15:49:42 -0500

> Sent: Wednesday, December 03, 2008 2:58 PM
>

Nope, they actually can't.  Not in the INFO context.  Nor for that matter in the SUBSCRIBE, NOTIFY, or PUBLISH contexts.  If you add a body with the "render" C-D to one of those message method types, you're actually telling the far-end to give that body-part to its "user", which is the package application.  INFO is not the same context as MESSAGE.

> seems that others have issues with that.

In my mind, content-disposition is for a value that is basically a verb.  If each package-body needs a new verb to describe giving it to the package, or even if we create a common verb for all packages to give that body part to the package, then all we're doing is re-inventing the wheel.  The wheel is the INFO method name and Info-Package header value, which create the necessary and sufficient context with which to extract bodies of disposition "render" (or any specific disposition defined by the package).  The wheel is already capable of turning, since it appears to be turning fine in legacy INFO use.  We don't need to add hubcaps to make it more expensive. :)

-hadriel

---

From: "Christer Holmberg" <[email-masked]>
Date: Wed, 3 Dec 2008 21:58:30 +0100

Hi,

>> - "Render" as the c-d is probably not 100% waterproof, since other 
>> body types may also use it.
>> 
its just some additional boiler plate to add into the request. And it
adds *1* extra header to the message. Anybody who can't manage 
>that shouldn't be sending SIP messages.

Even if the value is hard coded on the sender side, the receiver will
still have to parse it - unless we define a hard coded value which
everyone must always use for info packages...

If we would allow multiple info packages per message I could see the use
of CID, but for a single info package I think a new c-d (or c-t) is much
more simple.

>100) single c-t for info-packages.

I agree with 1) :)

Regards,

Christer

---

From: "Christer Holmberg" <[email-masked]>
Date: Wed, 3 Dec 2008 22:06:30 +0100

Hi, 

>Nope, they actually can't.  Not in the INFO context.  Nor for that
matter in the SUBSCRIBE, NOTIFY, or PUBLISH contexts.  If you add a body
with the "render" C-D to one of those message method types, 
>you're actually telling the far-end to give that body-part to its
"user", which is the package application.  INFO is not the same context
as MESSAGE.

So, there is no risk that someone would insert a legacy INFO body part
with "render"?

>In my mind, content-disposition is for a value that is basically a
verb.  If each package-body needs a new verb to describe giving it to
the package, or even if we create a common verb for all packages 
>to give that body part to the package, then all we're doing is
re-inventing the wheel.  The wheel is the INFO method name and
Info-Package header value, which create the necessary and sufficient
context 
>with which to extract bodies of disposition "render" (or any specific
disposition defined by the package).  The wheel is already capable of
turning, since it appears to be turning fine in legacy INFO 
>use.  We don't need to add hubcaps to make it more expensive. :)

So, you are basically saying: we don't need to do anything as far as
find-the-body-part-with-the-info-package is concerned? We simple specify
that one inserts a Info-Package header with the package name, and that's
it? Whatever C-D/C-T value is used is then defined by the package
itself.

Well, since I assume most INFOs will be sent with a single body part
anyway, I guess it would work for those cases...

Regards,

Christer

---

From: Paul Kyzivat <[email-masked]>
Date: Wed, 03 Dec 2008 16:22:39 -0500

> everyone must always use for info packages...

True, it must parse it. And then it must seek out the body part that has 
the proper cid. Otherwise it must seek out the body part that has the 
proper C-D. Not much different there. Certainly not much of an 
additional hurdle if you have already agreed to implement the rest of 
the new info-package machinery.
	
	Paul

---

From: Hadriel Kaplan <[email-masked]>
Date: Wed, 3 Dec 2008 16:26:53 -0500

I think we're just going 'round and 'round on basically a non-issue.

Making *any* changes to INFO which don't provide real, tangible, and immediate value to either the developer or the customer/user, does not bode itself well to getting implementation.  Because INFO works.

Having a negotiation/detection scheme provides real, immediate value, by avoiding/reducing configuration.

Having a sub-context for the context already created by the "INFO" method does *not* provide such value, because there are no collisions/confusion in the real world AFAIK; but it was a common complaint from the IETF, so we put the Info-Package header in to resolve that.  It can basically be handled as syntactic sugar by current implementations, and is similar to Sub/Not/Pub, so fine.

Then somehow between IETF Dublin and Minneapolis, a mere 3.5 months (but a world apart in Guinness flavor), the draft doubled in size, adding another 20 pages.  To do what?  To add more dis-ambiguation and contextualizing, for a problem that has never actually been seen in the wild??  How many contexts of contexts, and meanings of meanings, do we need?  What value does that add over the currently deployed INFO?

-hadriel

> Sent: Wednesday, December 03, 2008 3:39 PM
> To: Christer Holmberg

---

From: Paul Kyzivat <[email-masked]>
Date: Wed, 03 Dec 2008 16:38:35 -0500

> So, there is no risk that someone would insert a legacy INFO body part

No matter what we do, legacy info usage will have body parts with "render".

I guess maybe you mean they might *combine* the use of a single INFO for 
one legacy INFO usage *and* one info-package??? They can only do that if 
we define that they may, which I expect we will not, if we are not 
allowing multiple packages. If we define that they can't, its just a 
matter of what the error is: either its
- erroneous attempt to use INFO for both legacy and info-package
- or its: too many package bodies for info package

And note that you can screw up with cid references too, by including the 
same Content-ID in two different body parts.

People will always find a way to screw up. They will just have to deal 
with it until they get smarter.

> it? Whatever C-D/C-T value is used is then defined by the package

I don't know what he is saying. But IMO we can't have just any old 
combination of C-D/C-T be the package.

No matter what, each body part does have a C-D - either explicitly or 
implicitly. And each brings its own "verb" with it. If a new one is not 
defined and used, and none is specified, then that verb will be "render".

But I don't agree that the C-D is a verb. "render" is a verb. But 
"inline", "attachment", "session", "early-session", "icon", 
"by-reference" are not verbs. And "alert" and "signal" (from 3204) might 
be nouns or verbs.

	Thanks,
	Paul

---

From: Paul Kyzivat <[email-masked]>
Date: Wed, 03 Dec 2008 16:50:41 -0500

Hadriel,

Is the problem that the document is hard to implement? Or just that you 
think it has too many words?

IMO when we leave ambiguity there will be problems.
I would rather see more words than have a brief but ambiguous document.
More words do not (necessarily) make the implementation more difficult.

Making the wrong choice of words can complicate the implementation.

Its also the case that we end up using a lot more words (in emails) 
along the way to convince ourselves that we all agree on what is meant. 
Once we agree, it may not take so many words in the document to 
unambiguously specify what we have decided.

We know we have needs for multipart, for things like Geoloc, and 
probably more, that are orthogonal to other usages. We are headed for a 
train wreck on that because 3261 didn't say enough about that. The body 
handlng draft will hopefully address much of that. We just need to try 
to ensure that other things play well with that.

	Thanks,
	Paul

---

From: Dean Willis <[email-masked]>
Date: Wed, 3 Dec 2008 18:15:10 -0600

On Dec 3, 2008, at 3:26 PM, Hadriel Kaplan wrote:

> Making *any* changes to INFO which don't provide real, tangible, and  
> immediate value to either the developer or the customer/user, does  
> not bode itself well to getting implementation.  Because INFO works.

How exactly does INFO work in conjunction with other extensions (e2m,  
AIB, SAML) that add bodies?

How do you KNOW it works with deployed phones? I haven't seen any  
implementations with those extensions applied to deployed phones, yet.

if we can see that INFO packages (and other SIP requests, perhaps) are  
going to have problems with other extensions that add bodies, then we  
have to fix it.

---

From: Hadriel Kaplan <[email-masked]>
Date: Wed, 3 Dec 2008 21:15:18 -0500

> Sent: Wednesday, December 03, 2008 7:15 PM
>

I don't know - it's like asking me how I know my chimney is big enough for Santa Claus.  The odds are not high I'll ever find out; but I'm not rebuilding the chimney to fit him - he has to fit in the chimney, because it's already built, and it's the same size as everyone else's chimney.

> implementations with those extensions applied to deployed phones, yet.

Right but there's the rub - the phones are DEPLOYED.  It's not them that need a'changin', nor *could* they be changed.  It's AIB/e2m/saml/foobar that need to be changed.

> going to have problems with other extensions that add bodies, then we

No, actually we don't.  We have to change the extensions to not have a problem with INFO - or any other SIP message type, for that matter.
Otherwise, what you're really saying is that every single message type in SIP needs to be changed - requests and responses - because this is NOT specific to INFO.  Good luck with that.  I'm sure people will love to change their implementations and upgrade all systems just in case unicorns show up someday.

-hadriel

---

From: Hadriel Kaplan <[email-masked]>
Date: Wed, 3 Dec 2008 21:55:48 -0500

> Sent: Wednesday, December 03, 2008 4:39 PM
>
> Christer Holmberg wrote:

Exactly.  Not just legacy INFO, BTW - Sub/Not/Pub/Mess/etc.

-hadriel

---

From: Hadriel Kaplan <[email-masked]>
Date: Wed, 3 Dec 2008 22:28:07 -0500

> Sent: Wednesday, December 03, 2008 4:51 PM
>

Of course, and I know document size is not a good measurement of complexity.
But it does have a psychological effect, fwiw.

Anyway, no my problem with the draft is it's trying to fix things that either aren't broken, or are broken for everything else and should not be fixed in this specific document. (and I'd debate how they should be fixed, but that's another topic)

> to ensure that other things play well with that.

Right, so do you also plan to have an update RFC, to change the C-D's of their context's bodies, for each of RFC 3261 (INVITE/ACK), 3265 (SUB/NOT), 3311 (UPDATE), 3428 (MESSAGE), 3262 (PRACK), 3515 (REFER), and 3903 (PUBLISH)?  Most of which have existential proofs of deployed use, and most of which are significant deployment use?  (at least I think INVITE is fairly popular - I could be wrong)

Or would you rather replace RFCs 3893 (AIB), RFC 3420 (sipfrag), and whatever current drafts do not dis-ambiguate themselves from the deployed message type context's bodies?
(And for 3893bis at least, I would assert the subject line of such a doc should start with the words "Moving to Experimental...", if not "Deprecation of...")

-hadriel

---

From: Paul Kyzivat <[email-masked]>
Date: Thu, 04 Dec 2008 00:10:04 -0500

> Anyway, no my problem with the draft is it's trying to fix things that either aren't broken, or are broken for everything else and should not be fixed in this specific document. (and I'd debate how…

You mean the way 3261 was simplified by not saying much about multipart 
and not requiring that it be supported, because that wasn't broken in 2543?

> Right, so do you also plan to have an update RFC, to change the C-D's of their context's bodies, for each of RFC 3261 (INVITE/ACK), 3265 (SUB/NOT), 3311 (UPDATE), 3428 (MESSAGE), 3262 (PRACK), 3515…

I don't think we need to change common usage of existing deployed stuff. 
We can grandfather the usages.

But by tightening up the required behavior when multipart is being used, 
we may indeed require some deployed devices to be updated to remain 
compliant. Without being updated they will continue to work in those 
cases where they work today. And many of the probably wouldn't have 
worked in some of those currently unused multipart cases anyway.

(We *do* make changes, such as the essential corrections and loop fixes.)

> (And for 3893bis at least, I would assert the subject line of such a doc should start with the words "Moving to Experimental...", if not "Deprecation of...")

AFAIK we haven't identified a need to do that. If we do, so be it.

I just want it to be clear under what circumstances you can use multiple 
body parts in a message, and how a recipient of a message containing 
multiple parts figures out how to process it.

Just in the thread we have already heard a explanation of doing it based 
solely on C-T, which is really wrong. So its obviously not clear now.

	Thanks,
	Paul

---

From: Hadriel Kaplan <[email-masked]>
Date: Thu, 4 Dec 2008 01:32:40 -0500

> Sent: Thursday, December 04, 2008 12:10 AM
>
> Hadriel Kaplan wrote:
> >
> > Anyway, no my problem with the draft is it's trying to fix things that
> either aren't broken, or are broken for everything else and should not be
> fixed in this specific document. (and I'd debate how they should be fixed,
> but that's another topic)
>

That's not a relevant analogy and you know it. :)
3261 was an update for the base draft of SIP, upon which everything else  was dependent, for all intents and purposes.  Are you claiming this info draft is of that type?  Will the changes we make in here apply to all other RFCs, or all other message types, which normatively reference 3261 for their mechanics?  Hardly.  Do we need to fix all known issues of RFC 3261 and all known problems of all its extensions which could possibly occur in an INFO message transaction, simply because they can happen in an INFO and this INFO update happens to be on our plate right now?  Because this multi-part thing is only like #32 on the Billboard top-100 list of rfc3261 problems.

This is an update to the INFO RFC, to address known problems with INFO - and in particular the problem of support-negotiation and message context.  If you're claiming its scope is broader, we have a big disconnect, because that was not my understanding of WG consensus for this work.

For example, I don't think we need to define how to make RFC 4474 work for INFO if it crosses B2BUA's.  That's a general problem for all messages. (nevermind the fact we can't agree on a solution)  Nor do I think we need to copy text from draft-ietf-sip-ipv6-abnf-fix into this draft, even though that applies to INFO, because that draft addresses problems for all message types.

There's nothing "special" about this multi-part issue for INFO over any other request method.

-hadriel

---

From: Hadriel Kaplan <[email-masked]>
Date: Thu, 4 Dec 2008 01:33:56 -0500

> multiple parts figures out how to process it.

Right, so that has two clear aspects to it:
1) Where do we solve it.
2) How do we solve it.

I assert that every issue raised so far on this thread with respect to multiple body parts has been equally applicable to most if not all SIP message types.  No one has refuted that assertion as far as I can tell.

I claim, therefore, that the answer to (1) is: in a separate draft which applies to all messages.  Otherwise we run the risk that (a) we don't solve it the same way, and (b) we delay this draft, and (c) we create a case where someone fixes their handling for INFO multi-part bodies but not other message types because they only implemented this draft, and we end up with split UA personality disorder. :)

> solely on C-T, which is really wrong. So its obviously not clear now.

That is about aspect (2).  I agree with you completely that C-T is not the right answer, but I don't see what it has to do with this draft.  We shouldn't be defining a solution to the problem for *INFO*.  We should be updating INFO to fix what's broken in it now, and defining a solution for all messages in a separate draft (presumably the body-handling draft).

-hadriel

---

From: "Christer Holmberg" <[email-masked]>
Date: Thu, 4 Dec 2008 09:59:04 +0100

Hi,

I agree with Hadriel.

Regards,

Christer

> From: Hadriel Kaplan [mailto:[email-masked]] 
> Sent: 4. joulukuuta 2008 8:34
> To: Paul Kyzivat
> Cc: SIP List; Dean Willis; Christer Holmberg
> Subject: RE: [Sip] Multiple body-parts in one INFO
> 
> 
> 
> > Sent: Thursday, December 04, 2008 12:10 AM I just want it 
> to be clear 
> > under what circumstances you can use multiple body parts in 
> a message, 
> > and how a recipient of a message containing multiple parts 
> figures out 
> > how to process it.
> 
> I assert that every issue raised so far on this thread with 
> respect to multiple body parts has been equally applicable to 
> most if not all SIP message types.  No one has refuted that 
> assertion as far as I can tell.
> 
> I claim, therefore, that the answer to (1) is: in a separate 
> draft which applies to all messages.  Otherwise we run the 
> risk that (a) we don't solve it the same way, and (b) we 
> delay this draft, and (c) we create a case where someone 
> fixes their handling for INFO multi-part bodies but not other 
> message types because they only implemented this draft, and 
> we end up with split UA personality disorder. :)
> 
> 
> > Just in the thread we have already heard a explanation of doing it 
> > based solely on C-T, which is really wrong. So its 
> obviously not clear now.
> 
> That is about aspect (2).  I agree with you completely that 
> C-T is not the right answer, but I don't see what it has to 
> do with this draft.  We shouldn't be defining a solution to 
> the problem for *INFO*.  We should be updating INFO to fix 
> what's broken in it now, and defining a solution for all 
> messages in a separate draft (presumably the body-handling draft).
> 
> -hadriel
>

---

From: "Elwell, John" <[email-masked]>
Date: Thu, 04 Dec 2008 09:42:25 +0000

Hadriel,

I would like to agree with this. My only reservation is that if the
generic solution requires that each document that defines usage of a
body part in SIP needs to specify something additional (e.g., CID in a
header field), then we would need to come back and update the
Info-Events draft/RFC.

John 

> Sent: 04 December 2008 06:34
> To: Paul Kyzivat
> Cc: SIP List; Holmberg; [email-masked]; Dean Willis

---

From: "Christer Holmberg" <[email-masked]>
Date: Thu, 4 Dec 2008 11:48:09 +0100

Hi, 

>I would like to agree with this. My only reservation is that 
>if the generic solution requires that each document that 
>defines usage of a body part in SIP needs to specify 
>something additional (e.g., CID in a header field), then we 
>would need to come back and update the Info-Events draft/RFC.

I am not sure we do. We only need to e.g. allow generic-param in the
Info-Package header ABNF, and if needed someone can then in future
define (in a separate draft) a CID parameter for Info-Package.

Regards,

Christer

> Behalf Of 
> > > Sent: Thursday, December 04, 2008 12:10 AM I just want it to be 
> > > clear under what circumstances you can
> > use multiple
> respect to 
> > multiple body parts has been equally applicable to most if 
> not all SIP 
> > message types.  No one has refuted that assertion as far as I can 
> > tell.
> > 
> > I claim, therefore, that the answer to (1) is: in a separate draft 
> > which applies to all messages.  Otherwise we run the risk 
> that (a) we 
> > don't solve it the same way, and (b) we delay this draft, 
> and (c) we 
> > create a case where someone fixes their handling for INFO 
> multi-part 
> > bodies but not other message types because they only 
> implemented this 
> > draft, and we end up with split UA personality disorder. :)
> > 
> >

---

From: Paul Kyzivat <[email-masked]>
Date: Thu, 04 Dec 2008 09:14:36 -0500

I agree that there is nothing special about INFO in contrast to any 
other message that defines use of a body. (Well, there is *something* 
special about it - we are considering it after the body-handling draft.)

I think *every* draft that specifies the use of a body needs to specify 
how that body is identified.

The body-handling draft can clarify for all the preexisting RFCs, and it 
also gives the general framework that applies to new drafts too. That 
eases the burden of what needs to be in new drafts, but IMO *something* 
should be in each new draft. It can be as simple as saying that it 
consumes bodies of C-D "render". (We can continue to discuss if "render" 
is the best choice.)

Eric knows way more about mime than I do. He seems to think that our use 
of C-D is wrong, which is why I think he chose to use cid instead. I 
certainly think we should take his position seriously. I don't know what 
the best answer is here, but I think we ought to decide what we think 
the best practice is, and document it.

	Thanks,
	Paul

---

From: Eric Burger <[email-masked]>
Date: Sun, 7 Dec 2008 10:37:04 -0500

Everyone seems to think there needs to be a generic way of identifying  
body bits.

I do not see an obvious, generic way of doing this.

Thus for those out there who think there is a generic way of  
identifying body parts for SIP, please write text.

On Dec 2, 2008, at 4:02 AM, Gonzalo Camarillo wrote:

> given (i.e., send text if you think the draft should say something  
> about this ;o) )?
>
> Thanks,
>
> Gonzalo
>
> Eric Burger wrote:
>> Context, in the vein of Message-Context for e-mail (RFC 3458).   
>> Body-handling would specify generic SIP stacks to be aware that  
>> Content-Disposition is how you pair a body part with its intended  
>> use. Hope no one else wants Content-Disposition: render for  
>> anything else...
>> writers of extensions that add body parts to explicitly state how  
>> to address the relevant body part.
>> Message-Context into Content-Disposition.  Mea Culpa for not  
>> noticing it sooner.

---

From: Hadriel Kaplan <[email-masked]>
Date: Sun, 7 Dec 2008 14:45:12 -0500

[note: changing the thread to be consistent]

> Sent: Sunday, December 07, 2008 10:37 AM

I think the body-handling draft already does it, although maybe I'm reading into it what I want to and not what it really says.

You asked, so this email is long.  This is what I think is the way to do it...

:Executive summary: basically we let C-D of "render" mean render to the specific context of the message; we mandate future extensions which are not for that context disambiguate themselves, by not using a C-D of "render" or the other ones already in use, and that they can't use a C-T already used today either. (and that includes changing geoloc's C-T immediately)

:The Details:

Definitions:
User-context = the specific context defined by the method name, and package if it's a method which has a package sub-context (SUB/NOT/PUB/INF).  The target user is the user-context's app-layer.  For example an "application/dtmf-relay" body-part would want to be targeted to the user-context defined by the "dtmf" package in an INFO.

Method-only-context = the context defined by the method name alone, ignoring any package.  The target is the specific message processor/state-machine for that method, but for any/all packages/sub-contexts.  For example the Event and Subscription-State headers are for this context in a SUBSCRIBE.  For methods that don't have a package (INV/UPD/ACK/PRA/MSG), the method-only-context and user-context are the same.  So the "session" and "early-session" C-D's are really for a user-context, but it's the same context as method-only-context.  I don't know of any bodies which are currently only for a method-only-context.(?)  Nor am I convinced we even need this context to be defined separately.

All-messages-context = the context is just the SIP message processing rules common to all messages.  The target is the SIP message processor common to all SIP messages.  The mandatory SIP headers (Call-ID, To, From, etc.) are examples of things targeted for this context.  An AIB, geoloc, and maybe sipfrag(?) bodies are targets for this context.

Note on above: If you think of this as a layered model with an API, or better yet a class object model - basically the all-messages-context is for things needing to be handled/extracted in the base SIP message class, the method-only-context is for stuff to be handled in a derived class for a given method, and the user-context is for stuff to be handled by a derived class from that for a given package, which may just be the same class for some methods (INV/UPD/etc.).

Rules:
1) Any body-part with a C-D of "render", means to render it to the "user" - not the human user, but the *user-context*.  This lets us get backwards-compatibility for free, because a C-D of "render" is implicit and what current SIP messages actually have and UA's expect.  That C-D becomes the "default" so to speak, which it already is today.

2) Any package (event of info) can define additional C-D's that belong to it, just like they can define C-T's that they support.  I am not entirely thrilled with letting packages define C-D's, but some already do ("signal", for example).  If we'd rather just grandfather those and say no more that's fine.  ISTM that a package could get that semantic purpose information from within the boy content itself (in XML, for example) if it really needs such.  Methods already do too, like "session" or "early-session".  If we decide packages can have their own C-D's, then we need additional rules not to step on body parts for others, but I'll skip that for now.

3) Any body-part that is NOT for the user-context, for example a geoloc, needs to disambiguate itself from the rest, by using a C-D other than "render" or the ones already defined.  If it needs a sub-context other than the all-messages-context, or is in fact tied to a SIP header, then it needs to use CID, and a C-D of "by-reference".  I would in fact suggest that all future extensions which need to be for something other than the user-context MUST have a referencing SIP header and use a CID and a C-D of by-reference.

4) Furthermore, any future extension which is not for the user-context MUST NOT use any C-T currently defined in any RFC or WG draft for SIP, including already defined event-packages.  That sounds harsh, but that's what we need to do to get a very high degree of backwards-compatibility I think.  So this means you can't do a geoloc-type thing using "text/plain", for example, or really even "application/pidf+xml", which is what geoloc currently uses in its draft.  And body-handling or some other draft should list all such C-T's, so future extensions can know the list to avoid.  And if we want to just say no C-T currently define by IANA period, I'm fine with that too.  Note this does NOT prevent future SIP RFCs from using a C-T defined by such an extension as geoloc.  For example, if geoloc uses "application/foobar", then a future Event-package could use that too; because that future event package would normatively reference body-handling.

5) IF we need an option tag (and I do NOT think we do), then we should create one and only one tag right now, for the body-handling draft's logic.  Future extensions which are not for the user-context would then NOT need more option tags simply due to body-handling issues, but can use that generic one.  I would also put in some extreme language into the body-handling option tag about what it means to put such a thing in a Require header, to dissuade people from doing that.

6) If there are some already defined things which do not follow the above rules, we either (a) grandfather them into body-handling right now, or if they're not really in use, then either (b) deprecate or (c) replace them. (and I would vote for (b), fwiw)

-hadriel

---

From: Paul Kyzivat <[email-masked]>
Date: Mon, 08 Dec 2008 10:33:47 -0500

Hadriel,

There is good stuff in here. I've been trying to say some (not all) of 
the same things, but haven't done as good of a job of it.

I'll also observe that this is the discussion I was hoping would come 
out around the body-handling draft. I guess it was too abstract then, 
and took a specific use case to get people thinking about it.

More (a lot more) inline...

> All-messages-context = the context is just the SIP message processing rules common to all messages.  The target is the SIP message processor common to all SIP messages.  The mandatory SIP headers (…

I think this teasing apart of various processing contexts is very 
useful. It may need some tweaking, but certainly seems on the right 
track, and maybe well town the track. This is really an extension to the 
architectural model of sip, and we shouldn't discount its importance.

The C-Ds of "session" and "early-session" are unusual in that they can 
appear in a number of requests and responses. I guess these *could* be 
defned as user-context, or method-only-context, or all-messages-context. 
(Regardless of which context they are associated with, there need to be 
some special rules for how they can be used.)

Note that all of these can be in responses. Yet in the INFO case we 
aren't allowing use in responses. So again I think we have a *general* 
mechanism that may be used in requests and responses, and potentially 
special restrictions that are applied to particular cases.

There is another ugly special case that hasn't been mentioned: multipart 
bodies themselves. At least an outermost multipart/mixed needs to be 
handled as all-messages-context *by default* for backward compatibility. 
That means when it is C-D of "render", since that is the default for it.

I guess a multipart/mixed that has some other C-D need not be treated 
that way. E.g. there could be one with C-D of "by-reference", and some 
header that references it. But maybe that needs to be forbidden to 
ensure some existing app doesn't misinterpret it. But if it were 
forbidden, I don't know what someone would do if that is what they need.

> 1) Any body-part with a C-D of "render", means to render it to the "user" - not the human user, but the *user-context*.  This lets us get backwards-compatibility for free, because a C-D of "render"…

This seems right, at least for *outer* body parts. Once you get inside a 
multipart whose handling has already been determined by a C-D at that 
outer level, I'm not certain what to do with C-Ds that appear on the 
contained parts.

> 2) Any package (event of info) can define additional C-D's that belong to it, just like they can define C-T's that they support.  I am not entirely thrilled with letting packages define C-D's, but…

This seems to be building on Christer's proposal. Up to a point I think 
its probably ok. I was thinking that we didn't need to go this far, but 
maybe we do.

The notion of C-D is not unique to SIP, so there are C-D types out there 
that say nothing about their relationship to SIP. And of course there 
are C-Ds that we will define as being associated with the method-only or 
all-messages contexts.

So, I think a new C-D could be defined for use with a particular 
package. But to do so it would, I think, require an RFC. (Whatever the 
rules are for new C-D types.) Since we aren't going to require an RFC 
for info-packages, an info-package that needs a new C-D would still need 
an RFC. I also think an info-package could potentially specify that a 
particular (existing) C-D be associated with its user-context - as long 
as that C-D isn't associated with a message- or all-messages- context.

> 3) Any body-part that is NOT for the user-context, for example a geoloc, needs to disambiguate itself from the rest, by using a C-D other than "render" or the ones already defined.  If it needs a s…

I agree with this, for the most part.

IMO the key is that when a body part is referenced from a header, the 
*reference* defines one sort of processing for the body part. Generally 
speaking you don't want any *other* processing to happen to it based 
simply on its presence. The by-reference C-D is, IMO, really just a 
context that has no *implicit* processing based on its presence.

*In principle* there could be a body part that is referenced more than 
once, in which case it would be processed once for each reference. 
Similarly, there could be a body part that is present and intended to be 
processed based on its context, and there is *also* a reference to it 
that should be processed based on the reference. This is not a likely 
case by any means, but I think it is cleaner to separate the two 
mechanisms. Using the same body for both then just falls out. An 
(unlikely and generally nonsensical) example might be a PUBLISH request 
containing a presence body, that also has a Geoloc header referring to 
the same body part.

To summarize my point: the C-D of a body part provides a way to identify 
a context that in turn defines some processing to be performed on that 
part. A cid-reference to a body part *also* provides a way to define 
some processing to be performed on a part. Either, both, or neither may 
apply to any given body part. (The *neither* is important, because there 
may be a reference in an optional header that isn't processed by the 
recipient.)

> 4) Furthermore, any future extension which is not for the user-context MUST NOT use any C-T currently defined in any RFC or WG draft for SIP, including already defined event-packages.  That sounds harsh, but that's what we need to do to get a very high degree of backwards-compatibility I think. 

I agree it sounds harsh. IMO it is *too* harsh. That may mean I can't 
include an application/sdp in a MESSAGE, or in an info-package, even if 
it carefully *doesn't* use C-D of "session".

I think we should assume that complying UAs *should* be using C-D 
already to disambiguate, and they are simply broken if they don't.

> So this means you can't do a geoloc-type thing using "text/plain", for example, or really even "application/pidf+xml", which is what geoloc currently uses in its draft. 

This is a poster child for the problem. AFAIK "application/pidf+xml" is 
appropriate for its use, and forcing it to define a new C-T for the same 
thing in order to get around this would be a pain. At least in this case 
the possibility of conflict with non-conforming implementations isn't 
great because Geoloc isn't likely to be needed in PUBLISH or NOTIFY 
where conflicts might be possible.

But Geoloc should use "by-reference" when it doesn't want the body 
processed other than as a result of the header reference.

> And body-handling or some other draft should list all such C-T's, so future extensions can know the list to avoid.  And if we want to just say no C-T currently define by IANA period, I'm fine with that too.  Note this does NOT prevent future SIP RFCs from using a C-T defined by such an extension as geoloc.  For example, if geoloc uses "application/foobar", then a future Event-package could use that too; because that future event package would normatively reference body-handling.

I agree we should further discuss the backward compatibility issues. But 
I think we need not / should not be quite so resrictive.

> 6) If there are some already defined things which do not follow the above rules, we either (a) grandfather them into body-handling right now, or if they're not really in use, then either (b) deprec…

I agree with this.

	Thanks,
	Paul

---

From: Hadriel Kaplan <[email-masked]>
Date: Mon, 8 Dec 2008 12:59:39 -0500

[breaking this up 'cause it's getting long in the tooth]

> Sent: Monday, December 08, 2008 10:34 AM
>

Right but I think those C-Ds only have meaning in a user-context: one for INVITE, UPDATE, ACK, and PRACK.  No?  I wasn't implying that a C-D or body-part could not apply to the user-context of multiple methods.  Just that the "target" of the body was the user-context.

> special restrictions that are applied to particular cases.

Right, but if we don't allow INFO to carry app-level responses in the INFO's response, then it's actually ok because it's really the user-context layer making that decision, and user-context is already method-specific.  In other words, if you think of it as that class object hierarchy way, the base message class doesn't need to know/care whether INFO responses can or cannot have user-context bodies - it always assumes yes.  Only the derived class for an INFO needs to know.

(and BTW I'm not sure there is general consensus yet on whether an INFO response can contain a body or not - PUBLISH can, for example)

> That means when it is C-D of "render", since that is the default for it.

True, good point.  We can just grandfather that as an exception to the rule and say "multipart/mixed" needs to be checked for C-Ds internally to figure out which parts belong to what, it its C-D is "render".

-hadriel

---

From: Paul Kyzivat <[email-masked]>
Date: Tue, 09 Dec 2008 09:50:37 -0500

> Right but I think those C-Ds only have meaning in a user-context: one for INVITE, UPDATE, ACK, and PRACK.  No?  I wasn't implying that a C-D or body-part could not apply to the user-context of mult…

I'm still having trouble on the fringes defining user-context.
In this case its something like dialog-usage context. That would work 
for events too, since each has its own dialog-usage. It would also, I 
think, work for *legacy* INFO.

But it doesn't work for info-packages. All the info packages are within 
a single invite-dialog-usage. Yet each has its own context.

So getting all the terminology to work right is tricky. But I think I 
agree with the gist of what you are saying.

> Right, but if we don't allow INFO to carry app-level responses in the INFO's response, then it's actually ok because it's really the user-context layer making that decision, and user-context is alr…

OK.

> True, good point.  We can just grandfather that as an exception to the rule and say "multipart/mixed" needs to be checked for C-Ds internally to figure out which parts belong to what, it its C-D is…

OK. I think we agree. Again it may be a little tricky to scope the 
exception properly.

	Thanks,
	Paul

---

From: Gonzalo Camarillo <[email-masked]>
Date: Tue, 16 Dec 2008 11:04:34 +0200

Hi Hadriel,

 > I think the body-handling draft already does it, although maybe I'm
 > reading into it what I want to and not what it really says.

the draft already talks about contexts:

http://tools.ietf.org/html/draft-ietf-sip-body-handling-05#section-8.1

I would like to agree on a concrete way forward. Do you think we should 
add something to the body handling draft? Maybe expand the information 
on contexts? Maybe provide guidelines for extension developers so that 
they take them into account when defining new extensions?

Thanks,

Gonzalo

---

From: Hadriel Kaplan <[email-masked]>
Date: Wed, 17 Dec 2008 13:11:51 -0500

I think that's really a question for the others (Paul, Dean, Eric).  I interpreted body-handling to address the issue already, but maybe not the backward compatibility issue.

Also, section 8.1. talks about the context being defined by the method, C-D and C-T.  It should probably mention that the Event package for SUB/NOT/PUB and soon the Info-Event package narrows the context further.  And I'm not sure that C-T has anything to do with defining a context.

-hadriel

> From: Gonzalo Camarillo [mailto:[email-masked]]
> Sent: Tuesday, December 16, 2008 4:05 AM
> To: Hadriel Kaplan
> Cc: Eric Burger; SIP List
> Subject: Body handling - Contexts WAS (Re: [Sip] multiple bodies in any
> SIP message)
>
> Hi Hadriel,
>
> Eric
> > :Executive summary: basically we let C-D of "render" mean render to the
> specific context of the message; we mandate future extensions which are
> not for that context disambiguate themselves, by not using a C-D of
> "render" or the other ones already in use, and that they can't use a C-T
> already used today either. (and that includes changing geoloc's C-T
> immediately)
> >
> > :The Details:
> >
> > Definitions:
> > User-context = the specific context defined by the method name, and
> package if it's a method which has a package sub-context
> (SUB/NOT/PUB/INF).  The target user is the user-context's app-layer.  For
> example an "application/dtmf-relay" body-part would want to be targeted to
> the user-context defined by the "dtmf" package in an INFO.
> >
> > Method-only-context = the context defined by the method name alone,
> ignoring any package.  The target is the specific message processor/state-
> machine for that method, but for any/all packages/sub-contexts.  For
> example the Event and Subscription-State headers are for this context in a
> SUBSCRIBE.  For methods that don't have a package (INV/UPD/ACK/PRA/MSG),
> the method-only-context and user-context are the same.  So the "session"
> and "early-session" C-D's are really for a user-context, but it's the same
> context as method-only-context.  I don't know of any bodies which are
> currently only for a method-only-context.(?)  Nor am I convinced we even
> need this context to be defined separately.
> >
> > All-messages-context = the context is just the SIP message processing
> rules common to all messages.  The target is the SIP message processor
> common to all SIP messages.  The mandatory SIP headers (Call-ID, To, From,
> etc.) are examples of things targeted for this context.  An AIB, geoloc,
> and maybe sipfrag(?) bodies are targets for this context.
> >
> > Note on above: If you think of this as a layered model with an API, or
> better yet a class object model - basically the all-messages-context is
> for things needing to be handled/extracted in the base SIP message class,
> the method-only-context is for stuff to be handled in a derived class for
> a given method, and the user-context is for stuff to be handled by a
> derived class from that for a given package, which may just be the same
> class for some methods (INV/UPD/etc.).
> >
> > Rules:
> > 1) Any body-part with a C-D of "render", means to render it to the
> "user" - not the human user, but the *user-context*.  This lets us get
> backwards-compatibility for free, because a C-D of "render" is implicit
> and what current SIP messages actually have and UA's expect.  That C-D
> becomes the "default" so to speak, which it already is today.
> >
> > 2) Any package (event of info) can define additional C-D's that belong
> to it, just like they can define C-T's that they support.  I am not
> entirely thrilled with letting packages define C-D's, but some already do
> ("signal", for example).  If we'd rather just grandfather those and say no
> more that's fine.  ISTM that a package could get that semantic purpose
> information from within the boy content itself (in XML, for example) if it
> really needs such.  Methods already do too, like "session" or "early-
> session".  If we decide packages can have their own C-D's, then we need
> additional rules not to step on body parts for others, but I'll skip that
> for now.
> >
> > 3) Any body-part that is NOT for the user-context, for example a geoloc,
> needs to disambiguate itself from the rest, by using a C-D other than
> "render" or the ones already defined.  If it needs a sub-context other
> than the all-messages-context, or is in fact tied to a SIP header, then it
> needs to use CID, and a C-D of "by-reference".  I would in fact suggest
> that all future extensions which need to be for something other than the
> user-context MUST have a referencing SIP header and use a CID and a C-D of
> by-reference.
> >
> > 4) Furthermore, any future extension which is not for the user-context
> MUST NOT use any C-T currently defined in any RFC or WG draft for SIP,
> including already defined event-packages.  That sounds harsh, but that's
> what we need to do to get a very high degree of backwards-compatibility I
> think.  So this means you can't do a geoloc-type thing using "text/plain",
> for example, or really even "application/pidf+xml", which is what geoloc
> currently uses in its draft.  And body-handling or some other draft should
> list all such C-T's, so future extensions can know the list to avoid.  And
> if we want to just say no C-T currently define by IANA period, I'm fine
> with that too.  Note this does NOT prevent future SIP RFCs from using a C-
> T defined by such an extension as geoloc.  For example, if geoloc uses
> "application/foobar", then a future Event-package could use that too;
> because that future event package would normatively reference body-
> handling.
> >
> > 5) IF we need an option tag (and I do NOT think we do), then we should
> create one and only one tag right now, for the body-handling draft's
> logic.  Future extensions which are not for the user-context would then
> NOT need more option tags simply due to body-handling issues, but can use
> that generic one.  I would also put in some extreme language into the
> body-handling option tag about what it means to put such a thing in a
> Require header, to dissuade people from doing that.
> >
> > 6) If there are some already defined things which do not follow the
> above rules, we either (a) grandfather them into body-handling right now,
> or if they're not really in use, then either (b) deprecate or (c) replace
> them. (and I would vote for (b), fwiw)
> >
> > -hadriel