Subject: [Sip] comments on draft-camarillo-sip-body-handling-01

From: Jonathan Rosenberg <[email-masked]>
Date: Wed, 18 Jul 2007 09:44:26 -0400

The draft makes support of multipart a SHOULD in RFC 3261. If our 
objective is to use multipart as a vehicle for extending SIP (e.g., by 
including optional bodies in addition to the mandatory one - a location 
object plus SDP for example), this is much better served by a MUST. 
Otherwise, a UAC will have to send a request first with multipart, and 
if its rejected, retry the request with just the supported parts. Its 
effectively the same as the behavior we'd see if the only way to extend 
SIP was with Require, and not Supported.

This draft also strikes me as something that is in the essential 
corrections category, but its debatable.

For multipart/alternative - I don't understand the requirement to order 
them from least to most 'rich'. Is that a general MIME behavior or are 
we defining it that way? If we want to prioritize, shouldn't we use an 
explicit q-value or something? Using order seems like it will be brittle 
(as it has been in SDP where m-lines were never numbered).

The use case described for multipart/alternative - new SDP mechanisms - 
seems kind of bogus. We've decided not to pursue that. Do we have a REAL 
use case for this?

> The reason for not having such a mechanism is that disposition types
>    are typically supported within a context.  Outside that context, a UA
>    (User Agent) may not support the disposition type. 

I think the same can be send for content-types. A UA may support a 
content-type of application/sdp, but only for one disposition 
('session') and not another ('render'). So, generally I would say that a 
UA never really supports a content-type; it supports a set of tuples of 
{content-type, content-disposition, method}.

> UAs process message bodies and body parts in the following way.  On
>    receiving a SIP message, if a body part is not referenced in any way
>    (e.g., there are no header fields or other body parts with a
>    Content-ID URL pointing to it), the UA processes the body part as
>    indicated by its disposition type and the context in which the body
>    part was received.
> 
>    OPEN ISSUE 4: this means that a UA would need to parse all body parts
>    to find references between them before being able to fully process
>    them.  If we are OK with this, we need to include text here
>    explaining it.

This behavior seems like a bad idea, and I don't understand why it is 
needed. If the CID URL is part of an optional extension, then you make 
the body handling optional, and the UA will know to pick up the body 
part if it supports the extension, otherwise not.

Thanks,
Jonathan R.
-- 
Jonathan D. Rosenberg, Ph.D.                   600 Lanidex Plaza
Cisco Fellow                                   Parsippany, NJ 07054-2711
Cisco Systems
[email-masked]                              FAX:   (973) 952-5050
http://www.jdrosen.net                         PHONE: (973) 952-5000
http://www.cisco.com

_______________________________________________
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: Gonzalo Camarillo <[email-masked]>
Date: Thu, 19 Jul 2007 21:13:05 +0300

Hi Jonathan,

> object plus SDP for example), this is much better served by a MUST. 

I sent an email with the slides I intend to use to present this draft 
right before you sent your comments to the list. In those slides I 
already propose to make it a MUST. So, we are on the same page.

> them from least to most 'rich'.

It is not our requirement. It is just how MIME works.

> Is that a general MIME behavior or are 

I do not think we should be changing how MIME works.

> seems kind of bogus. We've decided not to pursue that. Do we have a REAL 

AFAICT, we have decided not to pursue SDPng but we still need a 
mechanism in order to be able to, at some point, migrate to new session 
description formats. The current consensus, as I understand it, is that 
multipart/alternative should not be used to provide alternative SDP 
descriptions, but that it could be used to provide alternative session 
descriptions written in different formats.

> {content-type, content-disposition, method}.

yes, that is what the draft intends to say. I will clarify it in the text.

> part if it supports the extension, otherwise not.

we have a separate email thread where we are discussing this. The 
current proposal is to avoid having to process the message two times.

Thanks for your comments,

Gonzalo

---

From: Paul Kyzivat <[email-masked]>
Date: Thu, 19 Jul 2007 14:29:48 -0400

Just one comment in addition to what Gonzalo said:

Gonzalo Camarillo wrote:

>> The use case described for multipart/alternative - new SDP mechanisms 
>> - seems kind of bogus. We've decided not to pursue that. Do we have a 
>> REAL use case for this?
> 

The other classic example, because it is just like email, is MESSAGE 
with a multipart/alternative containing plain text and html.

	Paul

---

From: Qian Sun <[email-masked]>
Date: Fri, 20 Jul 2007 15:58:13 +0800

Hi,
I suggest Content Indirection Mechanism defined in rfc4483 should also be considered in this draft.

It is a little special, an example from rfc4483:
6.1.  Single Content Indirection

           INVITE sip:[email-masked] SIP/2.0
           Accept: message/external-body application/sdp
           Content-Type: message/external-body;
                ACCESS-TYPE=URL;
                URL="http://www.example.net/party/06/2002/announcement";
                EXPIRATION="Sat, 20 Jun 2002 12:00:00 GMT";
                size=231
           Content-Length: 105

           Content-Type: application/sdp
           Content-Disposition: session
           Content-ID: <[email-masked]>

