Re: [Sip] Support for Multipart/MIME

[Paul Kyzivat <[e-mail]>]

Dean Willis wrote:
> 
> On May 9, 2007, at 3:22 PM, Ted Hardie wrote:
> 
>> 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:
> 
> 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."

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

    --boundary1

    Content-Type: application/sdp

    ...SDP here

    --boundary1

    Content-Type: application/pidf+xml
    Content-ID: [e-mail]
    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:[e-mail]">
         <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


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