Subject: Re: [Sip] WGLC for draft-ietf-sip-body-handling

From: Adam Roach <[email-masked]>
Date: Wed, 02 Jul 2008 15:33:23 -0500

This document largely looks good to me. I have only one substantive 
comment to make.

Section 8 has the following text:

>    The situation with 'multipart/related' is similar.  Per [RFC2387], a
>    UA processing a 'multipart/related' body processes it as a compound
>    object ignoring the disposition types of the body parts within it.

This is, indeed, consistent with RFC 2387. However, RFC2387 is geared 
towards content in email messages. The constraint, in that context, 
makes a lot of sense -- it would be bizarre to, for example, have an 
HTML page (disposition inline) with subservient images tagged as 
attachments. In an email context, it makes sense to treat the whole 
multipart/related document as monolithic.

When we consider the kinds of things we're doing with 
content-disposition in SIP lately, this logic falls apart. We're no 
longer simply indicating whether something should be shown as part of an 
email or saved as a local file; we're indicating fairly complex 
semantics that help disambiguate uses of MIME types that might otherwise 
be confused with each other -- see, for example, my message a few hours 
ago talking about how we disambiguate ad-hoc list subscriptions from 
XCAP diff subscriptions (which use the same MIME type by default).

In that context, the use of Content-Disposition on individual parts of a 
multipart/related document makes a *huge* amount of sense. I think the 
sip-body-handling document needs to take into consideration the needs of 
the SIP protocol in this case, rather than reinforcing restrictions from 
RFC 2387 that really only make sense for email.

/a
_______________________________________________
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: Cullen Jennings <[email-masked]>
Date: Wed, 2 Jul 2008 22:47:41 -0700

This document is good and looks ready to go to IESG.

One thing I think should be changed  - it says "Consequently, UAs MUST  
use the binary transfer encoding for binary payloads in SIP."
I actually believe that the binary transfer encoding is the right  
choice for all payloads regardless of if they are binary or not. (It's  
not like you are going to base64 encode the some ascii body). All  
binary means is the bits will get transfered without being molested -  
which is alway true for SIP since all the body handling is 8 bit safe.

So the change I would suggest would be to simply change "for binary  
payloads" to "for payloads". I think we had consensus on this in a HUM  
in a WG meeting back in 2004. A more detailed explanation of why think  
this is in

http://www.softarmor.com/wgdb/docs/draft-jennings-sip-mime-02.txt

Cullen <with my individual contributor hat on>

On Jun 25, 2008, at 9:06 AM, Dean Willis wrote:

>
> I'm pleased to announce a working group last call for the "Body  
> Handling" draft:
>
> http://www.ietf.org/internet-drafts/draft-ietf-sip-body- 
> handling-02.txt
>
> This draft is intended for the Standards Track.
>
> The only minor issue I'm aware of is an outdated reference that  
> should have no impact on the review:
>
> == Outdated reference: A later version (-08) exists of draft-ietf- 
> mmusic-file-transfer-mech-06
>
> Please review the draft carefully and post your comments back to the  
> list and author.
>
> I'd like to conclude this WGLC period by July 11, 2008.
>
> Ok everybody, get busy reviewing!
>
> --
> Dean
>
>

---

From: Gonzalo Camarillo <[email-masked]>
Date: Fri, 04 Jul 2008 10:00:37 +0300

Hi Cullen,

I would still like to stress that, even if the payload is binary, you 
still need to use the binary transfer encoding. What about the following 
change:

OLD:
   Consequently, UAs MUST use the binary transfer encoding for binary
   payloads in SIP.

NEW:
   Consequently, UAs MUST use the binary transfer encoding for all
   payloads in SIP, including binary payloads.

Cheers,

Gonzalo

Cullen Jennings wrote:
> I actually believe that the binary transfer encoding is the right choice 
> for all payloads regardless of if they are binary or not. (It's not like 
> you are going to base64 encode the some ascii body). All binary means is 
> the bits will get transfered without being molested - which is alway 
> true for SIP since all the body handling is 8 bit safe.
> 
>> http://www.ietf.org/internet-drafts/draft-ietf-sip-body-handling-02.txt
>>
>> The only minor issue I'm aware of is an outdated reference that should 
>> have no impact on the review:
>>
>> == Outdated reference: A later version (-08) exists of 
>> draft-ietf-mmusic-file-transfer-mech-06
>>

---

