Re: 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