Subject: Re: [Sip] MIME: Nested bodies with option-tag?

From: Eric Burger <[email-masked]>
Date: Sun, 17 Jun 2007 20:11:01 +0900

<I-still-hate-XML-but-fine-to-make-a-point>

Going a step further: if SIP goes beyond the standard MIME processing, I
would offer that rather than use the hammer of the 1990's (MIME), we move to
the hammer of the 2000's (XML).

:-))

</I-still-hate-XML-but-fine-to-make-a-point>

On 5/30/07 4:53 AM, "Gonzalo Camarillo" <[email-masked]>
wrote:

> Hi,
> 
> what Keith says makes sense. I believe mandating support for multipart
> in SIP is a SIP-specific problem. Mandating suppport for
> multipart/alternative is also a SIP-specific problem, since a
> SIP-specific problem such as the transition to new session description
> formats depends on that.
> 
> However, specifying if an implementation that supports multipart should
> support nested body parts or not is something more general on which the
> email folks have a lot of experience.
> 
> Cheers,
> 
> Gonzalo
> 
> 
> DRAGE, Keith (Keith) wrote:
>> Well, at the moment, what I am trying to do is get some understanding of
>> what we should scope as valid SIP work.
>> 
>> We need to be able to understand why something that is clearly a generic
>> problem for specification of nested MIME bodies merits a SIP specific
>> solution.
>> 
>> So:
>> 
>> -       is a generic solution already documented elsewhere?
>> 
>> -       if a generic solution is not documented elsewhere, should one be
>> documented, rather than a specific SIP solution?
>> 
>> Regards
>> 
>> Keith
>> 
>>> -----Original Message-----
>>> From: Christer Holmberg (JO/LMF)
>>> [mailto:[email-masked]]
>>> Sent: Wednesday, May 30, 2007 8:52 AM
>>> To: DRAGE, Keith (Keith); Gonzalo Camarillo (JO/LMF); Paul Kyzivat
>>> Cc: [email-masked]
>>> Subject: RE: [Sip] MIME: Nested bodies with option-tag?
>>> 
>>> 
>>> Hi Keith,
>>> 
>>>> Once we get down to a decision of supporting nested versus not
>>>> supporting nesting, presumably we are then entirely in the
>>> realm of the
>>>> multipart coding itself.
>>>> 
>>>> Could I ask someone to elaborate on what generic
>>> requirements already
>>>> exist within multipart/mime in this respect, before we start
>>> looking at
>>>> defining SIP specific rules or indications?
>>> 
>>> I am very sure that I have seen text related to the support
>>> of nested multiparts, and what nodes are expected to support,
>>> somewhere, but I yet have not found it.
>>> 
>>> Regards,
>>> 
>>> Christer
>>> 
>>> 
>>>> 
>>>> Regards
>>>> 
>>>> Keith
>>>> 
>>>>> -----Original Message-----
>>>>> From: Christer Holmberg (JO/LMF)
>>>>> [mailto:[email-masked]]
>>>>> Sent: Tuesday, May 29, 2007 2:47 PM
>>>>> To: Gonzalo Camarillo (JO/LMF); Paul Kyzivat
>>>>> Cc: [email-masked]
>>>>> Subject: RE: [Sip] MIME: Nested bodies with option-tag?
>>>>> 
>>>>> 
>>>>> Hi,
>>>>> 
>>>>> My main concern is not what wording (SHALL, MUST, etc) we use.
>>>>> 
>>>>> The issue is that I think we need text saying what
>>> implementations
>>>>> that DO NOT support alternative and/or nested shall do. If
>>>> we say that
>>>>> they shall reject the message I believe that many of the existing
>>>>> implementations will be compliant with the spec.
>>>>> 
>>>>> And, if we give the possibility to simply reject the message, I
>>>>> believe it will be easier to get people to change their
>>>>> implementations, if they currently simply discard
>>>> alternative and/or
>>>>> nested today.
>>>>> 
>>>>> Regards,
>>>>> 
>>>>> Christer
>>>>> 
>>>>> 
>>>>>> -----Original Message-----
>>>>>> From: Gonzalo Camarillo [mailto:[email-masked]]
>>>>>> Sent: 29. toukokuuta 2007 16:06
>>>>>> To: Paul Kyzivat
>>>>>> Cc: Christer Holmberg (JO/LMF); [email-masked]
>>>>>> Subject: Re: [Sip] MIME: Nested bodies with option-tag?
>>>>>> 
>>>>>> Hi,
>>>>>> 
>>>>>> what I am hearing is that there are implementations out
>>>> there that
>>>>>> support multipart but not nested. Therefore, we need to
>>> decide two
>>>>>> things:
>>>>>> 
>>>>>> 1) do we want to have a MUST for multipart and a SHOULD for
>>>>> nested? I
>>>>>> would say that we should have the same level (e.g., MUST, if we
>>>>>> decided that MUST is appropriate) for both.
>>>>>> 
>>>>>> 2) do we need a way for implementations that support
>>>>> multipart but not
>>>>>> nested to be quickly updated to, at least, report that
>>>> fact with an
>>>>>> error response? This may make sense.
>>>>>> 
>>>>>> Cheers,
>>>>>> 
>>>>>> Gonzalo
>>>>>> 
>>>>>> Paul Kyzivat wrote:
>>>>>>> More or less repeating what I said before:
>>>>>>> 
>>>>>>> I expect we do have to account in some way for
>>>>> implementations that
>>>>>>> have already been deployed, in absence of a
>>> clarifying document.
>>>>>>> Exactly how we deal with that is still TBD.
>>>>>>> 
>>>>>>> But as we define what is required to support this in the
>>>>> future, I
>>>>>>> think there is *no* benefit to defining two levels of
>>>>>> support - full
>>>>>>> and partial. Anybody that sets out to provide support
>>> for this
>>>>>>> document should be expected to do it all - its not that
>>>>> much harder.
>>>>>>> 
>>>>>>>     Paul
>>>>>>> 
>>>>>>> Christer Holmberg (JO/LMF) wrote:
>>>>>>>> Hi,
>>>>>>>>>   I wonder whether we should define an option-tag for the
>>>>>> support of
>>>>>>>>>   nested bodies.
>>>>>>>>> 
>>>>>>>>> I don't think there's a lot to be gained from
>>>> defining such an
>>>>>>>>> option-tag.  The sender should already be aware that
>>>>>> there is a risk
>>>>>>>>> the recipient can't understand nested bodies, and have
>>>>>> arranged for
>>>>>>>>> suitable fallbacks.  Conversely, the recipient should (at
>>>>>> least) be
>>>>>>>>> able to skip the nested multipart body part in the proper
>>>>>> "I don't
>>>>>>>>> understand this body part" way.  All an option-tag would
>>>>>> do is allow
>>>>>>>>> the sender to not add a fallback.
>>>>>>>> 
>>>>>>>> In that case we need some specific text saying that if the
>>>>>> receiver
>>>>>>>> does not support nested multiparts it MUST
>>> do-this-and-do-that.
>>>>>>>> 
>>>>>>>> Because, as I said earlier, I don't think we will
>>>>> achieve what we
>>>>>>>> want by saying that one MUST be able to parse nested
>>>>>> multiparts. It
>>>>>>>> can be rather tricky to implement (depending on how the
>>>>> parser is
>>>>>>>> implemented, though), and since there aren't really any
>>>>>> use-cases out
>>>>>>>> there yet I am pretty sure some people will choose not to
>>>>>> implement
>>>>>>>> it (and saying that people are not compliant in that
>>>>> case will not
>>>>>>>> really help from an interop perspective). So, because of
>>>>>> that I think
>>>>>>>> it would be good not to mandate the support of nested
>>>>>> multiparts, but
>>>>>>>> to mandate appropriate behavior if not supported - just
>>>>>> like in any
>>>>>>>> other case when a MIME body contains an unsupported but
>>>>>> required content type.
>>>>>>>> 
>>>>>>>> Regards,
>>>>>>>> 
>>>>>>>> Christer
>>>>>>>> 
>>>>>>>> 
>>>>>>>> 
>>>>>>>>> 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
>>>>>>>> 
>>>>>>> 
>>>>>>> 
>>>>>>> _______________________________________________
>>>>>>> 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
>>>>> 
>>>> 
>>> 
>> 
> 
> 
> 
> _______________________________________________
> 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

