Hi, >>>to which I believe we have an answer: "Yes. One per INFO". >> >>IF we would end up using CID, I still don't see the problem. There >>would be a direct "link" between a Info-Package value and a body >>part (assuming there is an associated body part). >> >>If we are NOT going to use CID (or any other mechanism which creates >>the same link) I am ok with one-per-INFO. > > >And that's why we're still discussing it. > >No, we're still discussing it because you people are stubborn, as am I. ;) We clearly all have different definitions for the KISS principle, which is probably natural.
We also seem to have different definitions for the scope of what we are supposed to do as part of this WG item, which is also natural - at least in SIP :) >Let's imagine, for sake of argument, that the solution to the general SIP message problem of dis-ambiguating body parts which don't belong to the message context, were to be solved by creating a CID for >all the body-parts that *did* belong to the message context. I think that would be incredibly foolish, maybe even pathological, but let's just pretend that we decided it was the right solution... (nice >setup, eh? :) Would we: >a) Put the CID URL in specific SIP headers unique to each message type, for example "Info-Package:", "Event:", "Invite-cid:", "Message-cid:", etc.? >b) Put the CID URL in a SIP message header common to all message types? > >Now I would claim that any sane human would go with option (b), thereby nixing multiple Info-Packages to begin with. (and oh by the way showing why we shouldn't try to solve this for Info only) But let's >just suppose that we chose option (a), to confirm our pathological behavior... > >Then someday in the future we define Info-Packages "Foo" and "Bar". I send them both in an INFO. I get a 400 back. Which one failed? One of them could be a critical type, with app-level failure maybe >even sent in upstream requests - but I got a 400 and no upstream request - it's possible the critical one didn't even get to the app layer, or it's the other package context that failed. Hmm. We already have that problem today. A specific SIP request can "fail" due to many reasons (not only related to message bodies), but we are only allowed to send one single response code back. >Or let's say we define an Info-Package "Foo", and for some reason we decide it's really important and needs a special SIP header for it too in the INFO request. Like, oh, I don't know... a header called >"User-to-User" to carry UUI data. (I know, I have an active imagination!) Which package would this header belong to? I mean, my god there could be another future package which needs that same header >too! Would we create a "Header-ID" param and HID URL too?? Is this really a problem for non-INFO message bodies? There is no CID for SDP, but clients seem to be able to deal with it anyway. Because, in most cases today clients are able to find out what is in a message body, and what to do with it, based on the Content-Type value. There are multiple usages of XML message bodies, but even in all of those cases I think the Content-Type value gives more information than simply saying "XML". So, something like "Content-Type: application/info+foo" would solve this. No need for new headers, no need for CIDs, no need for nothing... That is MY definition of KISS (apart from being one of the coolest rock band :) I hear Paul's argument that people may want to used the same C-T value as they use for legacy INFO today, but I really see no problem in using something else. They can still use exactly the same data content. Regards, Christer _______________________________________________ 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
