RE: [SNAP] SNAP - last changes
"Shapira, Noam" <[email protected]> Wed, 15 May 2002 13:59:25 +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_01C1FBFF.9351BF88 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi Sergio, See inside > -----Original Message----- > From: Sergio Freire [mailto:[email protected]]=20 > Sent: Tuesday, May 14, 2002 11:55 AM > To: Shapira, Noam > Cc: [email protected]; [email protected]; Mario Moreira > Subject: Re: [SNAP] SNAP - last changes >=20 >=20 > Hi Shaphira, hi all, > About the issues that you mention, >=20 > 1. In fact these two fields in most cases won't be needed=20 > although they=20 > might be of some use.. >=20 > 2. About the port used by SNAP, well in my opinion it shouldn't be=20 > specificied by the draft. It should be a=20 > developer/implementation issue.=20 > The Notification Server is suposed to run under a restricted=20 > LAN, so why=20 > is the port number an issue ? > Asssigning a specific port adds some contraint to the draft.=20 > SNAP should=20 > care with the protocol itself, the syntax and not with the=20 > port because=20 > its suposed to run anywhere. For example, you might see it=20 > running it on=20 > HTTP port 80 in most of the cases. I tend to disagree with you - One of the comments that I got in the = last IETF meeting was that we should not use the standard (80) port for the protocol. This is a security hazard and will not allow firewalls to = monitor the incoming SNAP requests. >=20 > Another remarks: > a) Message-Context predefined values aren't of too much=20 > sense, if for=20 > VOICE and FAX you get a Message-Context of "voice-message" and=20 > "fax-message", why shouldn't likely get a "email-message" for=20 > the type=20 > EMAIL ? The different values are taken from VPIM working group draft - draft-ietf-vpim-hint-07 - and I tried to stay with this standard. >=20 > b) In Counters-Group, section 3.6.1, 3.6.2 and 3.6.3=20 > shouldn't they be=20 > "Total-Voice-Message", "Total-New-Voice-Message" and=20 > "Total-New-Urgent-Voice-Message" ? Since all other counter fields are = > like "Total-xxx-Message", why is this one "Total-xxx-Messages" ? >=20 I agree - it will be fixed. > c) Shouldn't there exist counters for the total of messages,=20 > including=20 > all types ? Something like "Total-Message", "Total-New-Message" and=20 > "Total-New-Urgent-Message" ? >=20 I think this information can be derived from the other counters and therefore not needed. Why do you think it is needed? > d) Shouldn't there be a Request-Type specifying rules for=20 > notification=20 > delivery ? There could be a Request-Type like "New-Rule"=20 > which had all=20 > fields necessary for the Nonfiction Server to process and=20 > know if it has=20 > to deliver it, how and when ? I can give a contribution on=20 > this matter... This protocol is between an email server and a notification server. = What you are saying is that the rule will be sent from the email server - which = I think is wrong architecturally. If you are talking about provisioning = of this service - this issue has been raised before and we (in the mailing list) decided not to tackle the problem in the draft. I think it is a = good idea to have complimentary RFC that will talk about the provisioning of = this service. >=20 > Regards, >=20 > Sergio Freire > Services and Mobile Networks > PT Inova=E7=E3o > Portugal Telecom >=20 > Shapira, Noam wrote: >=20 > > 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=20 > associate=20 > > (Eli Jacobi) in the last IETF meeting (IETF #53). The=20 > changes can be=20 > > found in the appendix to the draft (that can be found in_=20 > >=20 > __<__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 -=20 > 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=20 > implementation > > instruction to the email server developer or should we keep it open = > > (for implementation decision)? > > > > * If we provide implementation instruction - should it be=20 > 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=20 > consideration=20 > > that the SNAP implementer should take in consideration. It does not = > > discuss how to overcome these problems - rather leaves it to be an=20 > > 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=20 > draft for > > last-call. If there are other open issues as far as you can=20 > see it -=20 > > please let me know. > > > > Thanks > > > > *Noam Shapira* > > *Notification Group Leader* > > *Corporate Components* > > *InCom, R&D* > > *Tel: 972-3-766-3605* > > *Mobile: 972-58-543605* > > > > >=20 >=20 >=20 ------_=_NextPart_001_01C1FBFF.9351BF88 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>RE: [SNAP] SNAP - last changes</TITLE> </HEAD> <BODY> <P><FONT SIZE=3D2>Hi Sergio,</FONT> </P> <P><FONT SIZE=3D2>See inside</FONT> </P> <P><FONT SIZE=3D2>> -----Original Message-----</FONT> <BR><FONT SIZE=3D2>> From: Sergio Freire [<A = HREF=3D"mailto:[email protected]">mailto:est-s-freire@ptinovaca= o.pt</A>] </FONT> <BR><FONT SIZE=3D2>> Sent: Tuesday, May 14, 2002 11:55 AM</FONT> <BR><FONT SIZE=3D2>> To: Shapira, Noam</FONT> <BR><FONT SIZE=3D2>> Cc: [email protected]; = [email protected]; Mario Moreira</FONT> <BR><FONT SIZE=3D2>> Subject: Re: [SNAP] SNAP - last changes</FONT> <BR><FONT SIZE=3D2>> </FONT> <BR><FONT SIZE=3D2>> </FONT> <BR><FONT SIZE=3D2>> Hi Shaphira, hi all,</FONT> <BR><FONT SIZE=3D2>> About the issues that you mention,</FONT> <BR><FONT SIZE=3D2>> </FONT> <BR><FONT SIZE=3D2>> 1. In fact these two fields in most cases won't = be needed </FONT> <BR><FONT SIZE=3D2>> although they </FONT> <BR><FONT SIZE=3D2>> might be of some use..</FONT> <BR><FONT SIZE=3D2>> </FONT> <BR><FONT SIZE=3D2>> 2. About the port used by SNAP, well in my = opinion it shouldn't be </FONT> <BR><FONT SIZE=3D2>> specificied by the draft. It should be a = </FONT> <BR><FONT SIZE=3D2>> developer/implementation issue. </FONT> <BR><FONT SIZE=3D2>> The Notification Server is suposed to run under = a restricted </FONT> <BR><FONT SIZE=3D2>> LAN, so why </FONT> <BR><FONT SIZE=3D2>> is the port number an issue ?</FONT> <BR><FONT SIZE=3D2>> Asssigning a specific port adds some contraint = to the draft. </FONT> <BR><FONT SIZE=3D2>> SNAP should </FONT> <BR><FONT SIZE=3D2>> care with the protocol itself, the syntax and = not with the </FONT> <BR><FONT SIZE=3D2>> port because </FONT> <BR><FONT SIZE=3D2>> its suposed to run anywhere. For example, you = might see it </FONT> <BR><FONT SIZE=3D2>> running it on </FONT> <BR><FONT SIZE=3D2>> HTTP port 80 in most of the cases.</FONT> <BR><FONT SIZE=3D2>I tend to disagree with you - One of the comments = that I got in the last IETF meeting was that we should not use the = standard (80) port for the protocol. This is a security hazard and will = not allow firewalls to monitor the incoming SNAP requests.</FONT></P> <P><FONT SIZE=3D2>> </FONT> <BR><FONT SIZE=3D2>> Another remarks:</FONT> <BR><FONT SIZE=3D2>> a) Message-Context predefined values aren't of = too much </FONT> <BR><FONT SIZE=3D2>> sense, if for </FONT> <BR><FONT SIZE=3D2>> VOICE and FAX you get a Message-Context of = "voice-message" and </FONT> <BR><FONT SIZE=3D2>> "fax-message", why shouldn't likely = get a "email-message" for </FONT> <BR><FONT SIZE=3D2>> the type </FONT> <BR><FONT SIZE=3D2>> EMAIL ?</FONT> <BR><FONT SIZE=3D2>The different values are taken from VPIM working = group draft - draft-ietf-vpim-hint-07 - and I tried to stay with this = standard.</FONT></P> <P><FONT SIZE=3D2>> </FONT> <BR><FONT SIZE=3D2>> b) In Counters-Group, section 3.6.1, 3.6.2 and = 3.6.3 </FONT> <BR><FONT SIZE=3D2>> shouldn't they be </FONT> <BR><FONT SIZE=3D2>> "Total-Voice-Message", = "Total-New-Voice-Message" and </FONT> <BR><FONT SIZE=3D2>> "Total-New-Urgent-Voice-Message" ? = Since all other counter fields are </FONT> <BR><FONT SIZE=3D2>> like "Total-xxx-Message", why is this = one "Total-xxx-Messages" ?</FONT> <BR><FONT SIZE=3D2>> </FONT> <BR><FONT SIZE=3D2>I agree - it will be fixed.</FONT> </P> <P><FONT SIZE=3D2>> c) Shouldn't there exist counters for the total = of messages, </FONT> <BR><FONT SIZE=3D2>> including </FONT> <BR><FONT SIZE=3D2>> all types ? Something like = "Total-Message", "Total-New-Message" and </FONT> <BR><FONT SIZE=3D2>> "Total-New-Urgent-Message" ?</FONT> <BR><FONT SIZE=3D2>> </FONT> <BR><FONT SIZE=3D2>I think this information can be derived from the = other counters and therefore not needed. Why do you think it is = needed?</FONT></P> <P><FONT SIZE=3D2>> d) Shouldn't there be a Request-Type specifying = rules for </FONT> <BR><FONT SIZE=3D2>> notification </FONT> <BR><FONT SIZE=3D2>> delivery ? There could be a Request-Type like = "New-Rule" </FONT> <BR><FONT SIZE=3D2>> which had all </FONT> <BR><FONT SIZE=3D2>> fields necessary for the Nonfiction Server to = process and </FONT> <BR><FONT SIZE=3D2>> know if it has </FONT> <BR><FONT SIZE=3D2>> to deliver it, how and when ? I can give a = contribution on </FONT> <BR><FONT SIZE=3D2>> this matter...</FONT> <BR><FONT SIZE=3D2>This protocol is between an email server and a = notification server. What you are saying is that the rule will be sent = from the email server - which I think is wrong architecturally. If you = are talking about provisioning of this service - this issue has been = raised before and we (in the mailing list) decided not to tackle the = problem in the draft. I think it is a good idea to have complimentary = RFC that will talk about the provisioning of this service.</FONT></P> <P><FONT SIZE=3D2>> </FONT> <BR><FONT SIZE=3D2>> Regards,</FONT> <BR><FONT SIZE=3D2>> </FONT> <BR><FONT SIZE=3D2>> Sergio Freire</FONT> <BR><FONT SIZE=3D2>> Services and Mobile Networks</FONT> <BR><FONT SIZE=3D2>> PT Inova=E7=E3o</FONT> <BR><FONT SIZE=3D2>> Portugal Telecom</FONT> <BR><FONT SIZE=3D2>> </FONT> <BR><FONT SIZE=3D2>> Shapira, Noam wrote:</FONT> <BR><FONT SIZE=3D2>> </FONT> <BR><FONT SIZE=3D2>> > Hi all,</FONT> <BR><FONT SIZE=3D2>> ></FONT> <BR><FONT SIZE=3D2>> > The SNAP protocol draft is in it's final = stages. The last draft has</FONT> <BR><FONT SIZE=3D2>> > been sent on February and the changes were = presented by my </FONT> <BR><FONT SIZE=3D2>> associate </FONT> <BR><FONT SIZE=3D2>> > (Eli Jacobi) in the last IETF meeting = (IETF #53). The </FONT> <BR><FONT SIZE=3D2>> changes can be </FONT> <BR><FONT SIZE=3D2>> > found in the appendix to the draft (that = can be found in_ </FONT> <BR><FONT SIZE=3D2>> > </FONT> <BR><FONT SIZE=3D2>> __<__<A = HREF=3D"http://www.ietf.org/internet-drafts/draft-shapira-snap-03" = TARGET=3D"_blank">http://www.ietf.org/internet-drafts/draft-shapira-snap= -03</A></FONT> <BR><FONT SIZE=3D2>> .txt__>_).</FONT> <BR><FONT SIZE=3D2>> ></FONT> <BR><FONT SIZE=3D2>> > There are currently two main open = issues:</FONT> <BR><FONT SIZE=3D2>> ></FONT> <BR><FONT SIZE=3D2>> > 1. The issue of attachment name and = number:</FONT> <BR><FONT SIZE=3D2>> > * Should it be in SNAP? Currently, in our = implementation - </FONT> <BR><FONT SIZE=3D2>> we are not</FONT> <BR><FONT SIZE=3D2>> > using it - but as far as I can see it - it = might be needed later on.</FONT> <BR><FONT SIZE=3D2>> ></FONT> <BR><FONT SIZE=3D2>> > * If it should be in SNAP - should we add = to the draft </FONT> <BR><FONT SIZE=3D2>> implementation</FONT> <BR><FONT SIZE=3D2>> > instruction to the email server developer = or should we keep it open </FONT> <BR><FONT SIZE=3D2>> > (for implementation decision)?</FONT> <BR><FONT SIZE=3D2>> ></FONT> <BR><FONT SIZE=3D2>> > * If we provide implementation instruction = - should it be </FONT> <BR><FONT SIZE=3D2>> according to</FONT> <BR><FONT SIZE=3D2>> > content-disposition header (as I suggested = before) or perhaps using </FONT> <BR><FONT SIZE=3D2>> > the body-structure.</FONT> <BR><FONT SIZE=3D2>> ></FONT> <BR><FONT SIZE=3D2>> > I would be thankful for opinions on these = options.</FONT> <BR><FONT SIZE=3D2>> ></FONT> <BR><FONT SIZE=3D2>> > 2. The issue of security:</FONT> <BR><FONT SIZE=3D2>> > In the last IETF meeting the issue of = security was raised again:</FONT> <BR><FONT SIZE=3D2>> > * The protocol should not discuss = tunneling through firewalls</FONT> <BR><FONT SIZE=3D2>> > * The protocol should not use the standard = port of HTTP - but rather</FONT> <BR><FONT SIZE=3D2>> > register a new one.</FONT> <BR><FONT SIZE=3D2>> > Currently the draft talks about the = different security </FONT> <BR><FONT SIZE=3D2>> consideration </FONT> <BR><FONT SIZE=3D2>> > that the SNAP implementer should take in = consideration. It does not </FONT> <BR><FONT SIZE=3D2>> > discuss how to overcome these problems - = rather leaves it to be an </FONT> <BR><FONT SIZE=3D2>> > implementer decision.</FONT> <BR><FONT SIZE=3D2>> ></FONT> <BR><FONT SIZE=3D2>> > As far as I can see it - in the next draft = I am going to add a</FONT> <BR><FONT SIZE=3D2>> > registration for a new port. Does any one = have any objections?</FONT> <BR><FONT SIZE=3D2>> ></FONT> <BR><FONT SIZE=3D2>> > After closing the two open issues -I would = like to send the </FONT> <BR><FONT SIZE=3D2>> draft for</FONT> <BR><FONT SIZE=3D2>> > last-call. If there are other open issues = as far as you can </FONT> <BR><FONT SIZE=3D2>> see it - </FONT> <BR><FONT SIZE=3D2>> > please let me know.</FONT> <BR><FONT SIZE=3D2>> ></FONT> <BR><FONT SIZE=3D2>> > Thanks</FONT> <BR><FONT SIZE=3D2>> ></FONT> <BR><FONT SIZE=3D2>> > *Noam Shapira*</FONT> <BR><FONT SIZE=3D2>> > *Notification Group Leader*</FONT> <BR><FONT SIZE=3D2>> > *Corporate Components*</FONT> <BR><FONT SIZE=3D2>> > *InCom, R&D*</FONT> <BR><FONT SIZE=3D2>> > *Tel: 972-3-766-3605*</FONT> <BR><FONT SIZE=3D2>> > *Mobile: 972-58-543605*</FONT> <BR><FONT SIZE=3D2>> ></FONT> <BR><FONT SIZE=3D2>> ></FONT> <BR><FONT SIZE=3D2>> </FONT> <BR><FONT SIZE=3D2>> </FONT> <BR><FONT SIZE=3D2>> </FONT> </P> </BODY> </HTML> ------_=_NextPart_001_01C1FBFF.9351BF88-- ---------------------------------------------------------- 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