Notice:  This email message, together with any attachments, may contain information  of  BEA Systems,  Inc.,  its subsidiaries  and  affiliated entities,  that may be confidential,  proprietary,  copyrighted  and/or legally privileged, and is intended solely for the use of the individual or entity named in this message. If you are not the intended recipient, and have received this message in error, please immediately return this by email and then delete it.

_______________________________________________
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: Paul Kyzivat <[email-masked]>
Date: Mon, 18 Jun 2007 10:16:45 -0400

> <I-still-hate-XML-but-fine-to-make-a-point>

:-)

I hate it too - not in the abstract, but in the way it has become the 
solution to all problems. IMO it is ok as an extensible, interoperable, 
program-to-program representation of complex structured data. But it is 
not a programming language, or suitable as a user interface, and people 
should not have to write it.

> the hammer of the 2000's (XML).

Perhaps if we were starting off to do SIP/3.0 (no I'm not suggesting 
that we do that), it might make sense to use XML rather than MIME.

Given where we are, I don't think it makes sense to use XML rather than 
MIME to represent multiple independent body parts in a request.

We are *already* defining most new body parts in XML, and making them 
extensible so that they can contain other XML things. But I wouldn't go 
out of my way to start redefining mime-type as XML just so they can be 
incorporated into other XML things.

	Paul