From: Gonzalo Camarillo <[email-masked]>
Date: Fri, 04 Jul 2008 10:26:21 +0300

Hi Adam,

the problem with redefining stuff that was already defined in email is 
that we may lose the ability to use it as originally defined. For 
example, if I want to send you a MESSAGE request with the html page in 
your example (which includes images), I would probably use 
multipart/related (as in the email in your example). If we redefine 
multipart/related, we may face problems because I may not be able to use 
it like that any longer.

In any case, do we have any existing extension that sends 
multipart/related in a different context than the one above?... because 
we may not need to use it in other contexts after all.

The real question is whether or not we need the ability to have 
extensions that use multipart/related where the content disposition of 
the multipart/related plus the content types of the body parts are not 
enough to understand how to process the extension.

The thing is that, when I talked with the apps folks (they reviewed the 
draft), they stressed the fact that they do not like it when we redefine 
stuff that they had previously defined because they expect it to work in 
a certain way when it actually works in a different way. The guideline 
we got was that, if we need to define something new, we should really do 
that instead of redefining an old mechanism. So, if we really have the 
requirement above, maybe it is better to define something new than to 
reuse multipart/related.

Cheers,

Gonzalo

---

From: Adam Roach <[email-masked]>
Date: Fri, 04 Jul 2008 10:00:19 -0500

On 07/04/2008 02:26 AM, Gonzalo Camarillo wrote:
> multipart/related, we may face problems because I may not be able to 
> use it like that any longer.

I'm not proposing that we redefine it -- I'm proposing that we relax a 
restriction that makes sense for email but not for SIP.

> multipart/related in a different context than the one above?... 
> because we may not need to use it in other contexts after all.

RFC 4662 does.

