Re: 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.
> 
> 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