Subject: [Sipping] Re: [Simple] Re: Managing multiple body parts

From: Gonzalo Camarillo <[email-masked]>
Date: Thu, 06 May 2004 21:41:39 +0300

Paul,

the set of issues you mention below could be documented in the 
guidelines for authors of SIP extensions document:

http://www.jdrosen.net/papers/draft-ietf-sip-guidelines-07.txt

This way, every document defining new body parts would take them into 
consideration.

Jonathan, Henning, what is the status of that draft?

Gonzalo

Paul Kyzivat wrote:

> 
> 
> Gonzalo Camarillo wrote:
> 
>> Hi Paul,
>>
>> typically you either tag the body with a content disposition tag, or 
>> have a pointer somewhere in the message pointing to the body part... 
>> or both.
> 
> 
> Note that even if you don't explicitly tag a body with a content 
> disposition it implicitly has one, because there is a defaulting rule.
> 
>> What sort of things do you have in mind, besides the ones I mentioned?
> 
> 
> Here are a few fuzzy issues:
> 
> - what content-disposition should a multipart/mixed body have?
>   Should the recipient always look inside one for interesting
>   content, regardless of the disposition?
> 
> - It is ok to nest body parts arbitrarily deep in nested
>   multipart/mixed bodies? Or is there a cannonical way that
>   body parts should be composed?
> 
> - What should happen, in an invite, to a body part with
>   content-type of application/sdp but with a content-disposition
>   of something other than "session"? (E.g. "render".)
> 
> - What should happen if an invite contains two body parts that
>   both have content-type of application/sdp and content-disposition
>   of session. (In a multipart/mixed, not multipart/alternative.)
> 
> - What content-disposition should be used for the content of
>   a MESSAGE message? A NOTIFY message? A SUBSCRIBE message?
> 
> - What content-disposition should be used for multipart/signed
>   and multipart/encrypted bodies? Should it match whatever it
>   is that is signed or encrypted?
> 
> - What content-disposition should be used for body parts that
>   are referenced via a cid: uri somewhere in the message?
> 
> - Does the fact that a body part is referenced by a cid: uri
>   mean that it shouldn't also be processed as it would have been
>   had it not been referenced by a cid: uri? What if the reference
>   is from an extension header that the recipient doesn't understand?
> 
> - The content-disposition header has a handling parameter.
>   An error should be generated if any parts with handling=required
>   aren't able to be processed. In the context of sip, how is a
>   determination made whether a part has been processed? Is it
>   sufficient that it be understood even if it isn't acted upon?
> 
> I can probably come up with more, but that is a start.
> 
>     Paul

_______________________________________________
Sipping mailing list  https://www1.ietf.org/mailman/listinfo/sipping
This list is for NEW development of the application of SIP
Use [email-masked] for questions on current sip
Use [email-masked] for new developments of core SIP

---

From: Paul Kyzivat <[email-masked]>
Date: Thu, 06 May 2004 15:32:31 -0400

Gonzalo,

Adding stuff to the guidelines for extensions won't help clarify stuff 
that is already out there, like 3261. Someone who only sets out to 
implement 3261 faces some of these issues regarding what might be 
received and how to interpret it. Seems like eventually something might 
need to go into the next rev of 3261.

But it still sounds like this might be a good place to start.

I guess it isn't the issues that should be documented in the guidelines 
for authors - it is guidelines for addressing the issues that need to be 
there. I suspect there is not concensus on the proper resolution for 
those issues. But I suppose that can be cured by proposing something for 
the guidelines and seeing what complaints arise.

If that is the right place, and the intent is to rev that draft, I could 
propose some new content for section 4.12.

	Thanks,
	Paul