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

From: Gonzalo Camarillo <[email-masked]>
Date: Wed, 29 Aug 2007 14:17:17 +0300

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

---

From: Paul Kyzivat <[email-masked]>
Date: Wed, 29 Aug 2007 08:14:29 -0400

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

---

From: Paul Kyzivat <[email-masked]>
Date: Wed, 29 Aug 2007 08:57:29 -0400

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:
>> 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
>>
>>
>>