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
