RE: [SNAP] SNAP - last changes
Shapira, Noam <Shapira_Noam <at> icomverse.com>
2002-05-15 10:59:25 GMT
> -----Original Message-----
> From: Sergio Freire [mailto:est-s-freire <at> ptinovacao.pt]
> Sent: Tuesday, May 14, 2002 11:55 AM
> To: Shapira, Noam
> Cc: snap <at> lists.neystadt.org; vpim <at> lists.neystadt.org; Mario Moreira
> Subject: Re: [SNAP] SNAP - last changes
> Hi Shaphira, hi all,
> About the issues that you mention,
> 1. In fact these two fields in most cases won't be needed
> although they
> might be of some use..
> 2. About the port used by SNAP, well in my opinion it shouldn't be
> specificied by the draft. It should be a
> developer/implementation issue.
> The Notification Server is suposed to run under a restricted
> LAN, so why
> is the port number an issue ?
> Asssigning a specific port adds some contraint to the draft.
> SNAP should
> care with the protocol itself, the syntax and not with the
> port because
> its suposed to run anywhere. For example, you might see it
> running it on
> 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.
> Another remarks:
> a) Message-Context predefined values aren't of too much
> sense, if for
> VOICE and FAX you get a Message-Context of "voice-message" and
> "fax-message", why shouldn't likely get a "email-message" for
> the type
> EMAIL ?
The different values are taken from VPIM working group draft - draft-ietf-vpim-hint-07 - and I tried to stay with this standard.
> b) In Counters-Group, section 3.6.1, 3.6.2 and 3.6.3
> shouldn't they be
> "Total-Voice-Message", "Total-New-Voice-Message" and
> "Total-New-Urgent-Voice-Message" ? Since all other counter fields are
> like "Total-xxx-Message", why is this one "Total-xxx-Messages" ?
I agree - it will be fixed.
> c) Shouldn't there exist counters for the total of messages,
> all types ? Something like "Total-Message", "Total-New-Message" and
> "Total-New-Urgent-Message" ?
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
> delivery ? There could be a Request-Type like "New-Rule"
> which had all
> fields necessary for the Nonfiction Server to process and
> know if it has
> to deliver it, how and when ? I can give a contribution on
> 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.
> Sergio Freire
> Services and Mobile Networks
> PT Inovação
> Portugal Telecom
> Shapira, Noam wrote:
> > 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
> > (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_
> > 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
> > 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
> > 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*