Subject: Re: [Sip] New revision of draft-ietf-sip-body-handling-00.txt

From: Gonzalo Camarillo <[email-masked]>
Date: Fri, 16 Nov 2007 22:25:20 +0200

Hi,

FYI: we have just gotten their review:
http://www1.ietf.org/mail-archive/web/apps-review/current/msg00110.html

Cheers,

Gonzalo

Gonzalo Camarillo wrote:
> Folks,
> 
> FYI: we have requested the apps folks to have a look at this draft in 
> order to make sure we get all the MIME stuff right. We will make sure 
> the review is posted to this list.
> 
> Cheers,
> 
> Gonzalo
> 
> 
> Gonzalo Camarillo wrote:
>> Hi,
>>
>> to be more concrete in our discussions, we need to make decisions on 
>> the following two issues:
>>
>> 1) Where in a SIP message is it allowed to reference a body part?
>>
>> a) in header fields and body parts within the same multipart/related 
>> as the referenced body part
>> b) in header fields and body parts that appear before the referenced 
>> body part
>> c) in header fields and any body part
>>
>> We discussed that doing c) would require to parse SIP messages twice 
>> to look for potential references. Therefore, we decided to do a) or 
>> b). The current draft specifies a), we doing b) might make sense as 
>> well (it would be less restrictive).
>>
>>
>> 2) If a receiver does not understand a reference to a body part:
>>
>> a) it should process (handle) it solely based on its disposition type 
>> (as a fall-back mechanism). If the sender does not want this to 
>> happen, it can use an option tag.
>>
>> b) the body part will have a disposition type of "only-by-reference". 
>> This way, since the receiver did not understand the reference, it 
>> knows it should not process the body.
>>
>> The current draft specifies a), but b) would be an interesting 
>> optimization (no need to use option tags and reissue requests). 
>> However, we would need to get the opinion of a MIME person on b).
>>
>> Cheers,
>>
>> Gonzalo
>>
>>
>>
>> Paul Kyzivat wrote:
>>>
>>>
>>> Eric Burger wrote:
>>>> I agree 100% with Paul.  However, one thing I would like to hear 
>>>> opinions on
>>>> is the following:
>>>>
>>>> Do we way body parts are always processed, no matter what?
>>>>
>>>> It would be convenient to say body parts get processed as needed.  
>>>> If there
>>>> is a related part that never gets referenced, then a conforming 
>>>> processor
>>>> might not process that part, as an optimization.
>>>
>>> This gets into semantics...
>>>
>>> For one thing, I guess we should talk about "handling" rather than 
>>> "processing" - this is tied to the C-D "handling=" parameter.
>>>
>>> But the key thing is what does it *mean* to say you have handled 
>>> something? Its one thing to understand the meaning of the type and 
>>> disposition. What you actually *do* once that is understood is 
>>> something else entirely.
>>>
>>> I would expect that somewhere there would be a normative 
>>> specification for each C-D of what it means to *handle* body parts 
>>> with that disposition. This is where we get into trouble with 
>>> "render", where we need a different definition for SIP than is used 
>>> for email.
>>>
>>> I presume that if we had such normative definitions, then that would 
>>> determine what sort of optimizations, such as lazy processing, are 
>>> allowed.
>>>
>>> For example, 3261 defines (barely) the C-D "alert". It says this 
>>> "should" (lower case) be rendered. Together with some words elsewhere 
>>> about Alert-Info that warn of security issues, its seems clear that 
>>> the UA is given discretion about actually rendering this. (But it is 
>>> not a stellar example of clarity.) I would interpret this to mean 
>>> that you can consider the "alert" body part to have been "handled" if 
>>> you have indeed understood it and then *either* rendered it or made 
>>> an explicit not to render it.
>>>
>>>> However, one thing we need to be mindful of are side effects.  MIME 
>>>> body
>>>> parts can make external references.  Those external references (to
>>>> http/https URI's) may hit application servers.  Those application 
>>>> servers
>>>> may do something based on the receipt of the URI.  It could be as 
>>>> simple as
>>>> recording the fact the body part was read (like a web beacon), or it 
>>>> could
>>>> be as complex as changing application state.
>>>
>>> We have similar issues with headers that contain URL references, that 
>>> might or might not be resolved. E.g. Call-Info.
>>>
>>> Again, I don't see any general answer better than the specification 
>>> of the particular header or C-D.
>>>
>>> Based on this discussion I am beginning to conclude that we might as 
>>> well treat each body part almost as if it were a header whose name is 
>>> its C-D.
>>>
>>>> What do people think of this?  Do we say that SIP engines are 
>>>> opportunistic,
>>>> and the side effect MUST happen if the body gets used, buy the side 
>>>> effect
>>>> MAY happen if the body does not get used?  That would be my vote, as 
>>>> the
>>>> alternative, that all side effects (external references get 
>>>> resolved) happen
>>>> puts a pretty big burden on User Agents.
>>>
>>> This is further complicated by intermediate nodes. They are 
>>> *permitted* to look at body parts. If, as a result, an intermediate 
>>> node dereferences a reference within a body part, you will 
>>> potentially have another side effect.
>>>
>>> I also agree that we should give the UA latitude in what processing 
>>> it does. For example, even though a request has a geopriv header with 
>>> a body part containing location data, and has specified 
>>> "handling=required", the UAS may have no use for the location. If it 
>>> doesn't intend to use it then why should it process it?
>>>
>>>     Paul
>>>
>>>> On 8/29/07 8:57 AM, "Paul Kyzivat" <[email-masked]> wrote:
>>>>
>>>>> To clarify futher my last point below...
>>>>>
>>>>> What I am saying is that IMO body parts must always be processed
>>>>> according to their type and disposition, whether there are 
>>>>> references to
>>>>> them or not. If there is a reference, and it is understood, then it 
>>>>> can
>>>>> modify or supplement the processing, but if the reference is not
>>>>> recognized or understood then the other processing still occurs.
>>>>>
>>>>> If we want to support the possibility of a reference to a body part,
>>>>> where there is to be no processing of the body part when the reference
>>>>> is not understood, then we need a content-disposition that says "don't
>>>>> do anything with this unless you process a reference to it."
>>>>>
>>>>> An alternative is to simply assume there are no such cases, and warn
>>>>> people that use references to select a C-D for the referenced part 
>>>>> that
>>>>> will have an appropriate result if the reference is not understood.
>>>>>
>>>>> For instance, we have both the Alert-Info header and the "alert" 
>>>>> C-D. If
>>>>> you use an A-I with a CID reference, then you can use "alert" as 
>>>>> the C-D
>>>>> of that part. In that case, the A-I header is redundant unless it
>>>>> contains something that modifies the processing.
>>>>>
>>>>> An example where the problem I am concerned about may exist is in
>>>>> draft-ietf-sip-location-conveyance-08. It has an example of a
>>>>> Geolocation header referencing a body part. There is no C-D header in
>>>>> the example, so by default it is "render;handling=required". And 
>>>>> its C-T
>>>>> is application/pidf+xml. If a recipient of this message didn't
>>>>> understand the Geolocation header it would reach the conclusion 
>>>>> that it
>>>>> should render the pidf. Its debatable whether that is the desired
>>>>> conclusion - I think not. IMO the intent is that if the Geolocation
>>>>> header isn't processed then the pidf should be ignored. So, IMO this
>>>>> body part ought to contain:
>>>>>     Content-Disposition: by-reference;handling=optional
>>>>>
>>>>> (I don't care what name we use for the disposition, just that we 
>>>>> have one.)
>>>>>
>>>>> Thanks,
>>>>> Paul
>>>>>
>>>>> Paul Kyzivat wrote:
>>>>>> Gonzalo,
>>>>>>
>>>>>> Obviously we allow a "forward" reference from the sip message itself
>>>>>> (which from a mime perspective are just a bunch of mime headers.)
>>>>>>
>>>>>> I think that establishes a precedent that needs to be continued. An
>>>>>> example of why can be seen in sipfrag:
>>>>>>
>>>>>> If we had a valid sip response that had a reference into one of 
>>>>>> its body
>>>>>> parts, then if that was turned into a sipfrag and stuffed into the 
>>>>>> body
>>>>>> of a NOTIFY, then it must still be valid.
>>>>>>
>>>>>> I just did a quick scan of the new draft, so the following is a
>>>>>> tentative comment, until I can read it more carefully:
>>>>>>
>>>>>> I think the draft is now saying that the decision about whether to
>>>>>> process a body part according to a reference to it, or process
>>>>>> independently, is decided based on whether a reference is found. 
>>>>>> We had
>>>>>> this discussion before, and I think we agreed that wouldn't work 
>>>>>> well,
>>>>>> and that instead we would have a special C-D type for body parts that
>>>>>> are disposed of based on a reference.
>>>>>>
>>>>>> I don't think the introduction of issues related to multipart/related
>>>>>> changes this. The obvious cases are when there is a single
>>>>>> multipart/mixed containing some body parts. Some of those may be
>>>>>> referenced from CID URIs in sip headers, and others (e.g. SDP) may 
>>>>>> stand
>>>>>> on their own. It is entirely possible that a body part might be
>>>>>> referenced from some extension header that the recipient doesn't
>>>>>> understand. In that case it may erroneously decide to process the 
>>>>>> body
>>>>>> part on its own, when it should instead have ignored it because the
>>>>>> header isn't being processed.
>>>>>>
>>>>>>     Thanks,
>>>>>>     Paul
>>>>>>
>>>>>> Gonzalo Camarillo wrote:
>>>>>>> Folks,
>>>>>>>
>>>>>>> I have just submitted a new revision of the body handling draft. 
>>>>>>> Until
>>>>>>> it appears on the archives, you can fetch it from:
>>>>>>>
>>>>>>> http://users.piuha.net/gonzalo/temp/draft-ietf-sip-body-handling-00.txt 
>>>>>>>
>>>>>>>
>>>>>>> Per our discussions in Chicago, the draft now states that only body
>>>>>>> parts within the same 'multipart/related' can reference each other
>>>>>>> using cid URIs.
>>>>>>>
>>>>>>> If this is too restrictive, we could also allow using forward
>>>>>>> references in any context (with no 'multipart/related' at all).
>>>>>>>
>>>>>>> Comments?
>>>>>>>
>>>>>>> Thanks,
>>>>>>>
>>>>>>> Gonzalo
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> _______________________________________________
>>>>>>> Sip mailing list  https://www1.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
>>>>>>>
>>>>>>
>>>>>> _______________________________________________
>>>>>> Sip mailing list  https://www1.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
>>>>>>
>>>>>
>>>>> _______________________________________________
>>>>> Sip mailing list  https://www1.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
>>>>
>>>>
>>>> Notice:  This email message, together with any attachments, may 
>>>> contain information  of  BEA Systems,  Inc.,  its subsidiaries  and  
>>>> affiliated entities,  that may be confidential,  proprietary,  
>>>> copyrighted  and/or legally privileged, and is intended solely for 
>>>> the use of the individual or entity named in this message. If you 
>>>> are not the intended recipient, and have received this message in 
>>>> error, please immediately return this by email and then delete it.
>>>>
>>
>>
>>
>> _______________________________________________
>> Sip mailing list  https://www1.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
>>
> 
> 
> 
> _______________________________________________
> Sip mailing list  https://www1.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
> 

_______________________________________________
Sip mailing list  https://www1.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: Paul Kyzivat <[email-masked]>
Date: Fri, 16 Nov 2007 17:08:48 -0500

> http://www1.ietf.org/mail-archive/web/apps-review/current/msg00110.html

Looks like there is a *bit* more work to do. :-)

