I think we're just going 'round and 'round on basically a non-issue. Making *any* changes to INFO which don't provide real, tangible, and immediate value to either the developer or the customer/user, does not bode itself well to getting implementation. Because INFO works.
Having a negotiation/detection scheme provides real, immediate value, by avoiding/reducing configuration. Having a sub-context for the context already created by the "INFO" method does *not* provide such value, because there are no collisions/confusion in the real world AFAIK; but it was a common complaint from the IETF, so we put the Info-Package header in to resolve that. It can basically be handled as syntactic sugar by current implementations, and is similar to Sub/Not/Pub, so fine. Then somehow between IETF Dublin and Minneapolis, a mere 3.5 months (but a world apart in Guinness flavor), the draft doubled in size, adding another 20 pages. To do what? To add more dis-ambiguation and contextualizing, for a problem that has never actually been seen in the wild?? How many contexts of contexts, and meanings of meanings, do we need? What value does that add over the currently deployed INFO? -hadriel > -----Original Message----- > From: Paul Kyzivat [mailto:[EMAIL PROTECTED] > Sent: Wednesday, December 03, 2008 3:39 PM > To: Christer Holmberg > Cc: Hadriel Kaplan; Dean Willis; SIP List > Subject: Re: [Sip] Multiple body-parts in one INFO > > > > Christer Holmberg wrote: > > Hi, > > > > - CID is too complex, and I think it will prevent some people from > > moving from legacy to info packages. > > > > - "Render" as the c-d is probably not 100% waterproof, since other body > > types may also use it. > > > > - I DO still strongly support a new c-d for the package body, but it > > seems that others have issues with that. > > How is CID "too complex"??? The id can be hard coded in most cases. So > its just some additional boiler plate to add into the request. And it > adds *1* extra header to the message. Anybody who can't manage that > shouldn't be sending SIP messages. > > I do think that a *new* c-d would be clearer than reusing "render". > > I guess my preferences (1-100, 1 best) are: > > 1) new c-d > 2) cid > 10) c-d "render" > 100) single c-t for info-packages. > > Paul _______________________________________________ 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
