Re: [Sip] Support for Multipart/MIME - support of alternative

[Paul Kyzivat <[e-mail]>]

Christer Holmberg (JO/LMF) wrote:
> 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.
>>
>> 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.

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
> 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
> 
> 
> 
> 
> 
>> Christer Holmberg (JO/LMF) wrote:
>>>  
>>> Hi,
>>>
>>>>>> 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.
>>>> 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'."
>>> 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).
>>>
>>>>>> 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.
>>>> I double check with an email expert to make sure we get this right.
>>>
>>>>> Another thing in Section 3: You have used SHOULD in this 
>> section. I 
>>>>> 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.
>>> Again, I think we should wait a little regarding alternative.
>>>
>>> Regards,
>>>
>>> Christer
>>
> 


_______________________________________________
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