Shapira, Noam (Shapira_Noam@icomverse.com)
Mon, 30 Jul 2001 12:58:40 +0300
Hi Eric,
Thanks for your comment. See comments in text:
> -----Original Message-----
> From: Eric Burger [mailto:eburger@snowshore.com]
> Sent: Thursday, July 26, 2001 9:48 PM
> To: snap@lists.neystadt.org
> Cc: Vpim
> Subject: [SNAP] RE: [VPIM] Notification Protocol
>
>
> General:
> 1. I don't see how this is an improvement over
> draft-mahy-sip-message-waiting. Thoughts?
N.S.> I think the model is different. In the sip-message-waiting, the model
is that a user agent subscribers on his messages status. In SNAP, we are
talking about server to server notification on events - where the
notification server is responsible for the decision and pushing of the
notification to the end user. I will try to investigate more and maybe talk
with the author of this draft. If you have more comments on the similarity
it will help.
>
> 2. This looks like a very heavyweight protocol. How is it
> better than IMAP?
N.S.> The IMAP protocol allows a client to access and manipulate email
messages on the ES.
This protocol is used for mail status notification in which an email server
notifies a notification server that changes have occurred in a mailbox
(new message arrived, mailbox is full, etc.). I.e. push to the subscriber
the notification information - rather the subscriber actively
access/manipulates the mailbox.
>
> 3. The security issues can't be understated. At the very
> least, if one uses
> HTTP, one SHOULD use digest authentication. Letting people
> tap into other
> people's mailboxes is not a good idea!
N.S.> As this is a server to server protocol, the security was not
addressed. Basically, the ES sends the information to the notification
server. The protocol does not allow external servers/clients to query the ES
- rather - the ES it self is active in the SNAP session. Between ES and
notification server, I thought that this security issue should be left open
for system configuration - and not restricted by the protocol. Any
suggestions?
>
>
> Specific:
>
>
> Text:
>
> 2.1.3 Persistent Connections
>
> The underlying transport may support sending multiple requests over
> same connection. An example of a such is Keep-Alive header of HTTP.
> The source MAY use transport's means to request persistent
> connection.
>
> The service SHOULD support persistent connections and use them upon
> source requests.
>
> The motivation for this is that Notification Service is assumed to
> be handling big amount of requests and this will optimize
> its operation
> significantly.
>
>
> >>> Given that e-mail updates happen relatively infrequently, and a
> particular server may serve thousands of users, establishing
> TCP connections
> to thousands of users does not sound like particularly good use of
> resources.
N.S.> Maybe it was not clear from the text, the ES does not need to open a
TCP connection per user - rather it should use the same TCP connection for
some users (maybe all users). The proposal allows the ES to open one
connection for all users or a few connection. The notification server should
support more then one connection that is persistent.
>
>
> Text:
>
> 2.2.1 Request Order
>
> The source MUST send the requests in the same order as the events
> that triggered them. This ensures a consistent behavior. For
> example: if there are two notifications, one indicating the
> subscriber has one new message and the second indicating he has
> two new messages, the subscriber must receive the first before the
> second.
>
> >>> The source may send the requests in order. However, THERE IS NO
> GUARANTEE the client will RECEIVE the requests in order. If
> we care about
> order, we need an ordering mechanism in the protocol, such as CallSeq.
N.S.> I agree - there is no guarantee that the end user will receive the
request in order.
A CallSeq / Time stamp might help. I didn't address on the notification
server side as it seemed to be a performance hazard. Any thoughts?
>
>
> Text:
>
> 2.2.3 Response
>
> Upon receiving a request, the service MUST return a response
> including a status code.
>
> The source SHOULD parse the response to retrieve the error code
> and determine success or failure of the request.
>
> >>> Is it the source or the client that parses the error code?
N.S.> Maybe the terminology is confusing - the "Source" - is the ES it sends
the SNAP to the Notification request that returns a response. The source
(ES) should parse the response and decide what to do with the request (for
example - retry to send it to another notification server). In this sense,
the client is the source (ES). In a SNAP session there is no end client
intervention.
>
>
>
> Text:
>
> 2.2.4 Retries
>
> The source SHOULD retry the request in case of failure.
>
> >>> How does the source know there is a failure?
N.S.> The source receives in the response - a 500 error code in the response
- meaning that the notification - didn't functioned and a retry will help.
For example, the Notification server temporarily lost connection with the
DB.
>
>
>
> Text:
>
> 3.5.1 MessageType (M)
>
> The message type can be of the following strings:
> Email, Voice, Fax, Video, Number, EmptyCaptured, VoiceFax
>
> >>> Is this the Message-Context? If so, why not use the values from
> Message-Context? If not, why is DeliveryReportMsg a separate keyword?
N.S.> I agree, this is not the first comment I get on the subject, and I
think I will use a reference to
draft-ietf-vpim-hint-07.txt in the next proposal draft. What do you think?
>
>
> Text:
>
> 3.5.14 Body
>
> The source SHOULD send the body of the MIME message in certain
> request as described later. When doing so, the following apply:
>
> >>> Why would you EVER return the body of a message with
> SNAP? That sounds
> dead wrong. If you want to retrieve the message, use IMAP or POP!
N.S.> The body is not mandatory. The issue is that we would like to give the
notification server maximum information for making decisions about what to
do with the notification request and let the end user get some part of the
body text with the notification he gets (if he wants it).
>
> ----------------------------------------------------------
> This message was sent to you, since you are subscribed to
> > snap@lists.neystadt.org. You can manage your subscription at
> http://www.neystadt.org/cgi-bin/majordomo
>
Thanks,
Noam
This archive was generated by hypermail 2.0b3 on Mon Jul 30 2001 - 12:59:49 IDT