This is perhaps somewhat more feedback than we were hoping for. But 
honestly it does seem constructive.

However on several of what I thought were key points needing feedback I 
don't see the help I was hoping for. For instance regarding references. 
Perhaps more interaction is needed to get on the same wavelength so that 
Dave understands our concerns and we understand his answers.

	Paul

>>>> "should" (lower case) be rendered. Together with some words 
>>>> elsewhere about Alert-Info that warn of security issues, its seems 
>>>> clear that the UA is given discretion about actually rendering this. 
>>>> (But it is not a stellar example of clarity.) I would interpret this 
>>>> to mean that you can consider the "alert" body part to have been 
>>>> "handled" if you have indeed understood it and then *either* 
>>>> rendered it or made an explicit not to render it.
>>>>
>>>>> recording the fact the body part was read (like a web beacon), or 
>>>>> it could
>>>> We have similar issues with headers that contain URL references, 
>>>> that might or might not be resolved. E.g. Call-Info.
>>>>
>>>> well treat each body part almost as if it were a header whose name 
>>>> is its C-D.
>>>>
>>>>> MAY happen if the body does not get used?  That would be my vote, 
>>>>> as the
>>>> it does. For example, even though a request has a geopriv header 
>>>> with a body part containing location data, and has specified 
>>>>>> them or not. If there is a reference, and it is understood, then 
>>>>>> it can
>>>>>>> parts, then if that was turned into a sipfrag and stuffed into 
>>>>>>> the body
>>>>>>> referenced from CID URIs in sip headers, and others (e.g. SDP) 
>>>>>>> may stand
>>>>> contain information  of  BEA Systems,  Inc.,  its subsidiaries  
>>>>> and  affiliated entities,  that may be confidential,  proprietary,