In addition, what happens to the INVITE request if the recipient can not get the indirect content?

Nits: a letter "l" is missing in the title.
Internet-Draft         Message Body Hand"l"ing in SIP              May 2007

Cheers,
Qian

-----Original Message-----
From: Paul Kyzivat [mailto:[email-masked]] 
Sent: Friday, July 20, 2007 2:30 AM
To: Gonzalo Camarillo
Cc: IETF SIP List
Subject: Re: [Sip] comments on draft-camarillo-sip-body-handling-01

	Paul

---

From: Eric Burger <[email-masked]>
Date: Sat, 21 Jul 2007 21:47:12 -0400

This is the way MIME works.  Please don't change it!

On 7/18/07 9:44 AM, "Jonathan Rosenberg" <[email-masked]> wrote:

[snip] 
> (as it has been in SDP where m-lines were never numbered).
[snip]

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.

---

From: Eric Burger <[email-masked]>
Date: Sat, 21 Jul 2007 21:48:12 -0400

Seems like a good idea.  However, I would not go so far as to mandate
iterative evaluation.  I would offer that the UA evaluates as needed.

---

From: Paul Kyzivat <[email-masked]>
Date: Sun, 22 Jul 2007 00:21:05 -0400

One of the tasks of the draft is to make support for at least some 
subtypes of multipart (e.g. mixed) mandatory.

I hope this is not a suggestion to make dereferencing of external bodies 
mandatory.

If the request is just to include some clarification of the use and 
handling of external bodies in this draft then I guess that does sound 
useful.

	Paul

---

From: Eric Burger <[email-masked]>
Date: Sun, 22 Jul 2007 01:47:55 -0400

The latter: be aware of indirection, but (1) not mandatory and in fact (2)
don't bother to fetch the bits unless you absolutely have to.

IMHO.  Just one vote.

On 7/22/07 12:21 AM, "Paul Kyzivat" <[email-masked]> wrote:

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

---

From: sunqian 32328 <[email-masked]>
Date: Mon, 23 Jul 2007 19:03:28 +0800

Hi,

Could different SIP methods (INVITE, MESSAGE) be given different Levels of Support for Multipart?

Best Regards,
Qian Sun

----- Original Message -----
From: Paul Kyzivat <[email-masked]>
Date: Sunday, July 22, 2007 12:21 pm
Subject: Re: [Sip] comments on draft-camarillo-sip-body-handling-01

> > Seems like a good idea.  However, I would not go so far as to 
> mandate> iterative evaluation.  I would offer that the UA 
> evaluates as needed.
> > 
> > 
> >> I suggest Content Indirection Mechanism defined in rfc4483 
> should also be
> >> considered in this draft.
> >>
> URL="http://www.example.net/party/06/2002/announcement";>>         
> >> In addition, what happens to the INVITE request if the 
> recipient can not get
> >> the indirect content?
> >>
> >>>> The use case described for multipart/alternative - new SDP 
> mechanisms>>>> - seems kind of bogus. We've decided not to pursue 
> that. Do we have a
> >>>> REAL use case for this?
> >>> descriptions, but that it could be used to provide alternative 
> session>>> descriptions written in different formats.
> >> The other classic example, because it is just like email, is 
> MESSAGE>> with a multipart/alternative containing plain text and html.
> >>
> >> Paul
> >>
> >>
> > 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.
> > 
> >

---

From: Paul Kyzivat <[email-masked]>
Date: Mon, 23 Jul 2007 10:21:17 -0400

I find it quite plausible that an implementation might support multipart 
for some methods and not for others. Currently it is 
difficult/impossible to reflect that distinction in signaling. So far we 
have punted making changes to indicate such distinctions - thinking that 
doing so is not worth the trouble.

	Paul

---

From: "DRAGE, Keith \(Keith\)" <[email-masked]>
Date: Mon, 23 Jul 2007 21:45:06 +0200

They could, but I suspect we would end up in a discussion with the APPS
area of why we are trying to. 

Either we implement MIME or we don't. 

But to continue the discussion - if you want to do this, then you are
going to have to motivate it. I don't see us taking a hum per method and
arbitrarily going one way on one method and another way on another.

And I don't see the WG being motivated by prior implementation either. I
believe we are at the point where we need to make a clear statement on
what SIP needs going forwards, not a kludge based on what some existing
implementations require to validate their conformance to the new
requirements.

Regards

Keith

> From: sunqian 32328 [mailto:[email-masked]] 
> Sent: Monday, July 23, 2007 12:03 PM
> To: Paul Kyzivat
> Cc: 'IETF SIP List'; Gonzalo Camarillo
> Could different SIP methods (INVITE, MESSAGE) be given 
> different Levels of Support for Multipart?
> 
> Best Regards,
> Qian Sun
> 
> > I hope this is not a suggestion to make dereferencing of external 
> > bodies mandatory.
> > 
> > >> 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
> > >>
> > >>
> > >>
> > >>
> > >> 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
> > > 
> > > 
> > 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.
> > > 
> > > 
> > > 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
> > > 
> > 
> 
> 
> This list is for NEW development of the core SIP Protocol Use 
> [email-masked] for questions on current sip