HOWEVER, I thought consensus was one Info Package per INFO request.
BTW, 20 pages for INFO is OK, as most of the text is a dissertation on why we are doing what we are doing. Remember, this is the merge of not one, not two, but THREE documents. Get over it ;-)
You know, we just passed 300 messages on THIS version of the INFO draft. I was going to wait for the traffic to die down before doing the next revision. Wonder when that will be? Soon, I hope.
On Dec 4, 2008, at 7:43 PM, Hadriel Kaplan wrote:
-----Original Message-----From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of DeanWillis Sent: Thursday, December 04, 2008 6:24 PM On Dec 4, 2008, at 1:35 PM, Christer Holmberg wrote: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.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.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??-hadriel _______________________________________________ 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
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ 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