---

From: Gonzalo Camarillo <[email-masked]>
Date: Sat, 17 Nov 2007 09:12:17 +0200

Hi Paul,

yes, I agree; that's what I thought as well when I read the review. 
Anyway, this is a good starting point for discussions. I will touch base 
with Dave and will start working on how to address his comments and how 
to get feedback on the points we did not get any.

In any case, I do not see the need to revise the draft before Vancouver.

Cheers,

Gonzalo

Paul Kyzivat wrote:
>>>> a) it should process (handle) it solely based on its disposition 
>>>> type (as a fall-back mechanism). If the sender does not want this to 
>>>> b) the body part will have a disposition type of 
>>>> "only-by-reference". This way, since the receiver did not understand 
>>>> the reference, it knows it should not process the body.
>>>>
>>>>> I presume that if we had such normative definitions, then that 
>>>>> would determine what sort of optimizations, such as lazy 
>>>>> processing, are allowed.
>>>>>
>>>>> clear that the UA is given discretion about actually rendering 
>>>>> this. (But it is not a stellar example of clarity.) I would 
>>>>> interpret this to mean that you can consider the "alert" body part 
>>>>> to have been "handled" if you have indeed understood it and then 
>>>>> *either* rendered it or made an explicit not to render it.
>>>>>
>>>>>> However, one thing we need to be mindful of are side effects.  
>>>>>> MIME body
>>>>> Based on this discussion I am beginning to conclude that we might 
>>>>> as well treat each body part almost as if it were a header whose 
>>>>> name is its C-D.
>>>>>
>>>>>> and the side effect MUST happen if the body gets used, buy the 
>>>>>> side effect
>>>>> "handling=required", the UAS may have no use for the location. If 
>>>>> it doesn't intend to use it then why should it process it?
>>>>>
>>>>>     Paul
>>>>>
>>>>>>> people that use references to select a C-D for the referenced 
>>>>>>> part that
>>>>>>>> understand. In that case it may erroneously decide to process 
>>>>>>>> the body
>>>>>>>>> I have just submitted a new revision of the body handling 
>>>>>>>>> draft. Until
>>>>>> and  affiliated entities,  that may be confidential,  
>>>>>> proprietary,  copyrighted  and/or legally privileged, and is 
>>>>>> intended solely for the use of the individual or entity named in 
>>>>>> this message. If you are not the intended recipient, and have 
>>>>>> received this message in error, please immediately return this by 
>>>>>> email and then delete it.
>>>>>>
>>>>
>>>>
>>>>

