Eric Burger (eburger@snowshore.com)
Thu, 26 Jul 2001 14:48:27 -0400
General:
1. I don't see how this is an improvement over
draft-mahy-sip-message-waiting. Thoughts?
2. This looks like a very heavyweight protocol. How is it better than IMAP?
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!
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.
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.
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?
Text:
2.2.4 Retries
The source SHOULD retry the request in case of failure.
>>> How does the source know there is a failure?
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?
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!
This archive was generated by hypermail 2.0b3 on Thu Jul 26 2001 - 21:48:31 IDT