Subject: RE: [Sip] Support for Multipart/MIME

From: "Christer Holmberg \(JO/LMF\)" <[email-masked]>
Date: Thu, 3 May 2007 12:50:06 +0200

Hi,

Multipart/alternative is interesting. I guess that, for SDP, it could be
used to provide different "offer alternatives". I think it would be good
to compare it against some of the other grouping/alternative mechanisms
we have defined for that purpose.

Regards,

Christer

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] 
> Sent: 30. huhtikuuta 2007 19:13
> To: [email-masked]
> Subject: Re: [Sip] Support for Multipart/MIME
> 
>    From: Cullen Jennings <[email-masked]>
> 
>    I think the WG should consider an update to 3261 (likely 
> done through  
>    the process Keith has proposed) that makes this multipart/MIME  
>    mandatory to implement.
> 
> I assume that the requirement is that if a message has a 
> multipart/alternative body, and the UA is capable of 
> understanding one part of the body, then it must be able to 
> extract that part and use it to process the message.
> 
> Dale
> 
> 
> _______________________________________________
> 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: "Dan Wing" <[email-masked]>
Date: Wed, 9 May 2007 12:15:29 -0700

The now-expired draft
http://tools.ietf.org/html/draft-jennings-sipping-multipart-02 explored
multipart/alternative.  One difficulty, however, is what does it mean to say
"can understand a part".

This is easy if one part is SDP and another part is SDPng.  If you
understand SDPng, you process it; if you don't, you process the SDP.

However, it's really hard if one part is SDP and another part is also SDP --
in some cases we would like the answerer to "pick the better SDP".  At the
time, we were considering multipart/alternative as a way to offer RTP
(RTP/AVP) and SRTP (RTP/SAVP), but we found it doesn't work well at all.
Since then, draft-ietf-mmusic-sdp-capability-negotiation is a superior
solution to sending an offer containing RTP and SRTP.  

I suppose we could avoid the difficulty by prohibiting identical
Content-Types in the alternatives.

-d

> From: Christer Holmberg (JO/LMF) 
> [mailto:[email-masked]] 
> Sent: Thursday, May 03, 2007 3:50 AM
> To: [email-masked]; [email-masked]
> Subject: RE: [Sip] Support for Multipart/MIME
> 
> 
> Hi,
>

---

From: Paul Kyzivat <[email-masked]>
Date: Wed, 09 May 2007 15:37:38 -0400

Dan Wing wrote:
> in some cases we would like the answerer to "pick the better SDP". 

The creator of the multipart/alternative has the job of picking which is 
the better one. By definition they alternatives are ordered with the 
preferred one last. (There is an assumption the the the preferred one is 
the least widely implemented, and the least preferred one is the most 
widely implemented.) You are supposed to process the *last* one that you 
are *capable* of processing.

But your point still remains. If there are two SDP alternatives, how do 
you decide if you can implement the last one? You are allowed to ignore 
much of SDP if you don't understand it. But is that supporting it?

> At the

Or just clearly define what it means to support one in an alternative.

	Paul

---

From: "James M. Polk" <[email-masked]>
Date: Wed, 09 May 2007 14:40:53 -0500

It's possible/probable/obvious (depending on who you talk to) that 
multipart will have to be supported for emergency calling, in which 
there is an SDP body and a Location message body...

This doesn't mean UAs that *don't* establish voice/video dialogs will 
have to support multipart, just for those UAs that do establish 
voice/video dialogs with emergency response centers (again, depending 
on who you talk to).

---

From: "Dan Wing" <[email-masked]>
Date: Wed, 9 May 2007 13:16:09 -0700