---

From: Paul Kyzivat <[email-masked]>
Date: Sat, 17 Nov 2007 10:16:04 -0500

> In any case, I do not see the need to revise the draft before Vancouver.

Yeah I agree.

Perhaps we can have a side conversation with Dave on this while in 
Vancouver.

	Thanks,
	Paul

>> However on several of what I thought were key points needing feedback 
>> I don't see the help I was hoping for. For instance regarding 
>> references. Perhaps more interaction is needed to get on the same 
>> wavelength so that Dave understands our concerns and we understand his 
>> answers.
>>
>>     Paul
>>
>>
>>> Gonzalo Camarillo wrote:
>>>> Folks,
>>>>
>>>> FYI: we have requested the apps folks to have a look at this draft 
>>>> in order to make sure we get all the MIME stuff right. We will make 
>>>> sure the review is posted to this list.
>>>>
>>>> Cheers,
>>>>
>>>> Gonzalo
>>>>
>>>>
>>>> Gonzalo Camarillo wrote:
>>>>> Hi,
>>>>>
>>>>> to be more concrete in our discussions, we need to make decisions 
>>>>> on the following two issues:
>>>>>
>>>>> a) in header fields and body parts within the same 
>>>>> multipart/related as the referenced body part
>>>>> b) in header fields and body parts that appear before the 
>>>>> referenced body part
>>>>> We discussed that doing c) would require to parse SIP messages 
>>>>> twice to look for potential references. Therefore, we decided to do 
>>>>> a) or b). The current draft specifies a), we doing b) might make 
>>>>> sense as well (it would be less restrictive).
>>>>>
>>>>>
>>>>> type (as a fall-back mechanism). If the sender does not want this 
>>>>> to happen, it can use an option tag.
>>>>>
>>>>> "only-by-reference". This way, since the receiver did not 
>>>>> understand the reference, it knows it should not process the body.
>>>>>
>>>>>>> It would be convenient to say body parts get processed as 
>>>>>>> needed.  If there
>>>>>> "render", where we need a different definition for SIP than is 
>>>>>> used for email.
>>>>>>
>>>>>> Again, I don't see any general answer better than the 
>>>>>> specification of the particular header or C-D.
>>>>>>
>>>>>> *permitted* to look at body parts. If, as a result, an 
>>>>>> intermediate node dereferences a reference within a body part, you 
>>>>>> will potentially have another side effect.
>>>>>>
>>>>>> I also agree that we should give the UA latitude in what 
>>>>>> processing it does. For example, even though a request has a 
>>>>>> geopriv header with a body part containing location data, and has 
>>>>>> specified "handling=required", the UAS may have no use for the 
>>>>>> location. If it doesn't intend to use it then why should it 
>>>>>> process it?
>>>>>>
>>>>>>     Paul
>>>>>>
>>>>>>>>> independently, is decided based on whether a reference is 
>>>>>>>>> found. We had
>>>>>>>>> this discussion before, and I think we agreed that wouldn't 
>>>>>>>>> work well,