Subject: [Sip] Binary Encoding for SIP

From: Cullen Jennings <[email-masked]>
Date: Sat, 14 Feb 2004 23:03:21 -0800

I submitted a draft on binary encoding for SIP. This improves
interoperability, improves speed, decreases sizes of messages, and generally
makes life better for SIP which will no doubt eventually help with World
Hunger. I need feedback, please let me know:

a) Yah, lets do it

b) No this is a stupid ideas and here are the reasons why

c) There has not been many list comments, this draft involves some very
complex issues. I need a year or two to develop an opinion on the single
sentence inside it.

d) I agree with Cowboy Willis

Until it arrives in the archives, you can find it at

http://www.employees.org/~fluffy/ietf/draft-jennings-sip-mime-01.html

or, if you prefer ASCII encodings of everything,

www.employees.org/~fluffy/ietf/draft-jennings-sip-mime-01.txt

Thanks, Cullen

_______________________________________________
Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use [email-masked] for questions on current sip
Use [email-masked] for new developments on the application of sip

---

From: Henning Schulzrinne <[email-masked]>
Date: Sun, 15 Feb 2004 10:43:47 -0500

You should apply for a job at a local tabloid - headlining a discussion 
on the encoding of MIME body parts into the mother of all mailing list 
battles on protocol encoding.

Given the first reaction to the draft: this is only about the SIP body. 
Cullen is not proposing that SIP headers be coded in ASN.1 :-)

I'm for option (a), for the reasons you mention. The more interesting 
question is whether all SIP devices still need to be prepared to receive 
all the various encodings.

---

From: Marc Petit-Huguenin <[email-masked]>
Date: Sun, 15 Feb 2004 09:03:07 -0800

I thought that binary body was already supported: RFC3261 section 7.4.1, 
third paragraph.

---

From: neil quiogue <[email-masked]>
Date: Mon, 16 Feb 2004 05:06:50 +0800

I think what Cullen is proposing is to only send one type of MIME body part 
encoding (i.e., binary) instead of having multiple possible MIME encoding 
as specified on RFC3261/7.1.4.

Regards, Neil

--On dimanche 15 février 2004 09:03 -0800 Marc Petit-Huguenin 
<[email-masked]> wrote:

>> interoperability, improves speed, decreases sizes of messages, and
>> generally makes life better for SIP which will no doubt eventually help
>> with World Hunger. I need feedback, please let me know:
>>
>> a) Yah, lets do it
>>

---

From: Paul Kyzivat <[email-masked]>
Date: Tue, 17 Feb 2004 09:27:46 -0500

Cullen,

This is an attractive proposal because it has potential to make sip 
implementations simpler. But before I can answer I need clarification on 
one thing:

Does this apply to content referenced and fetched via content-indirection?

This proposal only has value if my mime processor *never* needs to deal 
with any content-transfer-encoding other than binary. If content 
referenced by content indirection still might use other encodings, then 
that value is lost. Unfortunately, given the potential range of 
transports that might be used with content indirection, I don't know if 
requiring binary can be done in general.

	Paul

---

From: Cullen Jennings <[email-masked]>
Date: Thu, 19 Feb 2004 22:21:19 -0800

Good point. 

I think that all they ways I can imagine getting indirect content, HTTP,
FTP, TFTP, NFS, SMB, file are all 8 bit safe so I think this argument
probably still holds.

Cullen

---

From: Cullen Jennings <[email-masked]>
Date: Thu, 19 Feb 2004 22:18:51 -0800

You are right - 3261 definitely allows binaries bodies.

I am just trying to suggest that it would be better to send MIME bodies with
a transfer encoding set to binary instead of base64 when sending them. Right
now SIP allows either, the examples are in base64, but binary is probably a
better choice. It seems like it should not be a big deal but it has been one
of the frustrating interoperability issues in getting S/MIME to work.

Cullen