I haven't chimed in yet, but I too cannot see why this debate continues. As someone whosedone lots of SW development in the past, I see the complexity of more than one INFO package per request to introduce far more potential for complexity than "One INFO package per INFO request". It seems to be an extremely small minority that seems to think the added complexity is worth saving some messages.
I agree there may be some interfaces over which saving bits is very important - in that case, in the past, I've done "message bundling" by including more than one message across the wire at one time. BUT, that was done at a lower layer, entirely transparent to the S/W that generates the basic messages. ISTM that the burden should be on the interfaces with the limitations rather than across the board for all usages of INFO packages - i.e., I don't see this at all to be an INFO package issue. That all said, if there is some correlation/coupling of the two packages by the application, then perhaps you should define a single new package that combines the information - it seems then that the implementation would be significantly simpler. Mary. -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Eric Burger Sent: Sunday, December 07, 2008 10:05 AM To: Hadriel Kaplan Cc: SIP List Subject: Re: [Sip] INFO Framework - one pakage per INFO *IF* we were to do multiple Info Packages in an INFO request, then the UAC is SOL if one package succeeds and another fails. That is the current text. 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 >> Dean Willis >> 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 _______________________________________________ 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
