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

["Christer Holmberg (JO/LMF)" <[e-mail]>]

 
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