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
