SNAP - last changes
"Shapira, Noam" <[email protected]> Tue, 14 May 2002 11:01:39 +0300
| Newsgroups | gmane.ietf.vpim |
|---|---|
| Message-ID | <[email protected]> |
This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C1FB1D.1D480BAE Content-Type: text/plain; charset="iso-8859-1" Hi all, The SNAP protocol draft is in it's final stages. The last draft has been sent on February and the changes were presented by my associate (Eli Jacobi) in the last IETF meeting (IETF #53). The changes can be found in the appendix to the draft (that can be found in <http://www.ietf.org/internet-drafts/draft-shapira-snap-03.txt <http://www.ietf.org/internet-drafts/draft-shapira-snap-03.txt> >). There are currently two main open issues: 1. The issue of attachment name and number: * Should it be in SNAP? Currently, in our implementation - we are not using it - but as far as I can see it - it might be needed later on. * If it should be in SNAP - should we add to the draft implementation instruction to the email server developer or should we keep it open (for implementation decision)? * If we provide implementation instruction - should it be according to content-disposition header (as I suggested before) or perhaps using the body-structure. I would be thankful for opinions on these options. 2. The issue of security: In the last IETF meeting the issue of security was raised again: * The protocol should not discuss tunneling through firewalls * The protocol should not use the standard port of HTTP - but rather register a new one. Currently the draft talks about the different security consideration that the SNAP implementer should take in consideration. It does not discuss how to overcome these problems - rather leaves it to be an implementer decision. As far as I can see it - in the next draft I am going to add a registration for a new port. Does any one have any objections? After closing the two open issues -I would like to send the draft for last-call. If there are other open issues as far as you can see it - please let me know. Thanks Noam Shapira Notification Group Leader Corporate Components InCom, R&D Tel: 972-3-766-3605 Mobile: 972-58-543605 ------_=_NextPart_001_01C1FB1D.1D480BAE Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN"> <HTML> <HEAD> <META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; = charset=3Diso-8859-1"> <META NAME=3D"Generator" CONTENT=3D"MS Exchange Server version = 5.5.2655.35"> <TITLE>SNAP - last changes</TITLE> </HEAD> <BODY> <P><FONT SIZE=3D2 FACE=3D"Arial">Hi all,</FONT> </P> <P><FONT SIZE=3D2 FACE=3D"Arial">The SNAP protocol draft is in it's = final stages. The last draft has been sent on February and the changes = were presented by my associate (Eli Jacobi) in the last IETF meeting = (IETF #53). The changes can be found in the appendix to the draft (that = can be found in<U> </U></FONT><U><FONT COLOR=3D"#0000FF" SIZE=3D2 = FACE=3D"Arial"><</FONT></U><A = HREF=3D"http://www.ietf.org/internet-drafts/draft-shapira-snap-03.txt"><= U></U><U></U><U><FONT COLOR=3D"#0000FF" SIZE=3D2 = FACE=3D"Arial">http://www.ietf.org/internet-drafts/draft-shapira-snap-03= .txt</FONT></U><U></U></A><U><FONT COLOR=3D"#0000FF" SIZE=3D2 = FACE=3D"Arial">></FONT></U><FONT SIZE=3D2 = FACE=3D"Arial">).</FONT></P> <P><FONT SIZE=3D2 FACE=3D"Arial">There are currently two main open = issues:</FONT> </P> <P><FONT SIZE=3D2 FACE=3D"Arial">1. The issue of attachment name and = number:</FONT> <BR><FONT SIZE=3D2 FACE=3D"Arial">* Should it be in SNAP? Currently, in = our implementation - we are not using it - but as far as I can see it - = it might be needed later on.</FONT></P> <P><FONT SIZE=3D2 FACE=3D"Arial">* If it should be in SNAP - should we = add to the draft implementation instruction to the email server = developer or should we keep it open (for implementation = decision)?</FONT></P> <P><FONT SIZE=3D2 FACE=3D"Arial">* If we provide implementation = instruction - should it be according to content-disposition header (as = I suggested before) or perhaps using the body-structure.</FONT></P> <P><FONT SIZE=3D2 FACE=3D"Arial">I would be thankful for opinions on = these options.</FONT> </P> <P><FONT SIZE=3D2 FACE=3D"Arial">2. The issue of security:</FONT> <BR><FONT SIZE=3D2 FACE=3D"Arial">In the last IETF meeting the issue of = security was raised again:</FONT> <BR><FONT SIZE=3D2 FACE=3D"Arial">* The protocol should not discuss = tunneling through firewalls</FONT> <BR><FONT SIZE=3D2 FACE=3D"Arial">* The protocol should not use the = standard port of HTTP - but rather register a new one.</FONT> <BR><FONT SIZE=3D2 FACE=3D"Arial">Currently the draft talks about the = different security consideration that the SNAP implementer should take = in consideration. It does not discuss how to overcome these problems - = rather leaves it to be an implementer decision.</FONT></P> <P><FONT SIZE=3D2 FACE=3D"Arial">As far as I can see it - in the next = draft I am going to add a registration for a new port. Does any one = have any objections?</FONT></P> <P><FONT SIZE=3D2 FACE=3D"Arial">After closing the two open issues -I = would like to send the draft for last-call. If there are other open = issues as far as you can see it - please let me know.</FONT></P> <P><FONT SIZE=3D2 FACE=3D"Arial">Thanks</FONT> </P> <P><B><FONT SIZE=3D2 FACE=3D"Comic Sans MS">Noam Shapira</FONT></B> <BR><B><FONT SIZE=3D2 FACE=3D"Comic Sans MS">Notification Group = Leader</FONT></B> <BR><B><FONT SIZE=3D2 FACE=3D"Comic Sans MS">Corporate = Components</FONT></B> <BR><B><FONT SIZE=3D2 FACE=3D"Comic Sans MS">InCom, R&D</FONT></B> <BR><B><FONT SIZE=3D2 FACE=3D"Comic Sans MS">Tel: = 972-3-766-3605</FONT></B> <BR><B><FONT SIZE=3D2 FACE=3D"Comic Sans MS">Mobile: = 972-58-543605</FONT></B> </P> <BR> </BODY> </HTML> ------_=_NextPart_001_01C1FB1D.1D480BAE-- ---------------------------------------------------------- This message was sent to you, since you are subscribed to [email protected]. You can manage your subscription at http://www.neystadt.org/cgi-bin/majordomo