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.
Even if the value is hard coded on the sender side, the receiver will still have to parse it - unless we define a hard coded value which everyone must always use for info packages... If we would allow multiple info packages per message I could see the use of CID, but for a single info package I think a new c-d (or c-t) is much more simple. >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. I agree with 1) :) 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
