Re: [Sip] Comments on draft-ietf-sip-body-handling-02

Fri, 01 Aug 2008 02:55:59 -0700 

Hi Keith,

sure, I can add a sentence per your suggestion below.

Thanks,

Gonzalo

DRAGE, Keith (Keith) wrote:
My personal preference would be to add a disclaimer sentence to indicate that such semantics are not defined in any SIP RFC (so far), so any interpretation of the relationship between multiple parts when they are nested or otherwise is solely dependent on the interpretation of the MIME values, and that the examples imply no specific definition of semantics for SIP. 
As this is an interpretation, different vendors may have different 
interpretations.

I could live without this, but something conveying this sense would be better.

Keith


-----Original Message-----
From: Gonzalo Camarillo [mailto:[EMAIL PROTECTED] Sent: Friday, August 01, 2008 10:40 AM 
To: Paul Kyzivat
Cc: DRAGE, Keith (Keith); SIP IETF
Subject: Re: [Sip] Comments on draft-ietf-sip-body-handling-02

Hi Keith,
per our conversation, I guess we can just leave the text as it is right now. The thing is that nesting was already defined for email and we do not really want to change those definitions and recommendations. The only thing we are doing here is stressing that you should not just perform nesting for fun. You need a reason to do that. 

Thanks,

Gonzalo


Paul Kyzivat wrote:


DRAGE, Keith (Keith) wrote:


I know we do have this paragraph in section 4.1:
Nested MIME bodies are yet another useful tool to build 
and combine
SIP extensions. Using the extensions in the previous 
examples, a UA
that supported a new session description format and 
that needed to

   include a location object in an INVITE request would include a
'multipart/mixed' body with two body parts: a location 
object and a

   'multipart/alternative'.  The 'multipart/alternative' body part
would, in turn, have two body parts: a session 
description written in

   SDP and a session description written in the newer session
   description format.
But thinking about this, I suspect we define no semantics anywhere (please correct me if I am wrong) about what nesting means. Does a nested body require different interpretation to a
multipart body, and
if so, how do I discover what that difference is. All the nesting would seem to tell me is that there might be a different relationship, but it does not tell me what that relationship is.
I agree that the current loose wording leaves something to 
be desired.

I just don't know how to fix it.

Let me give a concrete example:

Is an INVITE valid if it contains a body of:

    multipart/mixed {
       multipart/mixed {
          multipart/mixed {
             application/sdp
    }}}

Must the UAS keep unwrapping multiparts, looking for its SDP?

And while we are discussing weird cases, what about:

    multipart/mixed {
       multipart/mixed {
          multipart/mixed {
             application/sdp-1
          }
          application/sdp-2
    }}
If the latter is legal at all, which sdp is the offer? And
what should 
happen to the other one?
I know these are bizarre cases. I'm just pushing the envelope to understand the implications for the sorts of decoding logic
the stack 
should be expected to use.

    Thanks,
    Paul




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

Reply via email to