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

From: [email-masked]
Date: Sun, 3 Jun 2007 18:47:49 -0400

From: "DRAGE, Keith \(Keith\)" <[email-masked]>

   Well, at the moment, what I am trying to do is get some understanding of
   what we should scope as valid SIP work.

I've been busy, so I may be behind in the discussion, but it's not
clear to me that there is anything that needs to be done specifically
for SIP.  I may well be wrong, but my impression is that MIME already
has the features and specifications neede so that a receiver can
decide whether it has adequately "understood" the document when it
only understands some components.  These mechanisms are all inherited
by SIP and I would expect be a sufficient set of rules.

E.g., a UAC that sends a request with a multipart body must expect
that some UASs will respond with 415, and have some strategy in place
for dealing with that situation.  Similarly, a UAC that sends a nested
multipart body must expect that some UASs will be unable to process
the nested multipart, and will either ignore it or reject the request
(as specified), and the UAC must be prepared to deal with that
situation.

Is there a reason we need to define new, narrower subsets of allowed
behaviors and define a SIP mechanism to negotiate these?

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

---

From: Eric Burger <[email-masked]>
Date: Sun, 17 Jun 2007 19:54:07 +0900

IMHO, this whole thread is threatening.  Think of this analogy:
   SIP:3GPP::MIME:SIP-MIME

We are going WAY down the slippery slope of defining something that looks
like MIME, but is not MIME.  This is bad.  Or evil.  It depends on your
disposition [sic].

If you want to know how that feels, what is your visceral response to
Service Indicator?  Well, that is how the MIME community responds to
proposals that say, "we'll take MIME, but have it operate differently, but
call it MIME."  I know, no matter what we do here, there will be a 3GPP-MIME
:-(

For example, RFC 3204, referenced by the draft, is NOT the normative
reference for the handling parameter.  RFC 3204 describes SIP-ISUP
interworking.  It happens to describe a SIP-specific handling parameter.
RFC 3459 is the normative reference for the handling parameter, which
includes its use in SIP, as well as general-purpose MIME.  I would offer the
description for the motivation for the handling parameter in RFC 3459 is
more relevant to SIP today than the description in 3204.  [As a historical
note, the text for RFC 3459 pre-dates RFC 3204 by 2 years, but had a stupid
dependency on another document that didn't pop until 2003.  That was my
fault.]

I do NOT buy the argument there are too many broken implementations to do
the right thing.  In that case, jettison the whole MIME infrastructure and
build something you like (any takers for XCAP?).  Do the right thing now,
and say, "MIME is MIME."  You even get some benefits, like a bunch of open
source MIME implementations that one can use, rather than hacking these
implementations to do SIP-specific stuff.

On 5/29/07 9:05 AM, "Gonzalo Camarillo" <[email-masked]>
wrote:

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

---

From: Eric Burger <[email-masked]>
Date: Sun, 17 Jun 2007 19:41:18 +0900

Correct.  That is the mechanism specified by RFC 3459.

---

From: Paul Kyzivat <[email-masked]>
Date: Mon, 18 Jun 2007 11:11:42 -0400

Eric,

I don't understand how to apply this to sip. 3459 defines the criterion 
for REQUIRED as:

    If the content gateway cannot pass a body part marked REQUIRED, then
    the entire message has failed.  In this case, the content gateway
    MUST take the appropriate failure action.

That makes sense for a mail gateway. (I don't know if it makes sense for 
a mail user agent.) But attempting to apply it to sip still leaves a lot 
of questions.

In particular, I can see that in a mail message the multipart bodies 
themselves are actually rendered in the sense that they are shown as 
nested containers. In sip, in general that won't be the case - much of 
the content won't be "rendered", though it may be "processed" in some 
sense. Unless we define what we mean by "processing" then I think we 
haven't finished.

Consider a few cases:

1. content-type SDP, content-disposition session;handling=required

We know what that means, if in a message where an offer or answer is 
allowed, or a preview of an offer or answer, or in an OPTIONS response.

We don't have a meaning for this in other contexts, such as SUBSCRIBE, 
NOTIFY, MESSAGE or their responses. If you were to receive the body in 
one of those, what should be done? Should that be a 415 response?

2. content-type text/plain, content-disposition render;handling=required

We know what this means in MESSAGE. What should be done in other 
requests, or in responses?

3. c-t multipart/mixed, c-d ???;handling=required
       c-t SDP, c-d session;handling=required
       c-t application/ISUP, c-d signal;handling=optional

I think this should be legal all the same places where (1) is legal.
But a recipient that doesn't understand multipart/mixed will return a 415.

I don't know what the content-disposition should be for the multipart.
I guess for mail the default of render works, because it can really be 
rendered. That doesn't make sense for sip in this case.

I have never seen an example using a multipart/mixed that included a 
content-disposition for it. AFAIK the default should be 
"render;handling=required". But for sip I don't know what it means to 
"render" a multipart.

4. c-t multipart/mixed; c-d ???;handling=required
       c-t SDP, c-d session;handling=required

This is a little silly, but seems legal. If you can handle (3) then you 
should be able to handle this. Somebody that doesn't handle the 
multipart would return 415.

5. c-t multipart/mixed; c-d ???;handling=required
       c-t multipart/mixed; c-d ???;handling=required
          c-t SDP, c-d session;handling=required

This is even sillier. But it raises more issues. If you handle (4), must 
you also handle this? If it is acceptable to handle (4) and not handle 
this, then what response should there be?

AFAIK these are questions about the application of MIME to sip, that 
don't seem to have been handled by the mail work because the issues just 
didn't come up there.

	Thanks,
	Paul