Re: [Sip] Binary Encoding for SIP

Hi Cullen,

I am for 'a'. However, there may be some proxy severs who have the 
capability in handling 8-bit (text) data, not binary data. There may be 
an impact on all SIP entities including proxy servers that need not 
handle S/MIME data. 

Regards,
Kumiko 

>I sat for a long time looking at that one MUST and trying to decide if it
>should be a SHOULD. I also avoided mentioning what Henning points is the
>more interesting question of what must all UAs be willing to receive.
>
>So I take if you would be happy to see is say that things SHOULD send binary
>but need to be prepared to receive anything.
>
>I can live with that. Fits a certain stringent in what you send, lenient in
>what you receive model that I like. I doubt that implementers will be busy
>to go off and implement receiving multiple different things when there is no
>apparent value to doing that. It would solve my one really key issues which
>is that I would like to give enough guidance on the minimum to implement
>that things like S/MIME had a better chance of working together.
>
>Cullen
>
>
>
>On 2/17/04 9:44 AM, "Bryan Thale" <bryan.thale@motorola.com> wrote:
>
>> Hi Cullen,
>> 
>> I'd vote for 'b', not because the idea is stupid but because it is
>> unnecessary.  Why restrict the ability of the end-point service to
>> choose the most efficient encoding for its purposes?  If that happens to
>> be 'binary' then great, but if not, that's OK, too.
>> 
>> I agree with this sentiment from your draft:
>> 
>>> ... it is reasonable to suggest that SIP implementations send one type
>>> of encoding
>> 
>> 
>> However, this is at odds with the ultimate recommendation of your draft:
>> 
>>> Devices MUST use a content transfer encoding of "binary" for MIME body
>>> parts in SIP messages they send.
>> 
>> 
>> If the problem is that implementors are inappropriately choosing Base64
>> due to lack of sufficient guidance, I would prefer to see "Devices
>> SHOULD use ..." instead.  It provides the needed guidance and yet does
>> not arbitrarily close doors on possible future implementations.
>> 
>> Bryan.
>
>
>_______________________________________________
>Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
>This list is for NEW development of the core SIP Protocol
>Use sip-implementors@cs.columbia.edu for questions on current sip
>Use sipping@ietf.org for new developments on the application of sip

--
Kumiko Ono
NTT Network Service Systems Labs.
Tel +81 422 59 4508/Fax +81 422 60 4012

_______________________________________________
Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use sip-implementors@cs.columbia.edu for questions on current sip
Use sipping@ietf.org for new developments on the application of sip