Re: multiple bodies in any SIP message

Hadriel Kaplan wrote:
> With regards to how to handle multiple body parts in any SIP message,
> I believe the issue we're concerned with is how to handle body-parts
> that are not for the actual context of the SIP message, in a
> backwards-compatible way, right?

Sort of. 3261 already introduced the possibility for some of them - 
'alert' and 'icon' bodies, as well as S/MIME.

Many implementations likely simply never bothered to consider any of 
that. And those that did may have used a variety of techniques to 
identify the parts they care about for particular purposes.

So "backwards-compatible" depends a lot of what has already been 
implemented in the wild, not just what the specs say.

IMO, if you read 3261 carefully, then you need to sort out most of the 
existing use cases based on the Content-Disposition. However there is 
great ambiguity about how to interpret multipart bodies themselves if 
they lack a C-D.

> In other words, the context for bodies by default is based on their
> message method type, and possibly package if the method type has packages
> (SUB/NOT/PUB, and now INFO).  And since for 3261 the Content-Disposition's
> default means "render" (unless C-T is app/sdp), then no C-D means render -
> where "render" has different meanings based on the context too.  For

The above is a reasonable interpretation, and consistent with the 
body-handling draft.

> MESSAGE/INVITE/BYE it's basically render to the user in some fashion; for

This certainly seems to be the intuitive interpretation and its hard to 
find a reason not to follow it.

> package ones it's render to the package application, which effectively is
> the "user" of the message.  Right?

I think we are *forced* to take this interpretation for the existing 
uses in order to have any sort of backward compatibility. But IMO it is 
a perversion of "render".

> So ISTM that the body-handling draft does that. 

Yes. But I think we should consider the existing uses to be 
"grandfathered", rather than establishing a precedent for "render" in 
future uses. (That point may be debatable.)

> For new extensions going
> forward it would be done with a Content-ID and a C-D of "by-reference" in
> MIME, with a SIP header using a CID. 

We have two choices that the extension can make. It can do as you say. 
Or it can base things on a content-disposition type. If so it will need 
to define what that means in the contexts it covers.

For instance some new FOOBAR method might require a body in some cases 
and specify:
- the C-D for *its* body is "foobar"
- or the the C-D for its body is "render", and that such body part(s?)
   should be "rendered" by carrying out some specified processing
- or it could introduce a new header, which references the body part,
   which then has a C-D of "by-reference".

*In principle* an extension could simply define a new C-D, and the 
processing that should occur when a part with the disposition is 
encountered, independent of the method it is in. That would be 
*relatively* safe if it was always passed with handling=optional. But 
that might not work out so well in practice.

An extension *header* that needs to reference a body is more 
constrained. Based on the body-handling draft, the body part it 
references can be of any C-D, but it ought to be "by-reference" unless 
the constructor of the message wants the same body part to be processed 
once according to its reference, and again according to whatever 
implicit processing should be done based on its disposition.

There are other considerations if one body part references another body 
part.

The point is that, future extensions should clearly specify how this 
should be done.

> For older extensions it's handled by
> the option tags they already define, to make sure the recipient understands
> the extension and thus its additional body part's context. (I don't like
> that, but that's life)  And it's only really a problem for cases where the
> content-type collides with something valid for the message's context/package.

The claim that its only a problem when the content-type collides is 
problematic. That implies a certain algorithm for deciding how to 
process body parts. Not an obvious one, or one that is written down 
anywhere.

IMO C-D takes precedence over C-T for deciding how to process a body 
part. If I get a body part with a C-D of "render" and a C-T of 
application/SDP, then I should not process it as an offer/answer. Rather 
I should be looking for how to "render" it based on the definition of 
render for this method. If I don't know how to render an application/sdp 
body (quite likely) then it is just erroneous.

Now maybe my opinion is wrong. But if so, then we should define whatever 
rules we think there should be.

> So I'm back to: this is no different for INFO.  INFO has a context, we're
> adding a sub-context with Info-Package to fix collisions of same content-types
> for different uses, and any SIP extension going forward uses a CID and
> content-id and C-D of 'by-reference' if it's not tied to the message's context.

As Eric proposed it, the new info-packages don't depend on the INFO 
context, since they use CID references. Only the legacy INFO depends on 
the INFO context.

I think it remains an open issue if that is the way we want it.

> The Info draft only needs to reference the body-handling draft, call out the
> fact that INFO and its Info-Package creates a context, and a quick reminder on
> what that means.  We can then pull out all the current text about bodies in the
> draft, including the cid parameter and such, and move on to more interesting
> things like responses and actually defining packages. :)

If the Info-Package header is to reference the body part using cid, then 
  the draft can't avoid mentioning that.

And I think it needs to be more explicit about how body parts relate to 
legacy info - explaining that there is a special meaning of "render" for 
legacy INFO messages.

Then there is the question of what "render" means for an INFO that 
carries an info-package. My guess is that we don't want to allow a 
single INFO to have both an Info-Package *and* a legacy INFO body. So I 
think it will be needful to define that in a new INFO, bodies of 
disposition "render" (other than multipart/mixed) will be ignored.

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