Hi,

I agree to both a) and b), and even c) :)

But, my question is still: what makes support of multiple packages
un-simple? Based on the discussions we had on the list before the IETF
meeting, I thought there were no problems.

Regards,

Christer 

-----Original Message-----
From: Hadriel Kaplan [mailto:[EMAIL PROTECTED] 
Sent: Friday, November 28, 2008 7:36 PM
To: Christer Holmberg; Eric Burger
Cc: SIP List
Subject: RE: [Sip] INFO Framework - one pakage per INFO

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

Reply via email to