The need for clear Content-Disposition differentiation is highlighted by 
the exchange Robert and I had a few days ago (subject line "Possible 
semantic confusion w/ bodies in subscribes"); in particular, look at the 
examples in 
<http://www.ietf.org/internet-drafts/draft-roach-sip-list-subscribe-bodies-00.txt>. 
If we can't put content dispositions on the individual parts of 
multipart/related documents, the disambiguation of 
application/resource-lists+xml bodies becomes tricky.

> enough to understand how to process the extension.

I believe that the draft I cite above provides an existence proof of a 
case in which that is necessary.

> The thing is that, when I talked with the apps folks (they reviewed 
> the draft), they stressed the fact that they do not like it when we 
> redefine stuff that they had previously defined because they expect it 
> to work in a certain way when it actually works in a different way. 
> The guideline we got was that, if we need to define something new, we 
> should really do that instead of redefining an old mechanism. So, if 
> we really have the requirement above, maybe it is better to define 
> something new than to reuse multipart/related.

In practice, the thing that SIP has redefined here to be substantially 
different from MIME isn't the use of multipart/related -- it's the use 
of Content-Disposition. Because Content-Disposition really does mean 
something quite different in SIP than it does in email, the 
email-specific restrictions on it just don't make any sense here. If we 
could go back and do it over, I would suggest that the proper thing to 
do would be defining a new MIME header -- something like 
"Content-Context" -- but that ship has sailed.

/a

>> longer simply indicating whether something should be shown as part of 
>> an email or saved as a local file; we're indicating fairly complex 
>> semantics that help disambiguate uses of MIME types that might 
>> otherwise be confused with each other -- see, for example, my message 
>> a few hours ago talking about how we disambiguate ad-hoc list 
>> subscriptions from XCAP diff subscriptions (which use the same MIME 
>> type by default).
>>
>> In that context, the use of Content-Disposition on individual parts 
>> of a multipart/related document makes a *huge* amount of sense. I 
>> think the sip-body-handling document needs to take into consideration 
>> the needs of the SIP protocol in this case, rather than reinforcing 
>> restrictions from RFC 2387 that really only make sense for email.
>>
>> /a
>

---

From: Paul Kyzivat <[email-masked]>
Date: Fri, 04 Jul 2008 14:28:59 -0400

Adam,

I have to admit that I still haven't grokked the distinction between 
multipart/mixed and multipart/related. I gather this discussion is 
specific to related, not mixed. So would the issues you raise not be of 
concern if we used mixed rather than related to carry the multiple parts?

	Thanks,
	Paul

---

From: Adam Roach <[email-masked]>
Date: Mon, 07 Jul 2008 11:01:44 -0500

On 7/4/08 1:28 PM, Paul Kyzivat wrote:
> multipart/mixed and multipart/related.

 From a data structures perspective, multipart/mixed is an unordered 
set, while multipart/related is a tree. The difference is actually 
pretty radical.

> I gather this discussion is specific to related, not mixed. So would 
> the issues you raise not be of concern if we used mixed rather than 
> related to carry the multiple parts?

You're throwing the baby out with the bathwater. This issue would go 
away, but the solution would be tortured. We would have to add semantics 
on top of multipart/mixed that, when we were done, would make it 
effectively identical to multipart/related.

If I may draw an analogy -- SDP was originally developed for use in 
things like SAP (RFC 2974) and SIP for multicast sessions. As such, it 
made perfect sense to normatively require the inclusion of contact 
information in SDP (RFC 2327, section 6: "Either an email field or a 
phone field must be specified").

However, when we started doing point-to-point SIP sessions, this 
constraint stopped making much sense. The person responsible for the 
session is the person you're talking to -- mandating the inclusion of 
additional contact information didn't make sense anymore.

Now, we could have elected to skirt this problem by observing, for 
example, that FTP (RFC 959) already contains a means for establishing 
connections -- all we need to do is add syntax for conveying media 
types, codecs, etc. It certainly would be an *effective* way of skirting 
the restriction in RFC 2327 that we don't like.

Or, we could have observed that RFC 2327 gets us well over 99% of the 
way to where we want to go -- save for this one restriction that makes 
no sense in the context we're trying to use it in -- and just use it. 
Happily, this is what we did.

/a

---

From: Paul Kyzivat <[email-masked]>
Date: Mon, 07 Jul 2008 13:03:13 -0400

Adam,

> set, while multipart/related is a tree. The difference is actually 

I just went and reviewed RFC2387 *again*. I think my problem with it is 
that I don't know where it was *intended* to be used. It clearly wasn't 
*intended* to be used with SIP.

Now that I look again in the context of this discussion, it seems, IMO, 
to be *inappropriate* for many cases where we are likely to have 
multiple body parts in a sip message.

Consider the case of an INVITE that has SDP and a body part referenced 
by an Alert-Info header. These two are not related at all, and neither 
is the "starting" body part. They are each independently related to the 
sip message itself.

So, what uses do you have in mind for multipart/related? Without some 
specific and tangible ones, it is hard to justify making sip-specific 
interpretations of it in this general document.

	Thanks,
	Paul

---

From: Adam Roach <[email-masked]>
Date: Mon, 07 Jul 2008 13:22:33 -0500

On 7/7/08 12:03 PM, Paul Kyzivat wrote:
> I just went and reviewed RFC2387 *again*. I think my problem with it 
> is that I don't know where it was *intended* to be used. It clearly 
> wasn't *intended* to be used with SIP.
>
> Now that I look again in the context of this discussion, it seems, 
> IMO, to be *inappropriate* for many cases where we are likely to have 
> is the "starting" body part. They are each independently related to 
> the sip message itself.
>

RFC 4662.

In a closely related vein (the one that shows where Content-Disposition 
may be necessary), see also draft-roach-list-subscribe-bodies-00.

/a

---

From: Paul Kyzivat <[email-masked]>
Date: Mon, 07 Jul 2008 15:09:17 -0400

OK Adam. I had the mis-impression that you were advocating the use of 
multipart/related *instead* of multipart/mixed for those cases where the 
sip message just happened to contain multiple parts.

The examples you cite seem to be cases where there really is a 
relationship between the parts. So I have no problem with what you are 
proposing there.

Regarding the issue under discussion here, of the applicability of 
Content-Disposition to parts of a multipart/related, I'm going to 
reserve judgment. We are currently using Content-Disposition differently 
than it is used in mail, and some of the needs to satisfies still seem 
to exist with multipart/related. But I just don't know enough about the 
nuances of mime to sort out the other side of the argument.

	Thanks,
	Paul

---

From: [email-masked]
Date: Mon, 7 Jul 2008 23:28:05 -0400

Unfortunately, I don't particularly like this document, as it gives a
lot of discussion of various cases, but doesn't present a clear and
unified description of the semantics of multipart body part handling.
So much so that it would take me a long time to verify that the
various rules in the document covered all cases and were not mutually
contradictory.

In a lot of situations, it seems that the rule is "the designer of the
software should be able to figure out what is meant in each particular
situation".  Which inevitably leads to "No, he can't." or rather "He
will think he can, but he'll get it wrong."

But I don't know that we have time to fix that now.

More specifically:

There seems to be no clear statement that "required" and "optional"
mean "required/optional for successful processing of the enclosing
body/body part" -- after all, the enclosing body part may itself be
optional, so "required" and "optional" can only be relative to the
necessity of understanding of the enclosing body part.  Or
alternatively, maybe we don't want this degree of complexity.  But to
avoid it, we would have to ban nested multiparts, or at least, all but
certain specific usages of nested multiparts.

There are a lot of mentions of the 415 response in passing.  As far as
I can tell, it is expected that the Accept header in a 415 response
will contain all the media types that the UA understands *in any
context whatsoever*, but that doesn't seem to be stated clearly
anywhere.  (E.g., it would be reasonable for a designer to think that
the Accept should only list media types understood for the particular
request method.)

In section 5.1 the description is not really correct, as the "This
way..." sentence doesn't follow from the preceding sentence.  A better
phrasing is:

   Each body part within a 'multipart/alternative' carries an
   alternative version of the same information.  The body parts SHOULD
   be ordered in increasing richness of representation of the
   information.  More exactly, the UAS MUST process the last body part
   that it understands, and the UAC MUST order the body parts so
   that the this rule causes the UAS to behave as the UAC desires.

In section 6.1, I see:

   If the parameter [...] has the value 'required', the UAS returns a
   415 (Unsupported Media Type) response.

This is incorrect.  Of course, what is meant is, "If the parameter has
the value 'required', and the body part must be processed in order to
process the entire SIP message, then the UAS returns...", but that's
not what it says.

In section 6.2 there is various discussion of the handling parameter
for parts within a multipart/alternative body part.  But the
discussion could be made clearer by starting with the statement that
the handling parameter is not significant: "The handling parameters of
the parts of a multipart/alternative part are ignored in processing
(the processing is determined by the type multipart/alternative), and
SHOULD be set to optional."  Or should we just omit 'handling' on
parts of a multipart/alternative?

The sentence before that one is peculiar: "If the handling of a
'multipart/alternative' body is required, the UA MUST set the
'handling' parameter of the 'multipart/alternative' body to
'required'."  This seems tautological -- why is it stated?

In section 7.3, it is stated that "If the SIP message contains a
reference to the body part, the UA processes the body part according
to the reference.", but in the next paragraph, it says "Note that,
following the rules in [RFC3204], if a UA does not understand a body
part whose handling is optional, it ignores it."  But these are
contradictory if the part containing the reference is required but the
part that is referenced is marked optional.  In effect, the referenced
part becomes required (or rather, required under any circumstances
where the referencing part is required).  This can conflict with the
desire that all parts of a multipart/alternative are effectively
optional within that part.  What is really intended here?

Dale

---

From: Gonzalo Camarillo <[email-masked]>
Date: Thu, 10 Jul 2008 23:09:08 +0300

Hi Adam,

this is the paragraph we are talking about (in Section 8):

    The situation with 'multipart/related' is similar.  Per [RFC2387], a
    UA processing a 'multipart/related' body processes it as a compound
    object ignoring the disposition types of the body parts within it.
    However, UAs that do not understand 'multipart/related' will treat it
    as 'multipart/mixed'.  These UAs will not be able to process the body
    as a compound object.  Instead, they will process the body parts
    according to their disposition type.

What you are asking for is not to ignore the disposition types of the 
body parts within the multipart/related. If we go down that path, we 
will need to describe how multipart/related will be different from 
multipart/mixed. That is, we would need to clarify what we mean by 
"processing the body as a compound object" if the body parts are still 
processed per their respective disposition types, as if they were in a 
multipart/mixed instead of in a multipart/related.

Following the "propose text" principle, could you please edit the 
paragraph above so that we have a concrete proposal on how to describe 
the processing of multipart/related bodies and how it would differ from 
the processing of multipart/mixed bodies?

Thanks,

Gonzalo

Paul Kyzivat wrote:
>>>>> I have to admit that I still haven't grokked the distinction 
>>>>> between multipart/mixed and multipart/related.
>>>>
>>> Consider the case of an INVITE that has SDP and a body part 
>>> referenced by an Alert-Info header. These two are not related at all, 
>>> and neither is the "starting" body part. They are each independently 
>>> related to the sip message itself.
>>>
>> In a closely related vein (the one that shows where 
>> Content-Disposition may be necessary), see also 
>> draft-roach-list-subscribe-bodies-00.
>>
>> /a
>>

---

From: Adam Roach <[email-masked]>
Date: Thu, 10 Jul 2008 18:17:25 -0500

On 7/10/08 3:09 PM, Gonzalo Camarillo wrote:
> the processing of multipart/related bodies and how it would differ 
> from the processing of multipart/mixed bodies?

It's a bit wordy, but my first attempt at addressing the situation came 
out like this:

    The situation with 'multipart/related' is similar.  In [RFC2387],
    email clients processing a 'multipart/related' body are expected to
    processes it as a monolithic object, ignoring the disposition types
    of the body parts within it. Because SIP's use of
    Content-Disposition varies markedly from that of email, this
    constraint may not always make sense in SIP. Authors of SIP
    extensions making use of 'multipart/related' bodies are advised to
    explicitly address the handling of Content-Disposition on
    'multipart/related' body parts.  Authors wishing to make use of
    'multipart/related' bodies should keep in mind that UAs that do not
    understand 'multipart/related' will treat it as 'multipart/mixed',
    including the handling of Content-Disposition headers on body parts.

/a

---

From: Paul Kyzivat <[email-masked]>
Date: Thu, 10 Jul 2008 19:43:57 -0400

Adam,

Its pretty unsatisfying to end up with the manner of processing C-D 
varying from one use of multipart/related to another. This seems like 
the kind of thing that one would like to implement *once*.

If it is important to take C-D into account when processing 
multipart/related, can we define exactly *how* it should be taken into 
account? Does it supercede that of the container? Does it get merged 
with that of the container? Does it get merged (in a well defined way) 
with some default that the application is expected to provide for each part?

	Thanks,
	Paul

---

From: Gonzalo Camarillo <[email-masked]>
Date: Mon, 14 Jul 2008 11:31:40 +0300

Hi,

I agree with Paul that having a common way for handling 
multipart/related would be good.

In any case, if we decided to use the disposition types of the body 
parts in a multipart/related instead of ignoring them, we would need to 
understand what would be the difference between:

- a multipart/mixed where body parts are treated according to their 
disposition types, and

- a multipart/related where body parts would also be treated according 
to their disposition types.

If we do not explicitly explain what the difference in processing is, 
implementers are going to be confused.

Cheers,

Gonzalo

Paul Kyzivat wrote:
>>> "processing the body as a compound object" if the body parts are 
>>> still processed per their respective disposition types, as if they 
>>> were in a multipart/mixed instead of in a multipart/related.
>>>
>>> paragraph above so that we have a concrete proposal on how to 
>>> describe the processing of multipart/related bodies and how it would 
>>> differ from the processing of multipart/mixed bodies?
>>
>> It's a bit wordy, but my first attempt at addressing the situation 
>> came out like this:
>>

---

From: Paul Kyzivat <[email-masked]>
Date: Mon, 14 Jul 2008 12:21:43 -0400

> But I don't know that we have time to fix that now.

Well...

This was WGLC, and you did get your comment in before the WGLC closed.

If the draft isn't right, its better to fix it now than later.

Like a lot of things, it seems that they only get noticed by a small 
number of people until it is almost "too late".

> certain specific usages of nested multiparts.

Well, the handling parameter wasn't invented for sip. So presumably we 
should try to stick with its intended definition if we can. Assuming we 
knew what that was.

ISTM that if a part has handling=optional, and you choose not to handle 
it, then you won't notice the handling parameter of any enclosed parts. 
But that is an ISTM, not a normative reference.

> the Accept should only list media types understood for the particular

IMO this is a huge problem with all Accept-* headers. There is a fairly 
good chance that the 415 will only list those supported in a particular 
context. Consider for instance a case where a proxy for an AOR routes 
SUBSCRIBE requests for presence to one UA, and INVITE requests to a 
different UA. Those two UAs will most likely support different content 
types.

Even within a single UA there may be routing to different "applications" 
and that may result in different indications of what is accepted.

One might argue that this only makes sense within a dialog, but there 
are plenty of examples where the dialog is the wrong scope for this. I 
don't know a good answer here, but I expect that in practice the 415 may 
only reflect "this is what I can support here and now in this context."

> process the entire SIP message, then the UAS returns...", but that's

This is just the tip of an iceberg. The iceberg is the meaning of "handle".

IMO, "handle" has to mean "process in a way compliant according to the 
specifications for this C-T and C-D in the current context. (Which 
includes the current message type and the processing of any containing 
body parts, referencing headers, etc., as well as the role (UAC, UAS, 
proxy, ...) of the processor.) In many cases, "ignore" may be a valid 
form of processing.

> parts of a multipart/alternative?

The specification of C-D states that the default for the handling 
parameter is "handling=required", so omitting it solves nothing.

> 'required'."  This seems tautological -- why is it stated?

Goes back to the meaning of "required".  I don't think it is 
tautological, but maybe it could be stated better. The goal here would 
be define the relationship between "handling=required" in the header to 
desired behavior in the recipient of the body part.

> optional within that part.  What is really intended here?

We discussed this a lot, and I thought we finally got something workable.

As I understand it, processing based on a reference and processing based 
on presence are more-or-less independent.

Assume for the moment that the type and disposition are understood. If 
there is some implied processing based on the type and disposition, then 
it will be done. If there is also a reference to it via CID from one or 
more headers (or other body parts), then those may also be performed 
based on the rules for those references. If the goal is to include a 
body part solely so that it can be referenced from elsewhere, then it 
ought to have a C-T/C-D that doesn't result in any unexpected processing.

If a part has handling=required, but is not understood, then references 
to it aren't going to work.

This is all pretty hard to explain. Expecially if you include references 
from other body parts. After listening to Adam, I suspect that maybe 
reference between body parts should be within a multipart/related, which 
will get us into the other discussion of C-D with multipart/related. But 
I think there are cases where multipart/related isn't appropriate.

Consider the following:

An INVITE that contains both sdp and a body part referenced by a Geoloc 
header. Those two parts aren't related to one another, so they go into a 
multipart/mixed in the INVITE. The reference is from the headers of the 
sip message to one of the body parts within the multipart/mixed.

Something similar could occur in a response to an INVITE as well, though 
probably not with geoloc. For instance there could be an Alert-Info 
header referencing a body part containing a picture of the callee.

Now suppose a REFER causes an INVITE that has such a response. And the 
entire response is returned in sipfrag in a NOTIFY to the referror. So 
then you have: A REFER with a body of type sipfrag. The body in turn 
contains a body of type multipart/mixed. The multipart/mixed contains an 
SDP part and an image part. The sip headers in the sipfrag reference the 
image part in the contained multipart/mixed.

Now *probably* the image part in the response to the invite would have 
handling=optional. Or it could have had handling=required if the callee 
felt strongly about presenting its image. I don't know what should 
happen to the INVITE if the image body part wasn't understood. Nor do I 
understand what should happen to the NOTIFY if the recipient doesn't 
understand the image.

	Paul

---

From: Anders Kristensen <[email-masked]>
Date: Mon, 14 Jul 2008 12:14:14 -0700

Paul Kyzivat wrote:
[snip]
> understand what should happen to the NOTIFY if the recipient doesn't 

On this last part, message/sipfrag is not a multipart so I don't think 
the rules in the body-handling draft really applies to how the referrer 
processes this NOTIFY. The sipfrag may include a body which may be a 
multipart but the entire sipfrag will be transported as an opaque 
non-multipart in the NOTIFY. So I would tend to think that this draft is 
irrelevant as far as interpreting sipfrags is concerned.

Anders

---

From: Paul Kyzivat <[email-masked]>
Date: Mon, 14 Jul 2008 15:22:47 -0400

OK. Good point.

	Paul

Anders Kristensen wrote:
> 
> 
> Paul Kyzivat wrote:
> [snip]
>> Consider the following:
>>
>> An INVITE that contains both sdp and a body part referenced by a 
>> Geoloc header. Those two parts aren't related to one another, so they 
>> go into a multipart/mixed in the INVITE. The reference is from the 
>> headers of the sip message to one of the body parts within the 
>> multipart/mixed.
>>
>> Something similar could occur in a response to an INVITE as well, 
>> though probably not with geoloc. For instance there could be an 
>> Alert-Info header referencing a body part containing a picture of the 
>> callee.
>>
>> contains a body of type multipart/mixed. The multipart/mixed contains 
>> an SDP part and an image part. The sip headers in the sipfrag 
>> reference the image part in the contained multipart/mixed.
>>
>> handling=optional. Or it could have had handling=required if the 
>> callee felt strongly about presenting its image. I don't know what 
>> should happen to the INVITE if the image body part wasn't understood. 
>> Nor do I understand what should happen to the NOTIFY if the recipient 
>> doesn't understand the image.
>

---

From: Gonzalo Camarillo <[email-masked]>
Date: Fri, 25 Jul 2008 12:49:42 +0300

Hi Dale,

thanks for your comments. Answers inline:

[email-masked] wrote:
> necessity of understanding of the enclosing body part.

Section 6.2 explains exactly this. If you would like to propose some 
introductory text to clarify what is defined there, I will be happy to 
add it.

>  Or

Paul already answered this one. There are issues with how different 
methods are routed. Describing the limitations of the Accept-* mechanism 
is the best thing we can do, IMO.

>    that the this rule causes the UAS to behave as the UAC desires.

the paragraph in the draft does not contain normative statements because 
it is simply giving background information (per the title of the 
section) about normative statements in other documents. Therefore, we 
cannot really use normative statements there.

However, I agree that "this way" is not a good link between both 
sentences. I will simply remove it.

> process the entire SIP message, then the UAS returns...", but that's

What do you have in mind? I guess you are thinking of a body whose 
handling is required but its "father's" handling was optional. But the 
rules in Section 6.2 intend to keep that from happening. Could you give 
us an example where this happens?

> parts of a multipart/alternative?

Per RFC 4485, we are supposed to specify the behaviors of UACs and UASs 
separately. That is what the draft does. The note you are referring to 
is just an informative note.

> 'required'."  This seems tautological -- why is it stated?

It is there for completeness. If you put that sentence in context, 
together with the next sentence in the text, it makes sense to state it 
like that so that the specification is not ambiguous, I think.

> optional within that part.  What is really intended here?

Section 7.4 explains that we define the 'by-reference' disposition type 
to avoid that problem. The last paragraph on Section 7.4 explains that 
in the past, option tags have been used to avoid that same problem.

Thanks for your comments,

Gonzalo

---

From: Eric Burger <[email-masked]>
Date: Mon, 28 Jul 2008 06:57:35 +0100

Last I looked, RFC 3459 fully specifies what to do with multipart/ 
alternative and multipart/related. We did not bother to enumerate what  
to do with multipart/mixed, as it is painfully obvious: one has to  
look at everything to figure out what to do. Sometimes, life is "less  
than ideal."

Like all things Mail (and SIP), handling does not require  
understanding.  What part of the original intention is not clear?   
Both 3204 and 3459 are gateway (B2BUA) scenarios.  3204 is a  
particular instance, while 3459 is the generic use case; mail focused,  
true, but appropriate for SIP, too.

On Keith's point that body-handling updates 3204, that works for me if  
this draft updates the rules for ISUP.  However, if it updates the  
meaning of "handling", then it is 3459 that gets the update, as 3459  
updates 3204 already.

Unfortunately for me, I only have a copy of draft-ietf-sip-body- 
handling-01 handy, so I cannot comment on -02 until this week.

On Jul 14, 2008, at 5:21 PM, Paul Kyzivat wrote:

> Well, the handling parameter wasn't invented for sip. So presumably  
> we should try to stick with its intended definition if we can.  
> Assuming we knew what that was.
>
> ISTM that if a part has handling=optional, and you choose not to  
> handle it, then you won't notice the handling parameter of any  
> enclosed parts. But that is an ISTM, not a normative reference.
>
> IMO this is a huge problem with all Accept-* headers. There is a  
> fairly good chance that the 415 will only list those supported in a  
> particular context. Consider for instance a case where a proxy for  
> an AOR routes SUBSCRIBE requests for presence to one UA, and INVITE  
> requests to a different UA. Those two UAs will most likely support  
> different content types.
>
> Even within a single UA there may be routing to different  
> "applications" and that may result in different indications of what  
> is accepted.
>
> One might argue that this only makes sense within a dialog, but  
> there are plenty of examples where the dialog is the wrong scope for  
> this. I don't know a good answer here, but I expect that in practice  
> the 415 may only reflect "this is what I can support here and now in  
> this context."
>
> IMO, "handle" has to mean "process in a way compliant according to  
> the specifications for this C-T and C-D in the current context.  
> (Which includes the current message type and the processing of any  
> containing body parts, referencing headers, etc., as well as the  
> role (UAC, UAS, proxy, ...) of the processor.) In many cases,  
> "ignore" may be a valid form of processing.
>
> tautological, but maybe it could be stated better. The goal here  
> would be define the relationship between "handling=required" in the  
> header to desired behavior in the recipient of the body part.
>
> As I understand it, processing based on a reference and processing  
> based on presence are more-or-less independent.
>
> Assume for the moment that the type and disposition are understood.  
> If there is some implied processing based on the type and  
> disposition, then it will be done. If there is also a reference to  
> it via CID from one or more headers (or other body parts), then  
> those may also be performed based on the rules for those references.  
> If the goal is to include a body part solely so that it can be  
> referenced from elsewhere, then it ought to have a C-T/C-D that  
> doesn't result in any unexpected processing.
>
> If a part has handling=required, but is not understood, then  
> references to it aren't going to work.
>
> This is all pretty hard to explain. Expecially if you include  
> references from other body parts. After listening to Adam, I suspect  
> that maybe reference between body parts should be within a multipart/ 
> related, which will get us into the other discussion of C-D with  
> multipart/related. But I think there are cases where multipart/ 
> related isn't appropriate.
>
> Consider the following:
>
> Geoloc header. Those two parts aren't related to one another, so  
> they go into a multipart/mixed in the INVITE. The reference is from  
> the headers of the sip message to one of the body parts within the  
> multipart/mixed.
>
> Alert-Info header referencing a body part containing a picture of  
> the callee.
>
> Now suppose a REFER causes an INVITE that has such a response. And  
> the entire response is returned in sipfrag in a NOTIFY to the  
> referror. So then you have: A REFER with a body of type sipfrag. The  
> body in turn contains a body of type multipart/mixed. The multipart/ 
> mixed contains an SDP part and an image part. The sip headers in the  
> sipfrag reference the image part in the contained multipart/mixed.
>
> Now *probably* the image part in the response to the invite would  
> have handling=optional. Or it could have had handling=required if  
> the callee felt strongly about presenting its image. I don't know  
> what should happen to the INVITE if the image body part wasn't  
> understood. Nor do I understand what should happen to the NOTIFY if  
> the recipient doesn't understand the image.
>
> 	Paul
>
>> Dale

---

From: Eric Burger <[email-masked]>
Date: Mon, 28 Jul 2008 07:22:38 +0100

---

From: Eric Burger <[email-masked]>
Date: Mon, 28 Jul 2008 07:22:45 +0100

Unfortunately for me, I only have a copy of

---

From: "DRAGE, Keith \(Keith\)" <[email-masked]>
Date: Mon, 28 Jul 2008 15:05:37 +0200

> On Keith's point that body-handling updates 3204, that works 
> for me if this draft updates the rules for ISUP.  However, if 
> it updates the meaning of "handling", then it is 3459 that 
> gets the update, as 3459 updates 3204 already.

Well if this is the case, then it should have added its own reference to
the IANA registration of the handling parameter, which it did not.
Suggest therefore that sip-body-handling also updates the IANA registry
to include RFC 3459 as well as its own RFC number.

Regards

Keith

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On 
> Behalf Of Eric Burger
> Sent: Monday, July 28, 2008 6:58 AM
> To: [email-masked]; Gonzalo Camarillo
> Cc: [email-masked] List
> Subject: Re: [Sip] WGLC for draft-ietf-sip-body-handling
> 
> Last I looked, RFC 3459 fully specifies what to do with 
> multipart/ alternative and multipart/related. We did not 
> bother to enumerate what to do with multipart/mixed, as it is 
> painfully obvious: one has to look at everything to figure 
> out what to do. Sometimes, life is "less than ideal."
> 
> particular instance, while 3459 is the generic use case; mail 
> focused, true, but appropriate for SIP, too.
> 
> On Keith's point that body-handling updates 3204, that works 
> for me if this draft updates the rules for ISUP.  However, if 
> it updates the meaning of "handling", then it is 3459 that 
> gets the update, as 3459 updates 3204 already.
> 
> >> In a lot of situations, it seems that the rule is "the 
> designer of  
> >> the
> >> avoid it, we would have to ban nested multiparts, or at 
> least, all  
> >> but
> >> There are a lot of mentions of the 415 response in 
> passing.  As far  
> >> as
> >> This is incorrect.  Of course, what is meant is, "If the 
> parameter  
> >> has
> >> the handling parameter is not significant: "The handling 
> parameters  
> >> of
> >> contradictory if the part containing the reference is 
> required but  
> >> the