> voice/video dialogs with emergency response centers (again, depending 

By support, you mean such a UA would need to be able to send an 
Invite with a multipart, right?  That is, such a UA wouldn't need 
to necessarily receive or need to parse multipart for the purposes 
of emergency calling.

(It's quite trivial to send multipart, and obviously more difficult
to handle parsing it, especially nested multiparts.  Not impossible --
it's been done for years and years by mail user agents, afterall,
but it's also not slam-dunk easy.)

-d

---

From: Ted Hardie <[email-masked]>
Date: Wed, 9 May 2007 13:22:53 -0700

At 2:40 PM -0500 5/9/07, James M. Polk wrote:
>It's possible/probable/obvious (depending on who you talk to) that multipart will have to be supported for emergency calling, in which there is an SDP body and a Location message body...
>
>This doesn't mean UAs that *don't* establish voice/video dialogs will have to support multipart, just for those UAs that do establish voice/video dialogs with emergency response centers (again, depending on who you talk to).

That won't be multipart/alternative, though, as the location body and the SDP body
won't be alternatives but independent items.   I think they would be
multipart/mixed.  See this from RFC 2046:

5.1.3.  Mixed Subtype

   The "mixed" subtype of "multipart" is intended for use when the body
   parts are independent and need to be bundled in a particular order.
   Any "multipart" subtypes that an implementation does not recognize
   must be treated as being of subtype "mixed".

5.1.4.  Alternative Subtype

   The "multipart/alternative" type is syntactically identical to
   "multipart/mixed", but the semantics are different.  In particular,
   each of the body parts is an "alternative" version of the same
   information.

<snip>
				Ted

---

From: Dean Willis <[email-masked]>
Date: Wed, 9 May 2007 15:52:01 -0500

On May 9, 2007, at 3:22 PM, Ted Hardie wrote:

>> multipart will have to be supported for emergency calling, in  
>> which there is an SDP body and a Location message body...
>>
>> This doesn't mean UAs that *don't* establish voice/video dialogs  
>> will have to support multipart, just for those UAs that do  
>> establish voice/video dialogs with emergency response centers  
>> (again, depending on who you talk to).
>

Right. Mixed is a far cleaner semantic problem than alternative. It  
means "Use all of these that you understand, to the best of your  
ability, and complain if there's nothing you understand."

--
Dean

---

From: "Dan Wing" <[email-masked]>
Date: Wed, 9 May 2007 14:09:35 -0700

> ability, and complain if there's nothing you understand."

I agree that multipart/mixed makes sense when you're sending
different content-types and you want the receiver to process each
one that he understands.  This is useful if you're doing an Invite
that includes your location (application/sdp and 
application/pidf+xml [draft-ietf-sip-location-conveyance]).

However, if you're sending SDP and SDPng, multipart/mixed does not
make sense.  If you're sending SDP and SDPng, you want the answerer 
to pick one.  For the next decade, anyone that understands SDPng 
will also need to continue to understand SDP.  And we don't want the
receiver to creatively use both the SDP offer and the SDPng offer.

Email is similar:  if you configure Thunderbird or Outlook to send 
messages with text/plain and text/html they are put inside 
multipart/related, not multipart/mixed.

-d

---

From: Ted Hardie <[email-masked]>
Date: Wed, 9 May 2007 14:25:35 -0700

>multipart/related, not multipart/mixed.

I totally agree.  It seems like multipart/mixed, multipart/alternative,
and possibly multipart/related will be needed for different uses.
		regards,
				Ted

---

From: Paul Kyzivat <[email-masked]>
Date: Wed, 09 May 2007 17:55:32 -0400

> receiver to creatively use both the SDP offer and the SDPng offer.

It seems that this issue is moot, since SDPng seems to have been 
declared dead.

> multipart/related, not multipart/mixed.

Don't you mean multipart/alternative?

	Paul

---

From: "Dan Wing" <[email-masked]>
Date: Wed, 9 May 2007 15:13:25 -0700

> It seems that this issue is moot, since SDPng seems to have been 

Yes, it seems that way.

> Don't you mean multipart/alternative?

Argh, yes.  Thanks for catching that mistake.

Anyway - someone needs to run with this multipart/mixed for sure,
and probably also multipart/alternative and multipart/related (per
Ted's suggestion, although I don't see a use case for multipart/
related at the moment).  I no longer have the bandwidth to 
coauthor draft-jennings-sipping-multipart.

-d

---

From: Paul Kyzivat <[email-masked]>
Date: Wed, 09 May 2007 18:26:50 -0400

> ability, and complain if there's nothing you understand."

IIUC you needn't complain if you don't understand any of the parts.

Rather, the handling parameter of the Content-Disposition header of each 
part needs to be examined. For handling=optional the part can be ignored 
if you don't understand it. For handling=required you need to complain 
if you don't understand it.

So for example, you could have an INVITE that contains a multipart/mixed 
where the parts are:
- a part with Content-Type:text/plain and
   Content-Disposition:render;handling=optional.
- a part with Content-Type:image/gif and
   Content-Dispostion:icon;handling=optional

This should be treated as an offerless INVITE even if neither subpart is 
understood.

The case of location conveyance does present an interesting issue that I 
have wondered about for some time and never found an answer to:

Suppose you are making a call, and for some reason think that providing 
location information will be helpful. But it isn't critical that the 
recipient understand it. So you send a request like:

    INVITE sips:[email-masked] SIP/2.0
    Via: SIP/2.0/TLS pc33.atlanta.example.com;branch=z9hG4bK74bf9
    Max-Forwards: 70
    To: Bob <sips:[email-masked]>
    From: Alice <sips:[email-masked]>;tag=9fxced76sl
    Call-ID: [email-masked]
    Geolocation: <cid:[email-masked]>
      ;inserted-by=endpoint
    Supported: geolocation
    Accept: application/sdp, application/pidf+xml
    CSeq: 31862 INVITE
    Contact: <sips:[email-masked]>
    Content-Type: multipart/mixed; boundary=boundary1
    Content-Length: ...

    --boundary1

    Content-Type: application/sdp

    ...SDP here

    --boundary1

    Content-Type: application/pidf+xml
    Content-ID: [email-masked]
    Content-Disposition:???;handling=optional

    <?xml version="1.0" encoding="UTF-8"?>
        <presence xmlns="urn:ietf:params:xml:ns:pidf"
           xmlns:gp="urn:ietf:params:xml:ns:pidf:geopriv10"
           xmlns:cl="urn:ietf:params:xml:ns:pidf:geopriv10:civicAddr"
           xmlns:gs="urn:ietf:params:xml:ns:pidf:geopriv10:geoShape"
           entity="pres:[email-masked]">
         <tuple id="sg89ae">
          <timestamp>2007-03-20T14:00:00Z</timestamp>
          <status>
           <gp:geopriv>
             ...
           </gp:geopriv>
          </status>
         </tuple>
        </presence>
    --boundary1--

You need the Content-Dispostion header so that you can insert the 
handling=optional parameter. But what is the content-disposition value? 
None of the currently defined values, such as "session", or "render" 
seems appropriate.

In some sense its content-disposition is irrelevant because the 
processing of the part is determined by the cid: reference in the 
Geolocation header. But a UAS that doesn't understand the Geolocation 
header won't know that.

We have some parts whose handling is governed by their type and 
disposition, without need of explicit reference from another header. And 
we have other parts that shouldn't be processed at all unless there is 
an explicit reference to them elsewhere that has itself been understood. 
IMO there needs to be a Content-Disposition that covers the latter case. 
But that has never been recognized and specified.

This of course is a potential issue even if the body part is there by 
itself, without an enclosing multipart.

	Paul

---

From: "Christer Holmberg \(JO/LMF\)" <[email-masked]>
Date: Thu, 10 May 2007 03:55:23 +0200

Hi, 

>The now-expired draft
http://tools.ietf.org/html/draft-jennings-sipping-multipart-02
>explored multipart/alternative.  One difficulty, however, is what does
it mean to say "can understand a part".
> 
>This is easy if one part is SDP and another part is SDPng.  
>If you understand SDPng, you process it; if you don't, you 
>process the SDP.
> 
>However, it's really hard if one part is SDP and another part 
>is also SDP -- in some cases we would like the answerer to 
>"pick the better SDP".

It doesn't always have to be about picking what is best.

For example:

Assume a terminal supports audio and video. If both audio and video are
used, it supports codecs audio_X and video_X.

However, if only audio OR video are used, the terminal has more
resources available, to it could use the more-resource-using codecs
audio_Y and video_Y.

In this case I don't think it's about picking based on what is "better",
it's about picking based on what will be used for the session. 

Now, I am sure there are other ways of doing this, but this solution
would not require support of any SDP extensions (multipart/alternative
would of course have to be supported), and the same port number could be
used for the audio and/or media m= lines in all alternatives.

Regards,

Christer

>At the time, we were considering multipart/alternative as a way to
offer RTP (RTP/AVP) and SRTP (RTP/SAVP), but we found >it doesn't work
well at all.
>Since then, draft-ietf-mmusic-sdp-capability-negotiation is a 
>superior solution to sending an offer containing RTP and SRTP.  
> 
> I suppose we could avoid the difficulty by prohibiting 
> identical Content-Types in the alternatives.
> 
> -d
> 
> 
> > Multipart/alternative is interesting. I guess that, for 
> SDP, it could 
> > be used to provide different "offer alternatives". I think 
> it would be 
> > good to compare it against some of the other grouping/alternative 
> > mechanisms we have defined for that purpose.
> > 
> > Regards,
> > 
> > Christer
> >  
> > 
> > >    I think the WG should consider an update to 3261 (likely done 
> > > through
> understanding 
> > > one part of the body, then it must be able to extract 
> that part and 
> > > use it to process the message.
> > > 
> > > Dale
> > > 
> > > 
> > > [email-masked] for questions on current sip Use 
> > > [email-masked] for new developments on the application of sip
> > > 
> > 
> > 
> > [email-masked] for questions on current sip Use 
> > [email-masked] for new developments on the application of sip
>

---

From: "Dan Wing" <[email-masked]>
Date: Wed, 9 May 2007 19:03:06 -0700

> Sent: Wednesday, May 09, 2007 6:55 PM
> To: Dan Wing; [email-masked]
> Cc: [email-masked]

Using the same port number on multiple m= lines has been, and
continues to be, a direct violation of several SDP 
specifications.  Even the SDP grouping specification explicitly
calls this out as illegal.

Draft-ietf-mmusic-sdp-capability-negotiation is 100% backwards
compatible with endpoints that don't understand it.  Multipart/
alternative will never share that characteristic; the last 
SIPIT showed how poorly multipart is supported today and
there is no way, when you build an offer, to know if all of
the answerers will understand multipart/alternative.  HERFP
rears its head, too.

I had thought there was consensus around the need for
draft-ietf-mmusic-sdp-capability-negotiation -- I am mistaken?

-d

---

From: "Christer Holmberg \(JO/LMF\)" <[email-masked]>
Date: Thu, 10 May 2007 04:14:02 +0200

Hi, 

>>Assume a terminal supports audio and video. If both audio and video 
>>are used, it supports codecs audio_X and video_X.
>> 
>>In this case I don't think it's about picking based on what is 
>>"better", it's about picking based on what will be used for the 
>>session.
>> 
>>Now, I am sure there are other ways of doing this, but this 
>>solution would not require support of any SDP extensions 
>>(multipart/alternative would of course have to be supported), and the
same port 
>>number could be used for the audio and/or media m= lines in all
alternatives.
>specifications.  Even the SDP grouping specification 
>explicitly calls this out as illegal.

Yes. But in the multipart/alternative example I gave you (and which is
ilustrated in a simple form below) would have 3 individual SDP bodies,
and the same port number would not be used within a single SDP bodies. 

But, the same port number would be used in each indivudual SDP body, and
as far as I know there is no specification which forbids that.

-----boundary

m=audio 9999 audio_x
m=video 7777 video_x

-----boundary

m=video 7777 video_y

-----boundary

m=audio 9999 audio_y

-----boundary--

Regards,

Christer

>Draft-ietf-mmusic-sdp-capability-negotiation is 100% backwards
compatible with endpoints that don't understand it. 
>Multipart/ alternative will never share that characteristic; the last
SIPIT showed how poorly multipart is supported 
>today and there is no way, when you build an offer, to know if all of
the answerers will understand 
>multipart/alternative. HERFP rears its head, too.
>

---

From: Dean Willis <[email-masked]>
Date: Wed, 09 May 2007 23:20:20 -0500

> it's about picking based on what will be used for the session. 

better is relative and one man's lutefisk is another's cat food.

Perhaps what we need to say here is "preferred by the receiver".

--
Dean

---

From: "Dan Wing" <[email-masked]>
Date: Wed, 9 May 2007 21:27:02 -0700

> But, the same port number would be used in each indivudual 
> SDP body, and as far as I know there is no specification which 
> forbids that.
> 
> -----boundary
> 
> m=audio 9999 audio_x
> m=video 7777 video_x
> 
> -----boundary
> 
> m=video 7777 video_y
> 
> -----boundary
> 
> m=audio 9999 audio_y
> 
> -----boundary--

This can be expressed with MMUSIC's capabilities negotiation, though -- and
can be expressed better than with multipart/alternative because MMUSIC's
capability negotiation defines preferences of each m= and each a= line,
whereas multipart/alternative can only ever allow simple "take all of this
SDP" or "take none of this SDP".

(With the specific example you show, of course, you don't even need MMUSIC's
capabilities negotiation -- an answerer that doesn't support video (or
doesn't support audio) can already indicate that in its SDP answer.)

-d

---

From: Ted Hardie <[email-masked]>
Date: Wed, 9 May 2007 21:28:18 -0700

>Perhaps what we need to say here is "preferred by the receiver".

We've lost a bit of context here, but presuming that we're still
talking about multipart/alternative, that's not quite the model.
The preference order is set by the sender, it is explicit that the
receiver should take the first body it can handle.  If  you want
some other semantic (where all of them presented and the
receiver selected among them), I believe you'd have to use
a different MIME type.
	
				regards,
					Ted

---

From: "Christer Holmberg \(JO/LMF\)" <[email-masked]>
Date: Thu, 10 May 2007 06:54:01 +0200

Hi, 

Comment at the end.

> specifications.  
> > >Even the SDP grouping specification explicitly calls this out as 
> > >illegal.
> > 
> SDP body, 
> > and as far as I know there is no specification which forbids that.
> > 
> > -----boundary
> > 
> > m=audio 9999 audio_x
> > m=video 7777 video_x
> > 
> > -----boundary
> > 
> > m=video 7777 video_y
> > 
> > -----boundary
> > 
> > m=audio 9999 audio_y
> > 
> > -----boundary--
> 
> This can be expressed with MMUSIC's capabilities negotiation, 
> though -- and can be expressed better than with 
> multipart/alternative because MMUSIC's capability negotiation 
> defines preferences of each m= and each a= line, whereas 
> multipart/alternative can only ever allow simple "take all of 
> this SDP" or "take none of this SDP".
> 
> (With the specific example you show, of course, you don't 
> even need MMUSIC's capabilities negotiation -- an answerer 
> that doesn't support video (or doesn't support audio) can 
> already indicate that in its SDP answer.)

The point is that, depending on what media the answerer chooses,
different codecs can be used for chosen media streams.

Yes, "vanilla" SDP allows me to offer audio and video, and the answerer
can incdicate what it does/doesn't support. But, vanilla SDP does not
allow the offer to say: "Here is audio and video. If you accept both
then let's use these codecs, but if you only choose audio then let's use
theis other codec". 

Regards,

Christer

---

From: "Dan Wing" <[email-masked]>
Date: Wed, 9 May 2007 22:17:39 -0700

> then let's use these codecs, but if you only choose audio 

SDP Capabilities Negotiation does that, too -- and far better than
multipart/alternative.

-d

---

From: "Christer Holmberg \(JO/LMF\)" <[email-masked]>
Date: Thu, 10 May 2007 07:59:30 +0200

Hi, 

>>Yes, "vanilla" SDP allows me to offer audio and video, and the 
>>answerer can incdicate what it does/doesn't support. But, vanilla SDP 
>>does not allow the offer to say: "Here is audio and video. If you 
>>accept both then let's use these codecs, but if you only choose audio 
>>then let's use theis other codec".
> 
>SDP Capabilities Negotiation does that, too -- and far better 
>than multipart/alternative.

I haven't seen any comparision between the mechanisms, so I can't
comment on the "far better" statement at this point.

But, in order to do the same thing with SDP CapNeg, I assume it does
require the remote terminal to actually support SDP CapNeg?

I agree that many terminals don't support multipart today, but wasn't
the initial issue of this thread that we want to mandate the support of
multipart (at least multipart/mixed)?

Also, my initial intention was not to compare multipart/alternative with
SDP CapNeg, but to give an example what multipart/alternative could be
used for.

Regards,

Christer

---

From: "Christer Holmberg \(JO/LMF\)" <[email-masked]>
Date: Thu, 10 May 2007 08:02:30 +0200

>>In this case I don't think it's about picking based on what is
"better", it's about picking based on what will be used 
>>for the session.

Correct.

Regards,

Christer

---

From: "Dan Wing" <[email-masked]>
Date: Wed, 9 May 2007 23:14:38 -0700

> comment on the "far better" statement at this point.

Ok.  I'll let Flemming or one of the other people deep into the SDP
capability negotiation comment on the virtues of it versus 
multipart/alternative with several different SDP parts.

> the initial issue of this thread that we want to mandate the 
> support of multipart (at least multipart/mixed)?

Yes.  But multipart/mixed isn't useful selecting the 'best' SDP; it's
useful for throwing a bunch of different content types into one SIP
body (SDP and location, for example).

> SDP CapNeg, but to give an example what multipart/alternative could be

I have become convinced, through my efforts with RTPSEC, that 
multipart/alternative is harmful if it contains multiple SDP parts.

So if there is something other than SDP that multipart/alternative 
might help with -- and there very well could be -- throw it out
for discussion.  

-d

---

From: "Christer Holmberg \(JO/LMF\)" <[email-masked]>
Date: Thu, 10 May 2007 16:42:27 +0200

Hi, 

>>But, in order to do the same thing with SDP CapNeg, I 
>>assume it does require the remote terminal to actually support SDP
CapNeg?
>>the initial issue of this thread that we want to mandate 
>>the support of multipart (at least multipart/mixed)?
> 
>Yes.  But multipart/mixed isn't useful selecting the 'best' 
>SDP; it's useful for throwing a bunch of different content 
>types into one SIP body (SDP and location, for example).

Correct, but with multipart I meant both mixed and alternative.

>>Also, my initial intention was not to compare multipart/alternative 
>>with SDP CapNeg, but to give an example what multipart/alternative 
>>could be used for.

Again, I am not in a position to disagree with you ,but is that
harmfulness documented somewhere?

Regards,

Christer

---

From: "Dan Wing" <[email-masked]>
Date: Thu, 10 May 2007 09:18:36 -0700

> harmfulness documented somewhere?

Nope.  If we're going to move multipart/* forward in SIP, though,
I'll be happy to write that section.

-d

---

From: Paul Kyzivat <[email-masked]>
Date: Thu, 10 May 2007 13:22:09 -0400

I think it will be easier to make progress on multipart/mixed than 
multipart/alternative. It appears that making progress on alternative 
will be difficult without some use cases to help in defining what it 
means to "support" one of the alternatives.

	Paul

---

From: "Francois Audet" <[email-masked]>
Date: Thu, 10 May 2007 13:01:04 -0500

I think we are on to something here. I believe that Paul Kyzivat and Dan
Wing have it
right.

What I'd like to see is something describing the following:

- How to use Multipart/mixed

  I think Paul Kyzivat and Dan had some good explanation in this thread
about it. 
  We should really make proper treatment of multipart/mixed as mandatory
as we can. 
  This means, being able to understand parse the nested MIME bodies that
you DO support.
  At a miminum, an implementation should be able to find in a
Multipart/mixed the SDP
  for example. We probably need also to write some recommnedation on
what happens if
  there is multiple SDPs in that multipart mixed.

  It's not pretty out there. I've seen implementations that don't even
send 415
  when receiving multipart/mixed: they just ignore the payload, and
believe
  it's an SDP-less INVITE. They then put an offer in the response, which
the
  real offerer believes is an answer. Then all hell breaks loose.

  Some of them do send 415, but without the supported payload type in an
Accept 
  header in 415.

- Multipart/alternative

  I agree with Dan that using Multipart/alternative in the way that was
described
  in draft-jennings-sipping-multipart section 5 is in fact harmful.
Especially now that we
  are defining capability negotiation. Section 6 would be OK, but now
that SDPng is gone,
  it's irrelevant.

  What we really need to say is that multipart/alternative may be used
only when we
  are using alternative payload types for the same information. For
example, text/html and 
  text/xml or whatever. It would be applicable if one day we re-created
another SDPng 
  for example.

  Section 3.1 explains this relatively well, but is restricted to Offers
(for which we have
  no use cases anymore). I think it should instead talk about other
examples (e.g.,
  text/html, text/xml, or maybe some example with pictures).

  I really believe section 5 goes against the spririt of section 3.1
(specifically, of
  the quote of RFC 2046). What it really has it two application/sdp (one
of them is 
  encrypted inside a application/pkcs7mime), but really it's still two
application/sdp

  But we should make it clear that it is NOT for negotiating multiple
alternatives of 
  the same payload type, in particular, not for application/sdp &
application/sdp.
  
If we decide to go forward, I'd be happy to help too.

> From: Dan Wing [mailto:[email-masked]] 
> Sent: Thursday, May 10, 2007 09:19
> To: 'Christer Holmberg (JO/LMF)'; [email-masked]
> Cc: [email-masked]
> Nope.  If we're going to move multipart/* forward in SIP, 
> though, I'll be happy to write that section.
> 
> -d
> 
>

---

From: "Christer Holmberg \(JO/LMF\)" <[email-masked]>
Date: Fri, 11 May 2007 01:52:50 +0200

Hi, 
 
>   the same payload type, in particular, not for application/sdp &

In my example earlier it was not about negotiting multiple alternatives
of the same payload type.

But, anyway, if we want to forbid app/sdp & app/sdp we need good
technical justification for that, but my understanding is that Dan
indicated he would be able to provide that.

Regards,

Christer

---

From: Paul Kyzivat <[email-masked]>
Date: Thu, 10 May 2007 20:15:06 -0400

>   there is multiple SDPs in that multipart mixed.

I would like to bring up something that isn't discussed much: 
Content-Disposition. I brought it up earlier in this thread for a 
slightly different reason.

One *should not* look for a particular body part of interest solely 
based on the Content-Type. Both the content type and the content 
disposition need to be correct. For instance, a body part with content 
type of application/sdp should not be considered an offer or answer 
unless the content-disposition is "session". (This is confused because 
there are are also defaulting rules for content-disposition.)

*In principle* you could have a multipart/mixed that had to parts, both 
with content-type of application/sdp. This could be quite legal if only 
one of them had content-disposition of "session" and the other had some 
other content-disposition. It would be sufficient for the other to have 
"Content-Disposition:foo;handling=optional".

I realize this is obscure, and it isn't likely that anyone will be 
including an sdp body part that isn't intended to be an offer or answer. 
But we are writing the specs here, and we ought to be complete and 
precise about it.

>   text/xml or whatever. It would be applicable if one day we re-created

The perfect example for that is MESSAGE with text/plain and text/html, 
quite analogous to an email message.

> If we decide to go forward, I'd be happy to help too.

I don't have time to take authorship of the document, but I too can 
contribute some text.

	Paul

---

From: "Dan Wing" <[email-masked]>
Date: Thu, 10 May 2007 17:36:58 -0700

...
> unless the content-disposition is "session". (This is 
> confused because there are are also defaulting rules for 
> content-disposition.)
>

Yes, it's obscure, but that's alright.  There is the annoying
backward compatibility issue with lack of Content-Disposition,
too -- RFC3261 section 13.2.1, "Creating the Initial INVITE":

 >  If the Content-Disposition header field is missing, bodies of
 >  Content-Type application/sdp imply the disposition "session", while
 >  other content types imply "render".

...
> > 
> >   What we really need to say is that multipart/alternative 
> > may be used only when we
> >   text/xml or whatever. It would be applicable if one day 
> > we re-created another SDPng for example.
> 
> The perfect example for that is MESSAGE with text/plain and 
> text/html, quite analogous to an email message.

That is sufficient justification to include multipart/alternative.

-d

---

From: "Christer Holmberg \(JO/LMF\)" <[email-masked]>
Date: Fri, 11 May 2007 03:44:22 +0200

Hi,

The following is not a proposal, but more "brain storming".

Would it be helpful to have a SIP header, e.g. Content-Type-List, which
would list the different Content-Types in a multipart/* body. 

A node could then first check that header in order to see whether the
multipart/* contains something a specific node is interested in -
without having to parse the full multipart/* body first. It could speed
up the processing in nodes which may have interest only in a small set
of Content-Types.

Comments?

Regards,

Christer

---

From: "Dan Wing" <[email-masked]>
Date: Thu, 10 May 2007 19:14:54 -0700

An interesting optimization, but it doesn't appeal to me:

  * if they're out of sync, which one takes precedence (that is, do I
process a Content-Type that isn't listed in the Content-Type-List?)
  * if a UA knew an intermediate box used Content-Type-List, the UA could
use Content-Type-List to make the intermediate box think some sort of
Content-Type is not present.  That additional content-type might contain the
secret of the universe, which the intermediate box really needed to know.
  * looking for "^Content-Type *:" isn't too hard; you don't really need to
bother parsing MIME and looking for nested parts unless there is, in fact, a
content-type you care about.  Per Paul's message, if you only want ones with
Content-Disposition: session, you could look for that string within 4-5
lines of Content-Type; if you found it, then you could parse the MIME in the
body.

-d

> Sent: Thursday, May 10, 2007 6:44 PM
> To: Paul Kyzivat; Dan Wing
> Cc: [email-masked]; [email-masked]

---

From: "Christer Holmberg \(JO/LMF\)" <[email-masked]>
Date: Fri, 11 May 2007 06:13:17 +0200

Hi, 

>* if they're out of sync, which one takes precedence (that 
>is, do I process a Content-Type that isn't listed in the 
>Content-Type-List?)

The Content-Type contains "multipart/*", while the Content-Type-List
contains the types (app/sdp, app/isup, app/whatever etc) within that
multipart.

Please note that I am talking about SIP headers, not in the MIME bodies
(of course, if a MIME body contains another multipart/*, the header
could perhaps also be used there).

>* if a UA knew an intermediate box used Content-Type-List, 
>the UA could use Content-Type-List to make the intermediate 
>box think some sort of Content-Type is not present.  That 
>additional content-type might contain the secret of the 
>universe, which the intermediate box really needed to know.

Well, this depends on the functionality of the middle-box.

If the middle-box is going to do some kind of policing, or otherwise
verify that the multipart actually contains what is claimed in the
Content-Type-List, it will have to parse the multipart anyway.

>* looking for "^Content-Type *:" isn't too hard; you don't 
>really need to bother parsing MIME and looking for nested 
>parts unless there is, in fact, a content-type you care 
>about.  Per Paul's message, if you only want ones with
>Content-Disposition: session, you could look for that string 
>within 4-5 lines of Content-Type; if you found it, then you 
>could parse the MIME in the body.

I don't think it's that easy. Assume one MIME body contains a SIP
message (or part of a SIP message), or any other protocol which uses the
Content-Type header, which is not the Content-Type header of the MIME
body itself. The same goes for Content-Disposition.

Regards,

Christer

> > without having to parse the full multipart/* body first. It could 
> > speed up the processing in nodes which may have interest only in a 
> > small set of Content-Types.
> > 
> > Comments?
> > 
> > Regards,
> > 
> > Christer
>

---

From: Paul Kyzivat <[email-masked]>
Date: Fri, 11 May 2007 00:28:19 -0400

>> is, do I process a Content-Type that isn't listed in the 

I'm with Dan on this. Also, this is well trodden ground in email, and 
they haven't found a need for this.

> could perhaps also be used there).

There really isn't any difference between sip headers and mime headers. 
 From a mime perspective the entire sip message is just a bunch of mime 
headers including some that are extension headers.

> body itself. The same goes for Content-Disposition.

IMO the servers that care about what is in the bodies should just bite 
the bullet and do the necessary parsing. Frankly, middle boxes shouldn't 
be looking at bodies anyway.

	Paul

---

From: "Dan Wing" <[email-masked]>
Date: Thu, 10 May 2007 22:34:32 -0700

> Sent: Thursday, May 10, 2007 9:13 PM
> To: Dan Wing; Paul Kyzivat

Let me clarify my point about that new Content-Type-List header
being out of sync with the body.  Here is an example -- a SIP 
header containing, among other things:

  From: ...
  To: ...
  Content-Type-List: application/sdp
  Content-Type: multipart/mixed; boundary=B

and the body contains:

  --B
  Content-Type: application/sdp
  Content-Disposition: session

  v=0
  ...

  --B
  
  --B--

In such a situation, a device which supports Content-Type-List in an effort
to optimize its MIME parsing, wouldn't know there is a "Content-Type:
application/pidf+xml" in the body.

> Content-Type-List, it will have to parse the multipart anyway.

Right.

Proxies are supposed to ignore the body, so what sort of devices
which aren't enforcing policy might benefit from the 
Content-Type-List optimization?

> body itself. The same goes for Content-Disposition.

Yes, there can of course be false-positives; the same sort of
false positives would occur with Content-Type-List:  it could
list a content-type which is inside of a MIME part you wouldn't
otherwise process (due to the wrong Content-Disposition, for
example).

-d

---

From: "Christer Holmberg \(JO/LMF\)" <[email-masked]>
Date: Fri, 11 May 2007 07:45:43 +0200

Hi Dan,

Couldn't you get this out of sync already today?

You get a SIP message with application/sdp, and then the message body
contains something else...

Regards,

Christer

> Sent: 11. toukokuuta 2007 8:35
> To: Christer Holmberg (JO/LMF); 'Paul Kyzivat'
> is, do I 
> > Please note that I am talking about SIP headers, not in the MIME 
> > bodies (of course, if a MIME body contains another multipart/*, the 
> > header could perhaps also be used there).
> 
> Let me clarify my point about that new Content-Type-List 
> header being out of sync with the body.  Here is an example 
> -- a SIP header containing, among other things:
> 
>   From: ...
>   To: ...
> In such a situation, a device which supports 
> Content-Type-List in an effort to optimize its MIME parsing, 
> wouldn't know there is a "Content-Type:
> > >* if a UA knew an intermediate box used Content-Type-List, the UA 
> > >could use Content-Type-List to make the intermediate box 
> think some 
> > >sort of Content-Type is not present.  That additional content-type 
> > >might contain the secret of the universe, which the 
> intermediate box 
> > >really needed to know.
> > 
> Proxies are supposed to ignore the body, so what sort of 
> devices which aren't enforcing policy might benefit from the 
> > >* looking for "^Content-Type *:" isn't too hard; you don't really 
> > >need to bother parsing MIME and looking for nested parts 
> unless there 
> > >is, in fact, a content-type you care about.  Per Paul's 
> message, if 
> > >you only want ones with
> > >Content-Disposition: session, you could look for that 
> string within 
> > >4-5 lines of Content-Type; if you found it, then you could 
> parse the 
> > >MIME in the body.
> > 
> > message (or part of a SIP message), or any other protocol 
> which uses 
> > the Content-Type header, which is not the Content-Type 
> header of the 
> > MIME body itself. The same goes for Content-Disposition.
> 
> list a content-type which is inside of a MIME part you 
> wouldn't otherwise process (due to the wrong 
> Content-Disposition, for example).
> 
> -d
> 
> 
> > Regards,
> > 
> > Christer
> > 
> > 
> > 
> >

---

From: "Christer Holmberg \(JO/LMF\)" <[email-masked]>
Date: Fri, 11 May 2007 07:52:26 +0200

Hi, 

>I'm with Dan on this. Also, this is well trodden ground in 
>email, and they haven't found a need for this.

Email does not have the same real-time requirements which SIP has.

>>contains the types (app/sdp, app/isup, app/whatever etc) 
>>within that multipart.
>> 
>From a mime perspective the entire sip message is just a 
>bunch of mime headers including some that are extension headers.

My point was that you can't determine what types of MIME bodies you have
simply by taking the whole SIP message and performing a string search on
"Content-Type". Because, some of the Content-Types you will find may not
describe what is in a MIME body - it may be part of the MIME body data.

-----boundary

Content-Type: protocol/sip

To: [email-masked]
From: [email-masked]

-----boundary

In this example the string search will find two "Content-Type", but only
one of them actually describes the content of the MIME body, while the
other is just data inside that body.

Regards,

Christer

---

From: "Dan Wing" <[email-masked]>
Date: Thu, 10 May 2007 23:18:22 -0700

> My point was that you can't determine what types of MIME 
> bodies you have simply by taking the whole SIP message and 
> performing a string search on "Content-Type". Because, some 
> of the Content-Types you will find may not describe what 
> is in a MIME body - it may be part of the MIME body data.

Fully agreed that you could get false positives from such
a test!  But you'll never get a false negative from such
a test.  My point was that if you're trying to optimize, 
and also needing to avoid a UA that is lying, doing a 
search of the Content-Type strings is what you want.

-d

---

From: Paul Kyzivat <[email-masked]>
Date: Fri, 11 May 2007 08:20:32 -0400

> contains something else...

No you can't. If the sip message has Content-Type:application/sdp then 
*by definition* the body contains sdp. If it doesn't look like sdp then 
it is just syntactically incorrect sdp. The Content-Type in the message 
is not redundant with one in the body - it is the one for the body.

	Paul

>> within that

---

From: Paul Kyzivat <[email-masked]>
Date: Fri, 11 May 2007 08:25:10 -0400

> describe what is in a MIME body - it may be part of the MIME body data.

All that you need to do is reduce unnecessary parsing to an acceptable 
degree. If all you care about is sdp, then it is probably sufficient to 
search the body for the string "application/sdp", and only parse the 
body looking for sdp if you find that. Now and then you may encounter a 
body that contains "application/sdp" without actually containing an 
offer or answer. But as long as that is rare there will probably be no 
problem.

This puts the optimization entirely on the parser without requiring any 
changes by those that add bodies. That is a good thing. It also keeps 
the size of the message from increasing further, which is also a good thing.

	Paul

---

From: "Francois Audet" <[email-masked]>
Date: Fri, 11 May 2007 11:12:29 -0500

I think what we need to do is describe what you are explaining here, but
we need to make sure that we don't introduce backward compatibility
problems.

(e.g., maybe if Content-disposition: session is not present, it is
assumed
to mean session?)

> From: Paul Kyzivat [mailto:[email-masked]] 
> Sent: Thursday, May 10, 2007 17:15
> To: Audet, Francois (SC100:3055)
> Cc: Dan Wing; Christer Holmberg (JO/LMF); 
> [email-masked]; [email-masked]
>
> Content-Disposition. I brought it up earlier in this thread 
> for a slightly different reason.
> 
> One *should not* look for a particular body part of interest 
> solely based on the Content-Type. Both the content type and 
> the content disposition need to be correct. For instance, a 
> body part with content type of application/sdp should not be 
> considered an offer or answer unless the content-disposition 
> is "session". (This is confused because there are are also 
> defaulting rules for content-disposition.)
> 
> *In principle* you could have a multipart/mixed that had to 
> parts, both with content-type of application/sdp. This could 
> be quite legal if only one of them had content-disposition of 
> "session" and the other had some other content-disposition. 
> It would be sufficient for the other to have 
> I realize this is obscure, and it isn't likely that anyone 
> will be including an sdp body part that isn't intended to be 
> an offer or answer. 
> But we are writing the specs here, and we ought to be 
> complete and precise about it.

---

From: "Francois Audet" <[email-masked]>
Date: Fri, 11 May 2007 11:13:28 -0500

> > >   What we really need to say is that multipart/alternative may be 
> > > used only when we
> > >   text/xml or whatever. It would be applicable if one day we 
> > > re-created another SDPng for example.
> > 

Exactly what I had in mind. I was suggesting we replace the SRTP example
in 
the document with this example.

---

From: "Dan Wing" <[email-masked]>
Date: Fri, 11 May 2007 09:41:17 -0700

> From: Francois Audet [mailto:[email-masked]] 
> Sent: Friday, May 11, 2007 9:12 AM
> To: Paul Kyzivat
> assumed to mean session?)

RFC3261 says that already, on page 80:

-d

---

From: "Francois Audet" <[email-masked]>
Date: Fri, 11 May 2007 11:45:48 -0500

Here you go. Thanks. 

> Sent: Friday, May 11, 2007 09:41
> To: Audet, Francois (SC100:3055); 'Paul Kyzivat'
> Cc: 'Christer Holmberg (JO/LMF)'; [email-masked]; 
> [email-masked]
> > Cc: Dan Wing; Christer Holmberg (JO/LMF); [email-masked]; 
> > [email-masked]
> > I think what we need to do is describe what you are 
> explaining here, 
> > but we need to make sure that we don't introduce backward 
> > compatibility problems.
> > 
> > > Subject: Re: [Sip] Support for Multipart/MIME I would 
> like to bring 
> > > up something that isn't discussed much:
> > > disposition need to be correct. For instance, a body part with 
> > > content type of application/sdp should not be considered 
> an offer or 
> > > answer unless the content-disposition is "session". (This is 
> > > *In principle* you could have a multipart/mixed that had 
> to parts, 
> > > both with content-type of application/sdp. This could be 
> quite legal 
> > > if only one of them had content-disposition of "session" and the 
> > > other had some other content-disposition.

---

From: Cullen Jennings <[email-masked]>
Date: Fri, 11 May 2007 18:47:43 -0700

I want to make it clear that I view  draft-ietf-mmusic-sdp-capability- 
negotiation as a better solution to the selecting RTP / SRTP problem  
that the draft-jennings-sipping-multipart. (draft-jennings-sipping- 
multipart was premised on the idea that the SRTP keys would be  
transported with S/MIME which is not as good a solution as the DTLS  
solutions). More importantly, the RTP/SEC bofs and MMUSIC WG selected  
draft-ietf-mmusic-sdp-capability-negotiation as the way forward the  
problem of saying you can do RTP and SRTP but would prefer SRTP. I  
don't want to be opening that debate or anything about transitions to  
the SDPng.

However, even thought we don't need multipart for the above problems  
- I still think we need it so that we have some extensibility model  
for SIP body parts.

Cullen <with my individual hat on>

PS ... The picking which body to use is not hard - for mutlipart/ 
alternative you use the last one that you understand.

On May 9, 2007, at 12:15 PM, Dan Wing wrote:

> explored

---

From: "Christer Holmberg \(JO/LMF\)" <[email-masked]>
Date: Mon, 14 May 2007 07:41:38 +0200

Hi, 

> Exactly what I had in mind. I was suggesting we replace the 
> SRTP example in the document with this example.

I think the document should also describe SDP, and if someone thinks
alternative doesn't work (or that some other mechanism is far better)
with SDP it should be described.

Also, we now have a number SDP extensions, related to grouping,
alternatives and capabilities, so it would probably somehow be a good
idea to collect a description/comparition of them in some document.

Regards,

Chriser

---

From: Klaus Darilion <[email-masked]>
Date: Mon, 14 May 2007 09:22:33 +0200

Mark R. Lindsey wrote:
> It is much more reasonable to expect the service-provider/enterprise to 
> implement the location conveyance. They'd add the location in their 
> proxies/B2BUAs/ALGs. For example, an enterprise building ALG could add 
> its location before sending the call to an SP.

What if there is no service provider at all? SIP phones may perform 
emergency calls on there own - without the need of a service provider. 
Otherwise - if your service provider is down - you can't make emergency 
calls.

regards
klaus

---

From: Hannes Tschofenig <[email-masked]>
Date: Mon, 14 May 2007 12:33:26 +0200

Hi Klaus,

no matter how you call it but there will always be a (VoIP) application 
service provider involved in the emergency services case.
I guess you refer to the SIM-less emergency services case (or 
unauthenticated emergency network access scenario) where the access 
network provider (ASP and/or ISP) also needs to be the (VoIP) 
application service provider.

Ciao
Hannes

Klaus Darilion wrote:
>
>
> Mark R. Lindsey wrote:
>> It is much more reasonable to expect the service-provider/enterprise 
>> to implement the location conveyance. They'd add the location in 
>> their proxies/B2BUAs/ALGs. For example, an enterprise building ALG 
>> could add its location before sending the call to an SP.
>
> Otherwise - if your service provider is down - you can't make 
> emergency calls.
>
> regards
> klaus
>
>

---

From: [email-masked]
Date: Mon, 14 May 2007 11:46:31 -0400

From: Hannes Tschofenig <[email-masked]>

I don't see that this is guaranteed.  E.g., a VoIP mobile phone could
connect to an open WiFi hub at a coffee shop and route a request
directly to the local PSAP through its public Internet interface.  In
that case, the only SIP-aware elements are the mobile phone and the
PSAP.

But haven't all these issues been discussed and settled in the geoloc
WG?

Dale

---

From: "Francois Audet" <[email-masked]>
Date: Mon, 14 May 2007 12:16:34 -0500

> Sent: Sunday, May 13, 2007 22:42
> To: Audet, Francois (SC100:3055); Dan Wing; Paul Kyzivat
> I think the document should also describe SDP, and if someone 
> thinks alternative doesn't work (or that some other mechanism 
> is far better) with SDP it should be described.

This document should say that multiple SDPs with multipart/alternative
are NOT
allowed.

It should probably refer to RFC 2046 that explains pretty clearly what
Alternative means, i.e., Multiple version of the SAME information
using different MIME bodies. See 5.1.4/RFC 2046.

E.g., SDP vs SDPv2/NG/whatever-comes-up-next
      text/plain, text/html

> Also, we now have a number SDP extensions, related to 
> grouping, alternatives and capabilities, so it would probably 
> somehow be a good idea to collect a description/comparition 
> of them in some document.

Agreed.

That's probably the job of Flemming's capability negotiation draft in
MMUSIC.
I think he's got some wording on it already.

---

From: Gonzalo Camarillo <[email-masked]>
Date: Wed, 16 May 2007 11:04:42 +0300

Hi,

> multipart/alternative is harmful if it contains multiple SDP parts.

yes; alternatives, capabilities, etc., in SDP should be expressed using 
(potentially new) SDP mechanisms (e.g., SDP attributes). I agree that 
multipart/alternative should not be used for two SDP bodies.

Cheers,

Gonzalo

---

From: Gonzalo Camarillo <[email-masked]>
Date: Wed, 16 May 2007 11:13:06 +0300

Hi,

> Section 6 would be OK, but now that SDPng is gone, it's irrelevant.

I have seen a few statements like this on the list lately. SIP intends 
to be, by design, session-description-format agnostic. Therefore, we 
need a mechanism that allows endpoints to try and use different 
session-description formats even if SDPng is dead.

Experimenting with new session-description formats is part of the 
innovation process we want to have in SIP.

In short, I do not think such a mechanism is irrelevant only because 
SDPng did not succeed. We still need such a mechanism.

Cheers,

Gonzalo

---

From: Gonzalo Camarillo <[email-masked]>
Date: Wed, 16 May 2007 11:16:22 +0300

Hi,

yes, Paul and I talked about writing a draft to clarify a few issues 
that relate to content dispositions in SIP a while ago. We were quite 
busy at that point and did not have time to write it, but maybe it is 
time to do it now.

Cheers,

Gonzalo

Paul Kyzivat wrote:
>> about it.   We should really make proper treatment of multipart/mixed 
>> as mandatory
>> as we can.   This means, being able to understand parse the nested 
>> MIME bodies that
>> you DO support.
>> Accept   header in 415.
>> example, text/html and   text/xml or whatever. It would be applicable 
>> if one day we re-created
>> another SDPng   for example.
> 
>> of them is   encrypted inside a application/pkcs7mime), but really 
>> it's still two
>> application/sdp
>>
>> alternatives of   the same payload type, in particular, not for 
>> application/sdp &
>> application/sdp.
>>> From: Dan Wing [mailto:[email-masked]] Sent: Thursday, May 10, 2007 
>>> 09:19

---

From: Paul Kyzivat <[email-masked]>
Date: Wed, 16 May 2007 08:18:18 -0400

Hi Gonzalo,

I guess the question is whether we want to write a document specifically 
focused on Content-Disposition, or if we want to combine work on that 
with work on specifying use of multipart.

They aren't the same thing, but content-disposition becomes more 
significant when there are multiple body parts, so there is some 
justification for combining the work.

	Paul

Gonzalo Camarillo wrote:
>> *In principle* you could have a multipart/mixed that had to parts, 
>> both with content-type of application/sdp. This could be quite legal 
>> if only one of them had content-disposition of "session" and the other 
>> had some other content-disposition. It would be sufficient for the 
>> other to have "Content-Disposition:foo;handling=optional".
>>
>> including an sdp body part that isn't intended to be an offer or 
>> answer. But we are writing the specs here, and we ought to be complete 
>> and precise about it.
>>

---

From: "Francois Audet" <[email-masked]>
Date: Wed, 16 May 2007 10:26:50 -0500

Yes, that's exactly what I was saying.

It's perfectly consistent with the intent of what Multipart/alternative
is supposed
to mean. 

> From: Gonzalo Camarillo [mailto:[email-masked]] 
> Sent: Wednesday, May 16, 2007 01:13
> I have seen a few statements like this on the list lately. 
> SIP intends to be, by design, session-description-format 
> agnostic. Therefore, we need a mechanism that allows 
> endpoints to try and use different session-description 
> formats even if SDPng is dead.
> 
> Experimenting with new session-description formats is part of 
> the innovation process we want to have in SIP.
> 
> In short, I do not think such a mechanism is irrelevant only 
> because SDPng did not succeed. We still need such a mechanism.
> 
> Cheers,
> 
> Gonzalo
> 
>

---

From: "Francois Audet" <[email-masked]>
Date: Wed, 16 May 2007 10:30:08 -0500

My preference is one document. 

> Sent: Wednesday, May 16, 2007 05:18
> To: Gonzalo Camarillo
> Cc: Audet, Francois (SC100:3055); [email-masked]; Dan Wing; 
> Christer Holmberg (JO/LMF)
> I guess the question is whether we want to write a document 
> specifically focused on Content-Disposition, or if we want to 
> combine work on that with work on specifying use of multipart.
> 
> They aren't the same thing, but content-disposition becomes 
> more significant when there are multiple body parts, so there 
> is some justification for combining the work.
> 
> 	Paul
> 
> Gonzalo Camarillo wrote:
> > Hi,
> > 
> >>> I think we are on to something here. I believe that Paul 
> Kyzivat and 
> >>> Dan Wing have it right.
> >>>
> >> answer unless the content-disposition is "session". (This 
> is confused 
> >> because there are are also defaulting rules for 
> content-disposition.)
> >>
> >> other had some other content-disposition. It would be 
> sufficient for 
> >> the other to have "Content-Disposition:foo;handling=optional".
> >>
> >> answer. But we are writing the specs here, and we ought to be 
> >>>   It's not pretty out there. I've seen implementations that don't 
> >>> even send 415
> >>>   it's an SDP-less INVITE. They then put an offer in the 
> response, 
> >>> which the
> >>>   I agree with Dan that using Multipart/alternative in 
> the way that 
> >>> was described
> >>>   are defining capability negotiation. Section 6 would be OK, but 
> >>> now that SDPng is gone,
> >>>   it's irrelevant.
> >>>
> >>>   Section 3.1 explains this relatively well, but is restricted to 
> >>> Offers (for which we have

---

From: Paul Kyzivat <[email-masked]>
Date: Fri, 18 May 2007 10:29:05 -0400

If we need any more motivation for this work, here is a quote from 
draft-ietf-mmusic-file-transfer-mech-02.

    The MMUSIC working group considered a few alternative
    approaches before deciding to use the encoding described in
    Section 6.  In particular, the working group looked at the MIME
    'external-body' type and the use of a single SDP parameter.

    A MIME 'external-body' could potentially be used to describe the file
    to be transfered.  In fact, many of the SDP parameters this
    specification defines are also supported by 'external-body' body
    parts.  The MMUSIC working group decided not to use 'external-body'
    body parts because a number of existing offer/answer implementations
    do not support multipart bodies.

I don't think we can hold that work hostage until there is better 
support for multipart. But that means there is one more thing that has 
been screwed around because of the lack of multipart support.

	Paul

---

From: Gonzalo Camarillo <[email-masked]>
Date: Wed, 23 May 2007 11:23:59 +0300

Hi,

I have taken a stab at writing a quick draft about both issues (I agree 
it makes sense to tackle them in a single document). Until it appears in 
the archives, you can fetch it from:

http://users.piuha.net/gonzalo/temp/draft-camarillo-sip-body-handling-00.txt

I have marked a few open issues so that we can continue discussions 
around those on the list (this is, of course, just an initial draft).

Cheers,

Gonzalo

---

From: Paul Kyzivat <[email-masked]>
Date: Wed, 23 May 2007 10:34:40 -0400

Gonzalo,

Thank you for doing this. It is a great start. I largely agree with what 
you have written.

One specific comment about the draft:

- Open issue in section 3: perhaps a new Reason code, to be used
   with a 415 response would be adequate.

I think there are a number of loose ends, some mentioned, some not. In 
many cases, while I have an opinion what the right answer might be I 
think it needs discussion. Here is what I came up with:

- How to determine what processing a body part should receive

In many cases the processing of a body part is determined by: the 
content disposition, the content type, and perhaps the context within 
which the message is received. For instance, this is true for type sdp 
with disposition session in an INVITE; for type text/plain with 
disposition render in a MESSAGE; and for type kpml with disposition ??? 
in a SUBSCRIBE. In these cases there is no overt *reference* to the body 
part.

In other cases the processing is determined by the context of a 
reference to the body part via a cid: url that references the Content-ID 
of the body part. You mentioned this as well.

The case I am concerned with is when there is ambiguity between these. 
For instance 3261 defines Content-Dispositions "alert" and "icon". While 
these aren't described very well, it appears that if a body part is 
present with disposition "alert" then it should be used for alerting 
based on its presence, without any overt reference. But there is also an 
Alert-Info header, which *could* contain a cid: url. If there was an 
Alert-Info header with a cid: url that referenced a body part, must that 
body part be of disposition "alert"?

Its my feeling that the definition of each disposition should specify 
how use decisions should be made for body parts having this disposition. 
There should be one or more dispositions that state that their use is to 
be determined by how they are referenced. And headers that might 
reference body parts should define the acceptable dispositions for the 
body parts that are referenced.

If a message contains a body part with type and disposition that defines 
how it is processed without need of a reference, and there *also* is a 
reference to it, then it should be processed both ways. (This however 
should happen rarely or never.)

- What Content-Disposition type should multipart bodies have?

When you have a multipart body, it has a disposition, and each of its 
contained body parts also has a disposition. I have never seen any 
specification of what disposition the multipart itself should have. None 
of the examples I have seen have had a Content-Disposition header in the 
multipart. According to the sip defaulting rules, a multipart body 
without a C-D header has disposition "render", which seems a bit weird.

In the case of multipart/alternative, I think the disposition type of 
all the contained body parts should be identical. I think it would also 
make sense for the multipart/alternative itself to contain the same 
disposition. That would simplify processing, because the whole thing 
could be ignored if the disposition has a type that will be ignored.

In the case of multipart/mixed, the disposition types of the contained 
body parts will typically vary. The type of the mixed body simply needs 
to be something that causes it to be processed. Using the default of 
"render" seems weird to me. It would make sense to me to have some 
special C-D type for this purpose. Potentially it could be defined as 
the default C-D for multipart/mixed in the same way that "session" is 
the default for type application/sdp.

- Must the recipient of a message process all multipart bodies and their 
contents? Recursively?

Note that a multipart body can contain other multipart body parts, thus 
potentially forming a tree of body parts of arbitrary shape and depth.

So, the developer of a UA will want to know: do I have to parse all of that?

I think the answer is: like anything else, you make this decision based 
on the disposition type and handling. (If you understand multipart/mixed 
(and you should) then you also understand that multipart/X where you 
don't know X should be processed the same as multipart/mixed.)

If handling is optional and the disposition type and content type are 
known to you, then you must parse it. Each contained body part is then 
processed based on its own disposition. If the handling is optional and 
the disposition type or content type are not known to you then you can 
ignore it.

(This puts a premium on having an agreed to disposition type that is 
typically used for multipart/mixed and which everyone that supports 
multipart is expected to support.)

- What "handling" value should be used for multipart bodies and the 
contained body parts?

If a body part is referenced by a cid: url in a header (or in another 
body part I suppose), then the handling of the body part should be required.

Contained, non-multipart body parts that aren't referenced by cid: can 
have handling required or optional as appropriate for their use.

A multipart body should have handling of required if any of the parts it 
contains are required. Otherwise it may have optional handling.

Multipart/alternative is tricky. Only one alternative is to be used, and 
it is assumed that some alternatives may not be understood. So it seems 
that all except the first contained body part should have optional 
handling. The first may be required or optional depending on whether its 
ok to handle none. And the handling of the multipart/alternative 
container is as above.

- What about "gratuitous" nesting of multiparts?

It seems that it is technically valid to wrap a body part, such as an 
SDP offer, in one or many levels of multipart wrappers. A recipient who 
receives such a thing, and processes it according to what Gonzalo has 
specified and what I have suggested above, should be able to deal with this.

But its not a good thing.

So I think we ought to at least state that the sender of a request 
SHOULD NOT use a multipart wrapper when there is only one part, and 
SHOULD NOT nest one multipart/mixed within another unless there is a 
*reference* to the nested one. (Instead of nesting, include all the 
parts in the outer multipart.) And a sender SHOULD NOT nest one 
multipart/alternative within another.

	Thanks,
	Paul

Gonzalo Camarillo wrote:
>>> From: Paul Kyzivat [mailto:[email-masked]] Sent: Wednesday, May 
>>> 16, 2007 05:18
>>> To: Gonzalo Camarillo
>>> Cc: Audet, Francois (SC100:3055); [email-masked]; Dan Wing; Christer 
>>> Holmberg (JO/LMF)
>>> specifically focused on Content-Disposition, or if we want to combine 
>>> work on that with work on specifying use of multipart.
>>>

---

From: Paul Kyzivat <[email-masked]>
Date: Wed, 23 May 2007 11:28:36 -0400

Revising one point:

> body part I suppose), then the handling of the body part should be 

On reflection, this is tricky.

If the header containing the reference is optional (as most are), then 
recipients that don't understand the header will have no need for the 
referenced part. If it were required and they don't support the type, 
then they would fail the request. This is bad.

So if processing of the header is optional, then the referenced body 
part should have optional handling.

But then there could be a problem if the recipient does understand and 
process the header, but doesn't understand the body part, and so because 
it is optional doesn't process it. In that case, the cid reference will 
be unsatisfied. This could also result in an inappropriate error.

I think the solution here is that if a header contains a cid url, and if 
that url cannot be resolved to a body part that is supported, then the 
UA should treat it the same as if the header itself was not understood - 
typically ignoring it unless there is a Require in effect that demands 
failing the request.

An alternative is to require that Content-ID be remembered even for 
parts that are not understood, so that references can be resolved even 
if they can't be processed. This would allow more precise errors to be 
generated. This wouldn't be so hard at an outer level, but it might be 
troublesome in conjunction with nesting.

	Paul

---

From: "Francois Audet" <[email-masked]>
Date: Wed, 23 May 2007 13:17:41 -0500

This is great Gonzallo. Thanks for doing this.

Here are some comments:

- In section 4, another example that I think you should list for 
  Multipart/Mixed is RFC 3204 which actually has examples of 
  INVITEs with Multipart/Mixed (one for SDP, the other for 
  QSIG/ISUP tunnelling). That spec also illustrates the content-
  disposition mechanism (i.e., "optional" for QSIG/ISUP).

- I like your text on Multipart/Alternative. I'd like to include the 
  following snippet of text from draft-jennings-sipping-multipart-02.txt
  in there:

   It is critical that multipart/alternative offers follow the semantics
   of multipart/alternative, notably the following text from RFC2046
   [2]:

       "THE SEMANTICS OF CONTENT-ID IN MULTIPART/ALTERNATIVE:  Each
        part of a "multipart/alternative" entity represents the same
        data, but the mappings between the two are not necessarily
        without information loss.  For example, information is lost
        when translating ODA to PostScript or plain text.  It is
        recommended that each part should have a different Content-ID
        value in the case where the information content of the two
        parts is not identical."

  I'd also like to see an example of Multipart/Alternative for the
  MESSAGE message (with text/plain and text/html for example).

- I believe that the following text in section 4 is not strong enough:

   If a UAS does not support multipart bodies and receives one, the UAS
   SHOULD return a 415 (Unsupported Media Type) response.

  Instead, it should read as follows:

   If a UAS does not support multipart bodies and receives one, the UAS
   MUST return a 415 (Unsupported Media Type) response, and it MUST 
   return a list of acceptable formats as specificed in
[RFC3261]/21.4.13.

  I believe this is in line with RFC 3261/8.2.3. I will point out that 
  we have found in the field that if a UAS does NOT send a 415 and just
  "ignores" the Multipart body altogether, what happens is that the
receiver of the
  INVITE interprets the INVITE as having NO initial Offer, and sends an
an
  Offer of it's own in the 200/18X. This is interpreted by the sender of
the
  INVITE as an Answer, resulting in all hell breaking loose.

> Sent: Wednesday, May 23, 2007 01:24
> Cc: Paul Kyzivat; [email-masked]; Dan Wing; Christer Holmberg (JO/LMF)
> I have taken a stab at writing a quick draft about both 
> issues (I agree it makes sense to tackle them in a single 
> document). Until it appears in the archives, you can fetch it from:
> 
> I have marked a few open issues so that we can continue 
> discussions around those on the list (this is, of course, 
> just an initial draft).
> 
> Cheers,
> 
> Gonzalo
> 
> 
> Francois Audet wrote:

---

From: Paul Kyzivat <[email-masked]>
Date: Wed, 23 May 2007 14:39:15 -0400

Francois Audet wrote:

>   receiver of the INVITE interprets the INVITE as having NO initial
>   Offer, and sends an an Offer of it's own in the 200/18X. This is
>   interpreted by the sender of the INVITE as an Answer, resulting in
>   all hell breaking loose.

This is great! I love it.

	Paul

---

From: "Dan Wing" <[email-masked]>
Date: Wed, 23 May 2007 11:52:51 -0700

> Sent: Wednesday, May 23, 2007 11:18 AM
> To: Gonzalo Camarillo

I wasn't aware of that usage in RFC3204.  In both section 4.1 and its
example, though, I don't think it's using multipart/mixed correctly.  Here
is its example (section 4.1 is similar):

   To illustrate the use of the 'application/QSIG' media type, below is
   an INVITE message which has the originating SDP information and an
   encapsulated QSIG SETUP message.

   Note that the two payloads are demarcated by the boundary parameter
   (specified in RFC 2046 [4]) which in the example has the value
   "unique- boundary-1". This is part of the specification of MIME
   multipart and is not related to the 'application/QSIG' media type.

         INVITE sip:[email-masked] SIP/2.0
         Via: SIP/2.0/UDP sc10.nortelnetworks.com
         From: sip:[email-masked]
         To: sip:[email-masked]
         Call-ID: [email-masked]
         CSeq: 1234 INVITE
         Contact: <sip:[email-masked]>
         Content-Length: 358
         Content-Type: multipart/mixed; boundary=unique-boundary-1
         MIME-Version: 1.0

         --unique-boundary-1
         Content-Type: application/SDP; charset=ISO-10646

         v=0
         o=audet 2890844526 2890842807 5 IN IP4 134.177.64.4
         s=SDP seminar
         c=IN IP4 MG141.nortelnetworks.com
         t= 2873397496 2873404696
         m=audio 9092 RTP/AVP 0 3 4

         --unique-boundary-1
         Content-type:application/QSIG; version=iso

         08 02 55 55 05 04 02 90 90 18 03 a1 83 01
         70 0a 89 31 34 30 38 34 39 35 35 30 37 32
         --unique-boundary-1--

Per the semantics of multipart/mixed, both of those bodies are interpreted
by the recipient -- wouldn't that cause two calls to be set up?  Or does the
SDP describe the VoIP leg and the QSIG describes the PSTN leg?  If the
latter, I do feel multipart/related would have been a better choice.  

[[As MIME parsers are supposed to interpret unrecognized multipart/* as
multipart/mixed, a MIME-compliant parser that currently has the
RFC3204-described behavior <quote>should</quote> work correctly if it
received a multipart/related instead of multipart/mixed.]]

> - I like your text on Multipart/Alternative.

Yes, that section is very well written and captures exactly the problem with
multipart/alternative.

...
>   INVITE as an Answer, resulting in all hell breaking loose.

That's awful.  You could detect this situation by requiring the answerer to
insert a reference to the Content-ID they're answering; if an ACK comes back
without that Content-ID, you'll know you encountered such a defective
implementation.

-d

---

From: "Francois Audet" <[email-masked]>
Date: Wed, 23 May 2007 14:22:19 -0500

Hi Dan, 

To answer your question about the Multipart usage for ISUP/QSIG
tunnelling.

No, it does not set-up two calls. It sets-up ONE call.

The SDP is mandatory.

The QSIG or ISUP is optional. If supported it provides additional
information for the softswitches for legacy PSTN interop or other
features.
If not it should be safely ignored.

So 3204 operates exactly as it should. Works fine. Has been working fine
for years (except for implementations that have problems with Multipart
MIME,
which has forced the use of B2BUA that strip off these MIME bodies.)

> I wasn't aware of that usage in RFC3204.  In both section 4.1 
> and its example, though, I don't think it's using 
> multipart/mixed correctly.  Here is its example (section 4.1 
> is similar):
> 
> Per the semantics of multipart/mixed, both of those bodies 
> are interpreted by the recipient -- wouldn't that cause two 
> calls to be set up?  Or does the SDP describe the VoIP leg 
> and the QSIG describes the PSTN leg?  If the latter, I do 
> feel multipart/related would have been a better choice.  
> 
> [[As MIME parsers are supposed to interpret unrecognized 
> multipart/* as multipart/mixed, a MIME-compliant parser that 
> currently has the RFC3204-described behavior 
> <quote>should</quote> work correctly if it received a 
> multipart/related instead of multipart/mixed.]]
> 
> Yes, that section is very well written and captures exactly 
> the problem with multipart/alternative.
> 
> ...
> >   INVITE interprets the INVITE as having NO initial Offer, 
> and sends 
> > an an
> >   Offer of it's own in the 200/18X. This is interpreted by 
> the sender 
> > of the
> That's awful.  You could detect this situation by requiring 
> the answerer to insert a reference to the Content-ID they're 
> answering; if an ACK comes back without that Content-ID, 
> you'll know you encountered such a defective implementation.
> 
> -d
> 
> 
>  
> > > I have taken a stab at writing a quick draft about both issues (I 
> > > agree it makes sense to tackle them in a single 
> document). Until it 
> > > appears in the archives, you can fetch it from:
> > > 
> discussions

---

From: "Francois Audet" <[email-masked]>
Date: Wed, 23 May 2007 15:13:56 -0500

> Sent: Wednesday, May 23, 2007 12:53
> To: Audet, Francois (SC100:3055); 'Gonzalo Camarillo'
> Cc: 'Paul Kyzivat'; [email-masked]; 'Christer Holmberg (JO/LMF)'
> Yes, I expect RFC3204's syntax and semantics work fine 
> between two implementations that implement RFC3204.
> 
> My question if it the choice of multipart/mixed in RFC3204 
> was correct or if multipart/related would have been more 
> appropriate for RFC3204.  I have this question because the 
> QSIG (and ISUP) are directly related to the SDP, and the 
> QSIG/ISUP data provides additional information about that 
> outgoing PSTN call leg that assists it in being set up.
> 
> My underlying question is what guidance we want to provide 
> for Gonzalo's document.  If RFC3204's use of multipart/mixed 
> is what we want to do in SIP when there are bodyparts that 
> have a relationship with each other, then Gonzalo's document 
> will need to discourage use of multipart/related.

For Multipart/Related (as described in RFC 2387), I
don't think it's applicable to 3204 as I think they would be 
independent. My reading of 2387 is that they depend on each
other.

This is not the case for 3204. They are not dependent.

(And really, it's way too late to change 3204).

But, if I interpret your question in a broader sense, I guess,
the question is "Do we need to say anything about
multipart/related?". I would extend it to parallel and digest...
I guess we should. But I'm not sure what should be said. 
If we don't have a use case for them, I'd rather we don't encourage
people to use it and create interop problems...

---

From: "Dan Wing" <[email-masked]>
Date: Wed, 23 May 2007 12:52:31 -0700

Yes, I expect RFC3204's syntax and semantics work fine between two
implementations that implement RFC3204.

My question if it the choice of multipart/mixed in RFC3204 was correct or if
multipart/related would have been more appropriate for RFC3204.  I have this
question because the QSIG (and ISUP) are directly related to the SDP, and
the QSIG/ISUP data provides additional information about that outgoing PSTN
call leg that assists it in being set up.

My underlying question is what guidance we want to provide for Gonzalo's
document.  If RFC3204's use of multipart/mixed is what we want to do in SIP
when there are bodyparts that have a relationship with each other, then
Gonzalo's document will need to discourage use of multipart/related.

-d 

> Sent: Wednesday, May 23, 2007 12:22 PM
> To: Dan Wing; Gonzalo Camarillo
> Cc: Paul Kyzivat; [email-masked]; Christer Holmberg (JO/LMF)
> > >    If a UAS does not support multipart bodies and 
> receives one, the 
> > > UAS
> > >    If a UAS does not support multipart bodies and 
> receives one, the 
> > > UAS
> issues (I

---

From: "Dan Wing" <[email-masked]>
Date: Wed, 23 May 2007 13:24:42 -0700

> This is not the case for 3204. They are not dependent.

In RFC3204, the QSIG or ISUP parts do not appear to have any meaning without
the SDP.  Or do they?  For example, is it meaningful for me to send an
INVITE that has only the QSIG part (and no SDP)?

> (And really, it's way too late to change 3204).

Even if consensus were to be formed that there was a mistake?  Obviously no
such consensus has been formed, but I would like to have the discussion.

If we do consider it acceptable to change RFC3261's requirements around MIME
multipart support, I suggest it is reasonable to analyze what we may have
done wrong elsewhere around MIME with SIP.

> multipart/related?". I would extend it to parallel and digest...

And external-body, and all the other parts.  Yes, that is my underlying
question in light of Gonzalo's document and Cullen's stated desire for the
SIP community to document multipart support.

-d

---

From: "Francois Audet" <[email-masked]>
Date: Wed, 23 May 2007 15:36:50 -0500

> In RFC3204, the QSIG or ISUP parts do not appear to have any 
> meaning without the SDP.  Or do they?  For example, is it 
> meaningful for me to send an INVITE that has only the QSIG 
> part (and no SDP)?

Sure: it's just a delayed offer answer. 

> Even if consensus were to be formed that there was a mistake? 
>  Obviously no such consensus has been formed, but I would 
> like to have the discussion.

I really don't think it's a mistake.

> If we do consider it acceptable to change RFC3261's 
> requirements around MIME multipart support, I suggest it is 
> reasonable to analyze what we may have done wrong elsewhere 
> around MIME with SIP.
> 
> > But, if I interpret your question in a broader sense, I guess, the 
> > question is "Do we need to say anything about 
> multipart/related?". I 
> > would extend it to parallel and digest...
> 
> And external-body, and all the other parts.  Yes, that is my 
> underlying question in light of Gonzalo's document and 
> Cullen's stated desire for the SIP community to document 
> multipart support.

Yeah, I think it would be worthwile to talk about it, but not in the
context
of 3204.

Frankly, what I think we should say is "RECOMMEND don't use unless some
IETF RFC defines a use for them".

---

From: "Elwell, John" <[email-masked]>
Date: Thu, 24 May 2007 09:57:01 +0100

> Sent: 23 May 2007 21:37
> Cc: [email-masked]; Paul Kyzivat; Christer Holmberg (JO/LMF)
[JRE]Moreover, QSIG or ISUP parts can be sent in other messages without
SDP, e.g., in an INFO request.

John

---

From: Gonzalo Camarillo <[email-masked]>
Date: Sun, 27 May 2007 22:20:26 +0300

Hi Paul,

thanks for your comments. Answers inline:

>   with a 415 response would be adequate.

what do you mean by a reason code? Do you mean a Warning code?... 
because Reason header fields are not allowed in responses.

> should happen rarely or never.)

I have added more structure to the draft (i.e., a few new sections) that 
I believe make it easier to read. You can fetch a working version from:

http://users.piuha.net/gonzalo/temp/draft-camarillo-sip-body-handling-01.txt

The points above are covered in Sections 4.2, 4.3, and 5. I have added a 
few guidelines to authors of future extensions so that folks writing 
specs are also aware of all these issues and take them into 
consideration when writing new extensions.

> could be ignored if the disposition has a type that will be ignored.

That's now covered in Section 4.1

> the default for type application/sdp.

That's OPEN ISSUE 3 now. We may indeed need to define a new disposition 
type.

> multipart is expected to support.)

I think that is now clear in the new version... but let me know if you 
do not think so.

> ok to handle none. And the handling of the multipart/alternative 

That's now covered in Section 4.1

> multipart/alternative within another.

That's now covered in Section 3.2

I have numbered the OPEN ISSUES. Now the draft contain 4 of them. I 
would like to discuss how to close them.

Thanks,

Gonzalo

---

From: Gonzalo Camarillo <[email-masked]>
Date: Sun, 27 May 2007 22:22:59 +0300

Hi Paul,

I have added a few guidelines about this in Section 5 of the new version 
of the draft:

With those guidelines and the behavior defined in other sections, we 
should be OK. Let me know if you agree or want to add further 
clarifications or behavior.

Thanks,

Gonzalo

---

From: Gonzalo Camarillo <[email-masked]>
Date: Sun, 27 May 2007 22:29:18 +0300

Hi Francois,

thanks for the comments. Answers inline:

[by the way, Gonzalo has one 'l'; it is Camarillo the one with two 'l's 
;o) ]

>   disposition mechanism (i.e., "optional" for QSIG/ISUP).

I have added another reference to it in Section 3 as an additional 
example. You can fetch the new working version of the draft from:

>   MESSAGE message (with text/plain and text/html for example).

I have not copy/pasted the text above, but I have included all of it 
rephrasing it.

>    return a list of acceptable formats as specificed in

When it comes to response generation, I always use SHOULD because a 
request may cause other error, apart from the ones we are defining here, 
and the UAS may need to return a different status code. That's why I do 
not use MUST in this case.

In any event, I have added more text stressing the importance of this.

>   INVITE as an Answer, resulting in all hell breaking loose.

Yes, this is really bad. I have added text stressing the importance of 
being able to produce error responses (Section 3.3).

Thanks,

Gonzalo

---

From: Paul Kyzivat <[email-masked]>
Date: Mon, 28 May 2007 01:05:23 -0400

Gonzalo - comments inline. This is looking good.

	Paul

Gonzalo Camarillo wrote:
>> Thank you for doing this. It is a great start. I largely agree with 
>> what you have written.
>>

Never mind. I just wasn't thinking.

> http://users.piuha.net/gonzalo/temp/draft-camarillo-sip-body-handling-01.txt 

I believe you have covered my concerns.

I've been thinking if there are other similar issues regarding 
references to body parts. I think another is that it can be possible for 
a reference to be present in a body part. (For example if one body part 
is an application/sipfrag.) Potentially the reference could then be in 
an optional part that is not understood by the recipient. Again, we 
wouldn't want processing to depend on whether a reference was processed 
or not.

I'm not convinced there are any cases where this can be a real issue. It 
wouldn't be if the referenced body part were "within" the body part 
containing the reference. I think the sipfrag case would always fall 
into this category. I don't have any other examples in mind, so maybe 
this isn't really an issue. I'd just rather find any now rather than 
later. Can anybody else think of anything in this category? (Or do I 
have a monopoly on that job?)

Re Issues:

>    OPEN ISSUE 1: do we need to say something about other types?  Related
>    (rfc2387), parallel, digest, external-body.

I don't know much about these. I quickly scanned 2387 and see that it 
has some special rules re processing Content-Disposition of the 
contained (related) parts. I *think* those are consistent with what we 
are doing.

>    OPEN ISSUE 2: we know that we do not want two SDPs in a 'multipart/
>    alternative', but is this valid generally with any content type?
>    Would it be possible to provide two alternative body parts using the
>    same format and, thus, the same content type but in, say, different
>    languages?

Its my understanding that the distinction is based on which can be 
understood, relative to Content-Type. It isn't apparent to me that 
making this decision based on other attributes is valid. For one thing 
the parts are supposed to be ordered by increasing richness. If they 
differed by language this wouldn't be true.

So I think what you have is ok.

>    OPEN ISSUE 3: do we need to talk about encrypted body parts?

???

>    OPEN ISSUE 4: the handling parameter is a Content-Disposition
>    parameter.  Therefore, in order to set the handling parameter, it is
>    necessary to provide the 'multipart' body with a disposition type.
>    Otherwise, its disposition type would be, by default, render.  Which
>    disposition type shall we use for 'multipart/mixed' bodies?  Shall we
>    create a new disposition type for this purpose?

I think we need a new disposition type. I also think we should specify 
that this new one is the default for bodies of multipart/* content-type. 
That should fix up most examples and prior use, which afaict have not 
specified a content-disposition.

>    OPEN ISSUE 5: we could define a new response code (Content or
>    Disposition Type not Supported in this Context) to report known
>    content and disposition types appearing in an unsupported context in
>    order to be more explicit than always using 415.  It would avoid
>    receiving a 415 response with an Accept header field containing all
>    the content types used in the request.  How useful would this really
>    be?

I'm inclined to say yes for completeness. But I don't expect to see any 
implementations using this the change their behavior at runtime.

Another thing in Section 3: You have used SHOULD in this section. I 
thought we wanted to change this to MUST. Did we?

There are also a couple of typos in Section 3:

s/extensions relay on them/extensions rely on them/

s/miltipart/multipart/

	That's it for now,
	Paul

---

From: "Christer Holmberg (JO/LMF)" <[email-masked]>
Date: Mon, 28 May 2007 09:58:07 +0200

Hi,

One question is when "parallel" should be used instead of "mixed".

When mixed is used, the order of the bodies is significant, which is not
the case for parallel. And, for ISUP or QSIG, is there a difference in
which order the ISUP/QSIG and SDP bodies are presented?

I know that support of ISUP/QSIG bodies are implemented using mixed, and
I am not proposing to change that. But, I think the draft should maybe
talk a little more about the differences between parallel and mixed.

In most cases I guess it doesn't matter which one would use. At least I
can't think of any SIP use-case where the order of the bodies would be
significant.

Regards,

Christer

> Sent: 23. toukokuuta 2007 22:53
> To: 'Francois Audet'; Gonzalo Camarillo (JO/LMF)
> Cc: 'Paul Kyzivat'; [email-masked]; Christer Holmberg (JO/LMF)
> > So 3204 operates exactly as it should. Works fine. Has been working 
> > fine for years (except for implementations that have problems with 
> > Multipart MIME, which has forced the use of B2BUA that 
> strip off these 
> > MIME bodies.)
> > 
> > > I wasn't aware of that usage in RFC3204.  In both section 4.1 and 
> > > its example, though, I don't think it's using multipart/mixed 
> > > correctly.  Here is its example (section 4.1 is similar):
> > > 
> > >    To illustrate the use of the 'application/QSIG' media 
> type, below 
> > > is
> > > Per the semantics of multipart/mixed, both of those bodies are 
> > > interpreted by the recipient -- wouldn't that cause two 
> calls to be 
> > > set up?  Or does the SDP describe the VoIP leg and the QSIG 
> > > describes the PSTN leg?  If the latter, I do feel 
> multipart/related 
> > > would have been a better choice.
> > > 
> <quote>should</quote> 
> > > work correctly if it received a multipart/related instead of 
> > > multipart/mixed.]]
> > > 
> > > Yes, that section is very well written and captures exactly the 
> > > problem with multipart/alternative.
> > > 
> > > ...
> > > That's awful.  You could detect this situation by requiring the 
> > > answerer to insert a reference to the Content-ID they're 
> answering; 
> > > if an ACK comes back without that Content-ID, you'll know you 
> > > encountered such a defective implementation.
> > > 
> > > -d
> > > 
> > > 
> > >

---

From: "Christer Holmberg (JO/LMF)" <[email-masked]>
Date: Mon, 28 May 2007 10:01:55 +0200

Hi,

I agree with Francois.

You can send the QSIG/ISUP without SDP, and as far as the information
itself is concerned, I don't think the QSIG/ISUP and SDP is related.

So, I don't think mixed is a misstake. One question (as I wrote in
anther mail) is whether parallel would also be feasible.

Regards,

Christer 

> Sent: 23. toukokuuta 2007 23:37
> To: Dan Wing; Gonzalo Camarillo (JO/LMF)
> > In RFC3204, the QSIG or ISUP parts do not appear to have 
> any meaning 
> > without the SDP.  Or do they?  For example, is it 
> meaningful for me to 
> > send an INVITE that has only the QSIG part (and no SDP)?
> 
> > If we do consider it acceptable to change RFC3261's requirements 
> > around MIME multipart support, I suggest it is reasonable 
> to analyze 
> > what we may have done wrong elsewhere around MIME with SIP.
> > 
> Cullen's stated 
> > desire for the SIP community to document multipart support.
> 
> Yeah, I think it would be worthwile to talk about it, but not 
> in the context of 3204.
> 
> Frankly, what I think we should say is "RECOMMEND don't use 
> unless some IETF RFC defines a use for them".
>

---

From: "Francois Audet" <[email-masked]>
Date: Mon, 28 May 2007 16:17:33 -0500

Personally, I think we should treat parallel just like mixed when
received.
And continue to use mixed for sending, at least for things that exist
already (like QSIG/ISUP).

I would be surprised if parallel was really used in the wild...

But I do agree we could say something about it. 

> Sent: Monday, May 28, 2007 00:58
> To: Dan Wing; Audet, Francois (SC100:3055); Gonzalo Camarillo (JO/LMF)
> Cc: Paul Kyzivat; [email-masked]
> Subject: RE: [Sip] Support for Multipart/MIME - order of bodies
> 
> 
> Hi,
> 
> When mixed is used, the order of the bodies is significant, 
> which is not the case for parallel. And, for ISUP or QSIG, is 
> there a difference in which order the ISUP/QSIG and SDP 
> bodies are presented?
> 
> I know that support of ISUP/QSIG bodies are implemented using 
> mixed, and I am not proposing to change that. But, I think 
> the draft should maybe talk a little more about the 
> differences between parallel and mixed.
> 
> In most cases I guess it doesn't matter which one would use. 
> At least I can't think of any SIP use-case where the order of 
> the bodies would be significant.
> 
> Regards,
> 
> Christer
> 
>  
> 
> was correct 
> > or if multipart/related would have been more appropriate 
> for RFC3204.  
> > I have this question because the QSIG (and ISUP) are 
> directly related 
> > to the SDP, and the QSIG/ISUP data provides additional information 
> > about that outgoing PSTN call leg that assists it in being set up.
> > 
> > My underlying question is what guidance we want to provide for 
> > Gonzalo's document.  If RFC3204's use of multipart/mixed is what we 
> > want to do in SIP when there are bodyparts that have a relationship 
> > with each other, then Gonzalo's document will need to 
> discourage use 
> > of multipart/related.
> > 
> > -d
> > 
> > > > > > around those on the list (this is, of course, just 
> an initial 
> > > > > > draft).
> > > > > > 
> > > > > > Cheers,
> > > > > > 
> > > > > > Gonzalo
> > > > > > 
> > > > > > 
> > > > > > Francois Audet wrote:
> > > > > > >> specifically focused on Content-Disposition, or 
> if we want
> > > > > > to combine
> > > > > > >>> yes, Paul and I talked about writing a draft to 
> clarify a
> > > > > > >> few issues
> > > > > > >>> that relate to content dispositions in SIP a 
> while ago. We
> > > > > > >> were quite
> > > > > > >>> busy at that point and did not have time to 
> write it, but
> > > > > > >> maybe it is
> > > > > > >>> time to do it now.
> > > > > > >>>
> > > > > > >>> Cheers,
> > > > > > >>>
> > > > > > >>> Gonzalo
> > > > > > 
> > > > > > 
> > > > 
> > 
>

---

From: "Christer Holmberg (JO/LMF)" <[email-masked]>
Date: Tue, 29 May 2007 09:09:59 +0200

>Personally, I think we should treat parallel just like mixed 
>when received.

I agree. 

And, maybe forbid the usage of parallel with SIP, unless we really can
come up with a valid use-case where it is needed.

Regards,

Christer

>And continue to use mixed for sending, at least for things 
>that exist already (like QSIG/ISUP).
> 
> which is 
> > not the case for parallel. And, for ISUP or QSIG, is there a 
> > difference in which order the ISUP/QSIG and SDP bodies are 
> presented?
> > 
> > I know that support of ISUP/QSIG bodies are implemented 
> using mixed, 
> > and I am not proposing to change that. But, I think the 
> draft should 
> > maybe talk a little more about the differences between parallel and 
> > mixed.
> > 
> > At least I can't think of any SIP use-case where the order of the 
> > bodies would be significant.
> > 
> > Regards,
> > 
> > Christer
> > 
> >  
> > 
> > > > >          Call-ID: 
> [email-masked]
> > > > >          CSeq: 1234 INVITE

---

From: Gonzalo Camarillo <[email-masked]>
Date: Tue, 29 May 2007 11:33:23 +0300

Hi Paul,

I have addressed your comments and include them in revision 01 before 
submitting it to the IETF. I will now go ahead submit it so that it 
appears in the official repository. Until then, you can fetch it from 
the same link as before (reload the page if you downloaded it before):

> have a monopoly on that job?)

I wrote the text thinking of that possibility, but now I have rephrased 
it so that it is even more explicit about the fact that references can 
be found in body parts.

I have added the following text pointing to an example of such a case:

   "In another example, the extension for file transfer in SDP
    [I-D.ietf-mmusic-file-transfer-mech] places a Content-ID URL in a
    'file-icon' SDP attribute.  This Content-ID URL points to a body part
    whose disposition type is supposed to be 'icon'."

I have also added the following new open issue about the need to parse 
all body parts before being able to process any of them:

"4.2.  Body Processing

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

> contained (related) parts. I *think* those are consistent with what we 

I have added the following text to Section 5:

    "This specification recommends support for 'multipart/mixed' and
    'multipart/alternative'.  At present, there are no SIP extensions
    that use different 'multipart' subtypes such as parallel [RFC2046],
    digest [RFC2046], or related [RFC2387].  If such extensions were to
    be defined in the future, their authors would need to make sure
    (e.g., by using an option-tag or by other means) that entities
    receiving those 'multipart' subtypes were able to process them.  As
    stated earlier, UAs treat unknown 'multipart' subtypes as 'multipart/
    mixed'."

> So I think what you have is ok.

I double check with an email expert to make sure we get this right.

>>    OPEN ISSUE 3: do we need to talk about encrypted body parts?

Christer brought this one up. What did you have in mind?

> specified a content-disposition.

This is probably something email people did not face. I think it makes 
sense to define the new disposition type.

> implementations using this the change their behavior at runtime.

yes, I am leaning towards defining it as well.

> thought we wanted to change this to MUST. Did we?

You refer to the following statement, right?

   "In particular, UAs SHOULD support the 'multipart/mixed'
    and 'multipart/alternative' MIME types."

If people agree that this should be a MUST, I will be happy to change it.

> s/extensions relay on them/extensions rely on them/

Fixed.

> s/miltipart/multipart/

Fixed.

Thanks,

Gonzalo

---

From: Paul Kyzivat <[email-masked]>
Date: Tue, 29 May 2007 08:14:54 -0400

Gonzalo,

This all sounds good. I haven't read the new version yet, but based on 
your description below I have no problems with this, except possibly one 
area in which I am uncertain and which I would like to discuss:

>    them.  If we are OK with this, we need to include text here

I think there is at least ambiguity about what it means to "process" a 
body part. If one body part has a reference to another body part, then 
some amount of processing is required to detect such a reference.

There seems to be an implication that two-pass (or more) processing, 
such as is typically done in compilers, is expected. But given the 
variety of body types I think it will be difficult to define what may be 
processed in a first pass and what must be postponed to a second pass. 
Also, often people will want to use off-the-shelf packages to support 
certain body types, and those may not be so cooperative with this 
requirement.

Also, whether we like it or not, there will be systems that are only 
interested in a subset of what is there. (For instance proxies that are 
interested in SDP for purpose of enabling access.) These will want to 
parse the minimum necessary to find what they are interested in. It 
would be best if we can figure out a way for this to work.

Maybe it is that a UA needs to parse everything that is supported, but 
other nodes it passes through can be more selective.

> Christer brought this one up. What did you have in mind?

Nothing. I just don't know.

	Thanks,
	Paul

---

From: "Christer Holmberg (JO/LMF)" <[email-masked]>
Date: Tue, 29 May 2007 14:25:59 +0200

Hi,

>Christer brought this one up. What did you have in mind?

I think it's worth adding a few words describing the behavior when
receiving en encrypted body part which the receiver is not able to
de-encrypt.

I guess the behavior would be the same as when receiving an unsupported
content type, so it would mostly be a clarification.

Regards,

Christer

---

From: "Christer Holmberg (JO/LMF)" <[email-masked]>
Date: Tue, 29 May 2007 14:35:19 +0200

Hi,

>>contained (related) parts. I *think* those are consistent 
>>with what we are doing.
> 
>    that use different 'multipart' subtypes such as parallel 
>    [RFC2046], digest [RFC2046], or related [RFC2387].  If such 
>    extensions were to be defined in the future, their authors would
need to make sure
>    stated earlier, UAs treat unknown 'multipart' subtypes as 
>    'multipart/mixed'."

I think the text is good.

But, I wonder whether we should alternative to the list of "different
multipart subtypes". At present there are no SIP extensions using
alternative either, so...
 
Or, at least we could leave support of alternative open for the moment,
until we get more information about how it's supposed to be used in the
first place (regarding identical content type values etc).

>>>Would it be possible to provide two alternative body 
>>>parts using the same format and, thus, the same content type but in, 
>>>say, different languages?
>> 
>>making this decision based on other attributes is valid. 
>>For one thing the parts are supposed to be ordered by increasing 
>>richness. If they differed by language this wouldn't be true.
>> 

>If people agree that this should be a MUST, I will be happy 

Again, I think we should wait a little regarding alternative.

Regards,

Christer

---

From: Gonzalo Camarillo <[email-masked]>
Date: Tue, 29 May 2007 15:43:27 +0300

Hi Christer,

we should be ready for a transition to a new session description 
protocol, which includes experimental networks using their own stuff, 
and people seem to agree that alternative is the way to go. That is why 
it would be great if we could mandate its support already now.

The more we wait, the more trouble we could have in the future to use it.

Cheers,

Gonzalo

---

From: "Christer Holmberg (JO/LMF)" <[email-masked]>
Date: Tue, 29 May 2007 15:42:31 +0200

Hi, 

>we should be ready for a transition to a new session 
>description protocol, which includes experimental networks 
>using their own stuff, and people seem to agree that 
>alternative is the way to go. That is why it would be great 
>if we could mandate its support already now.
> 

Yes.

But, at the same time we need to try to be backward compatible, and take
into consideration existing implementations which may support mixed but
not alternative. If those implementations reject alternative I think our
spec should not make them "not compliant". The same thing goes for
nested bodies.

The more we can "fit" the spec into what is already out there, the
better.

So, I don't mind to strongly recommend people to implement alternative,
and give examples why it may be useful in the future, but at the same
time I think we should also say that if the receiver does not support
alternative a error response MUST be sent - in order to avoid cases e.g.
described by Francois, where the receiver simply discard the multipart
and continues the call setup.

Regards,

Christer

> >>>> OPEN ISSUE 1: do we need to say something about other types?  
> >>>> Related (rfc2387), parallel, digest, external-body.
> >>> I don't know much about these. I quickly scanned 2387 and 
> see that 
> >>> it has some special rules re processing 
> Content-Disposition of the 
> with what 
> >>> we are doing.
> > Or, at least we could leave support of alternative open for the 
> > moment, until we get more information about how it's supposed to be 
> > used in the first place (regarding identical content type 
> values etc).
> > 
> > 
> >>>> Would it be possible to provide two alternative body parts using 
> >>>> the same format and, thus, the same content type but in, say, 
> >>>> different languages?
> >> If people agree that this should be a MUST, I will be 
> happy to change 
> >> it.
> >

---

From: Paul Kyzivat <[email-masked]>
Date: Tue, 29 May 2007 09:53:48 -0400

Christer Holmberg (JO/LMF) wrote:
> spec should not make them "not compliant".

The MIME spec already says that if you don't understand multipart/X then 
you should treat it as if it were multipart/mixed. So at a minimum we 
should expect implementations to do that much with alternative.

If we are going to make more accommodation than that based on what is in 
the wild then I suggest we should take a survey first to find out what 
we really need to cope with. We should be able to get some good data 
from SipIT. Maybe we should be trying to come up with a list of specific 
questions, or maybe we can have an essay question on the survey to get a 
description of exactly what is/isn't supported.

I think we will have a pretty good chance of seeing support in the 
future if we can tell implementors what they must do. I did 
specifications for multipart support in a stack a few years ago (which 
is when I discovered all these open issues), and I had to make up what 
was done based on speculation about what would be used. Even hard things 
can be straightforward to implement if the requirements are clear.

	Paul

> The same thing goes for

---

From: "Dan Wing" <[email-masked]>
Date: Tue, 29 May 2007 12:37:55 -0700

Paul Kyzivat wrote: 
...
> > parts using the
> making this decision based on other attributes is valid. For 
> one thing the parts are supposed to be ordered by increasing 

Multipart/alternative is the best we have, though.  And who is to say that
image/jpeg is richer than image/gif, or that english is richer than latin?  

Anyway, the following RFCs standardize the use of Content-Language and refer
to using multipart/alternative when providing support for multiple
languages:

  http://tools.ietf.org/html/rfc3282
  http://tools.ietf.org/html/rfc3066

-d

---

From: "Christer Holmberg (JO/LMF)" <[email-masked]>
Date: Wed, 30 May 2007 10:07:01 +0200

Hi,

I don't think we should try to specify in detail when one is allowed to
use alternative, and one is not allowed, but instead refer to other
specifications for specific content types, and say that an
implementation shall reject the message if alternative is used in a
wrong way (based on those other specs).

I think our main focus should be to describe the expected protocol level
behavior of a SIP entity when receiving alternative.

Do we have the same issue with mixed, btw? I assume there COULD be cases
where the same content type can be used with mixed?

Regards,

Christer 

> Sent: 29. toukokuuta 2007 22:38
> To: 'Paul Kyzivat'; Gonzalo Camarillo (JO/LMF)
> Cc: 'Francois Audet'; [email-masked]; Christer Holmberg (JO/LMF)
> parts using 
> For one thing 
> Multipart/alternative is the best we have, though.  And who 
> is to say that image/jpeg is richer than image/gif, or that 
> english is richer than latin?  
> 
> Anyway, the following RFCs standardize the use of 
> Content-Language and refer to using multipart/alternative 
> when providing support for multiple
> languages:
>

---

From: "Christer Holmberg (JO/LMF)" <[email-masked]>
Date: Wed, 30 May 2007 10:14:03 +0200

Hi, 

> >> and people seem to agree that alternative is the way to 
> go. That is 
> >> why it would be great if we could mandate its support already now.
> >>
> >> The more we wait, the more trouble we could have in the 
> future to use 
> >> it.
> > 
> > Yes.
> > 
> > But, at the same time we need to try to be backward compatible, and 
> > take into consideration existing implementations which may support 
> > mixed but not alternative. If those implementations reject 
> alternative 
> > I think our spec should not make them "not compliant".
> 
>The MIME spec already says that if you don't understand 
>multipart/X then you should treat it as if it were 
>multipart/mixed. So at a minimum we should expect 
>implementations to do that much with alternative.

Well, assuming we don't think THAT could cause problems in the future...

But, since that is generic specific MIME behavior I think we'll have to
live with it.

But, I STILL think it's good to give an implementation to option to
reject alternative - at least if we find out that is what existing
implementations are doing.
  
>If we are going to make more accommodation than that based on 
>what is in the wild then I suggest we should take a survey 
>first to find out what we really need to cope with. We should 
>be able to get some good data from SipIT. Maybe we should be 
>trying to come up with a list of specific questions, or maybe 
>we can have an essay question on the survey to get a 

My understanding is based on my SIPit experience, and what I have
implemented myself.

But, I have to admit I haven't been to SIPit for a while, so someone
else (Robert?) may have better information.

>I think we will have a pretty good chance of seeing support 
>in the future if we can tell implementors what they must do. 

It's not always the implementors we have to tell - often it's the people
paying the implementors :)

>I did specifications for multipart support in a stack a few 
>years ago (which is when I discovered all these open issues), 
>and I had to make up what was done based on speculation about 
>what would be used. Even hard things can be straightforward 
>to implement if the requirements are clear.

I am not saying that it is difficult to implement alternative, but I
doubt many have done it.

But, it would be interesting to know what implementations do: 

1. do they treat alternative as mixed? 
2. do they reject the request?
3. do they support alternative? 
4. do they discard the message body?

I think our spec should allow options 1, 2 and 3.

Regards,

Christer

---

From: Gonzalo Camarillo <[email-masked]>
Date: Wed, 30 May 2007 11:56:35 +0300

Hi Dan,

thanks for the pointers. It seems that we want to specify that, for 
multipart/alternative bodies whose content disposition is "session" (or 
early session), the content-types of all body parts MUST be different.

However, multipart/alternative bodies with a different disposition type 
should follow the general MIME rules.

Cheers,

Gonzalo

---

From: "Dan Wing" <[email-masked]>
Date: Wed, 30 May 2007 12:33:11 -0700

> Sent: Wednesday, May 30, 2007 1:57 AM
> To: Dan Wing
> Cc: 'Paul Kyzivat'; 'Francois Audet'; [email-masked]; 'Christer 
> Holmberg (JO/LMF)'
> However, multipart/alternative bodies with a different 
> disposition type should follow the general MIME rules.

Yes, I concur.

You also brought up an interesting point with language.  One Might Consider
it reasonable to have multipart/alternative, with several application/sdp
parts which differ in language (and probably different m/c lines).  Your
document should probably provide a pointer to SDP's a=lang and guidance
towards its use in conjunction with SDP Capability Negotiation.  Sortof a
'you might be tempted to use MIME constructs where SDP should be used
instead'.  That is, if there is agreement that a=lang and SDP Capability
Negotiation is the right way to select language.

(I'm thinking of situations where, for example, you want to send an offer
for an English, German, or French announcement ("The dam broke, please
evacuate to higher ground") or an IVR or a human telephone operator).

-d

> is to say that
> Content-Language and refer

---

From: Paul Kyzivat <[email-masked]>
Date: Wed, 30 May 2007 18:10:02 -0400

Dan,

If I follow what you are saying then I disagree with the use case.

I believe the Content-Language specifies the language of the text in the 
body part, not the language that might be conveyed in a media stream 
that is negotiated by the SDP in the body part.

	Paul

---

From: "Dan Wing" <[email-masked]>
Date: Wed, 30 May 2007 17:02:55 -0700

I'm fine with that interpretation, too, because it keeps us away from using
MIME to negotiate and we keep negotiation in SDP (and SDP Cap Neg).

-d

> Sent: Wednesday, May 30, 2007 3:10 PM
> To: Dan Wing
> Cc: 'Gonzalo Camarillo'; 'Francois Audet'; [email-masked]; 
> 'Christer Holmberg (JO/LMF)'

---

From: Cullen Jennings <[email-masked]>
Date: Wed, 30 May 2007 19:32:49 -0700

I like the draft - this looks like exactly they type of think I was  
hoping someone would write. Thank you,  Cullen

On May 27, 2007, at 12:22 PM, Gonzalo Camarillo wrote:

> Hi Paul,
>
> I have added a few guidelines about this in Section 5 of the new  
> version of the draft:
>
> With those guidelines and the behavior defined in other sections,  
> we should be OK. Let me know if you agree or want to add further  
>>> - What "handling" value should be used for multipart bodies and  
>>> the contained body parts?
>>>
>>> If a body part is referenced by a cid: url in a header (or in  
>>> another body part I suppose), then the handling of the body part  
>>> should be required.
>> If the header containing the reference is optional (as most are),  
>> then recipients that don't understand the header will have no need  
>> for the referenced part. If it were required and they don't  
>> support the type, then they would fail the request. This is bad.
>> So if processing of the header is optional, then the referenced  
>> body part should have optional handling.
>> But then there could be a problem if the recipient does understand  
>> and process the header, but doesn't understand the body part, and  
>> so because it is optional doesn't process it. In that case, the  
>> cid reference will be unsatisfied. This could also result in an  
>> inappropriate error.
>> I think the solution here is that if a header contains a cid url,  
>> and if that url cannot be resolved to a body part that is  
>> supported, then the UA should treat it the same as if the header  
>> itself was not understood - typically ignoring it unless there is  
>> a Require in effect that demands failing the request.
>> An alternative is to require that Content-ID be remembered even  
>> for parts that are not understood, so that references can be  
>> resolved even if they can't be processed. This would allow more  
>> precise errors to be generated. This wouldn't be so hard at an  
>> outer level, but it might be troublesome in conjunction with nesting.
>>     Paul
>
>
>