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.
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...
True, it must parse it. And then it must seek out the body part that has
the proper cid. Otherwise it must seek out the body part that has the
proper C-D. Not much different there. Certainly not much of an
additional hurdle if you have already agreed to implement the rest of
the new info-package machinery.
Paul
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
_______________________________________________
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
