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
