Re: INFO Framework - one pakage per INFO

Oh man! I'm in tryptophan overdose!

On Nov 28, 2008, at 12:35 PM, Hadriel Kaplan wrote:

> I think I was one of the people at the meeting who argued against  
> it, so I'll talk turkey:
>
> INFO is in wide use today, and it works(!), with barely any interop  
> problems.
>
> IMHO, the requirements driving the INFO packages draft was to solve  
> two specific problems with current INFO:
> 1) Negotiation/advertisement of INFO uses, so that a UA is not  
> "surprised" when it gets an INFO, and we don't need system  
> configuration for every UA we talk to for what it can do.   
> Configuration on a system-wide basis is one thing, but configuration  
> per far-end is *really* bad.
> 2) Indication of what the use is for the INFO message that is sent,  
> so that one can receive the INFO method without ambiguity as to its  
> purpose.
>
> Those are the only things that drove a new draft, AFAIK.  Anything  
> else is basically gravy.
>
> We also had consensus (I think) a while back that the only chance we  
> have to make people use this draft instead of current INFO was to:
> a) Keep it simple.
> b) Keep it simple.
> c) Keep it simple.
>
> So ISTM we don't have room for gravy - we need to focus on slice of  
> the pie that we care about.  We need to keep the weight off the  
> draft by sticking to the meat of the problems being solved, without  
> stuffing in extra capabilities and by skipping the extra portions.   
> If we pile on more features, and mash in scenarios not covered by  
> current INFO, there's little chance current systems/implementers  
> will digest this thing and we'll end up with a dead duck instead.   
> So I was one of the people that cried fowl at the last meeting, and  
> suggested we scrape the extras off our plate so we can serve up a  
> draft people can really swallow.  Otherwise they'll continue doing  
> what they're doing now.  We can shop around for more features the  
> day after the draft is done, by putting extras in packages - but  
> having people buy into those is only possible if we make the base  
> draft cheap to implement now.
>
> -hadriel
>
>> -----Original Message-----
>> From: [email protected] [mailto:[email protected]] On Behalf Of
>> Christer Holmberg
>> Sent: Friday, November 28, 2008 8:48 AM
>>
>> Hi,
>>
>> If there is no technical reason I don't see why we again shall make a
>> restriction which we later may "suffer" from.
>>
>> 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