Subject: [UM] RE: Comments about draft-shapira-snap-04.txt

From: Decktor Gev <[email-masked]>
Date: Thu, 6 Mar 2003 19:24:42 +0200

> -----Original Message-----
> From: Alexey Melnikov [mailto:[email-masked]]
> Sent: Sunday, February 23, 2003 3:08 PM
> To: Shapira Noam
> Cc: Erev Ari
> Subject: Comments about draft-shapira-snap-04.txt
> 
> 
> Hi,
> I have some comments about draft-shapira-snap-04.txt. If you've
> already fixed them in a new revision, just disregard them.
> 
> Feel free to forward my comments to appropriate mailing lists.
> 
> >2. Basic Operation
> ...
> >
> >   Message Deposit process-  a message is deposited in a user's
> 
> In email world there is common term MDA (Mail Delivery Agent), so you
> should probably use this term instead of inventing a new one.
> 
We would use this term in the next drafts

> >   mailbox. In this case, if the deposit is successful, the Messaging
> >   System will send a "new message" request to the Notification
> >   Service. The request will include partial MIME headers of the
> >   incoming message. If the new message was rejected, the Messaging
> >   System will send a "message reject" request. An example
> of a process
> 
> >   like this is the SMTP process in email servers.
> 
> >2.1 The Transport Layer
> >
> >   The suggested protocol uses HTTP as an underlying transport layer.
> >   The messaging system sends a HTTP request with the POST
> method. The
> >   notification service replies with a HTTP response. A great deal of
> >   thought has been spent on choosing the correct underlying
> transport
> >   protocol. HTTP has been chosen as it is widely deployed
> over the net
> 
> This is a dangerous comment as there is a lot of discussion at IETF
> about "deployed and broken protocol" versa "non deployed and working 
> properly". But more to the point: HTTP uses request/response model, 
> but for SNAP it seems more appropriate to use "Fire-and-forget" model, 
> i.e. a Messaging System should just send the information to 
> Notification Service in the same way "syslog" works. Really, Messaging
> System doesn't care whether the Notification Service received 
> the information and was able to process it.
> 
One of the main reasons the request-response model has been used, was to
increase reliability by allowing a "Store and foreward" like mechanizm. HTTP
seems to be classic for such solution.

> >   and provides the needs of the notification protocol - as described
> >   in section 1.3 in this document.
> 
> ...
> >2.2.4 Retries
> >
> >   Upon receiving a response from the service indicating a
> failure, the
> 
> >   source SHOULD retry the request in case the service failure is
> >   recoverable (i.e. temporary). If the source does not receive a
> response
> >   from the service, it SHOULD retry as well.
> 
> I am not sure how you can deal reasonably with the latter case, thus I
> am not sure why SHOULD is used here.

This wold be changed to "RECOMMENDED"

> 
> >2.2.5 Pipelining
> >
> >   The source SHOULD pipeline requests according to [RFC-HTTP] part
> >   8.1.2.
> 
> Actually, exact section is 8.1.2.2

This would be corrected

> 
> >   If the source pipelines requests, the service SHOULD send
> >   its responses in the same order in which they where received.
> 
> According to HTTP you MUST send responses in the same order. If the
> server would reorder responses, the client will be unable to relate 
> responses to requests, because HTTP doesn't use tags for identifying 
> requests/responses. In section 3.1.7 you propose Request-Id that is 
> used for this purpose, but you still can't change order of responses 
> if you comply with HTTP. So, you either use HTTP (in which case this 
> sentence MUST be dropped), or you clearly say that you are using HTTP
> syntax, but not HTTP semantics.
> 
> Once again, maybe you are using wrong transport protocol and it might
> be better to reuse something existing (e.g. BEEP, which has all you 
> want) or write a simpler protocol specifically designed for your task.
> 

This would be changed to "MUST". Again for reliability reasons I think HTTP
is the right choice.

> >3.4.1 Email-Address (M)
> >
> >   The fully qualified email address for the mailbox.
> 
> There is terminology confusion here.  So for my email address 
> "[email-masked]" and two mailboxes "INBOX" and "Drafts", 
> Email-Address would be the same "[email-masked]" and 
> Mailbox-Name would be "INBOX" or "Drafts" respectively? If the answer 
> is yes, I would suggest to use the term "user" instead of "mailbox" 
> above. A user has an email address and one or more [IMAP] mailboxes
> associated with it.
> 

If Mailbox-Name would have been a mandatory field this would have been
reasonable. however this field may not be sent, causing the notification
service being aware of the Subscriber's identity only by email-address. i
think that for the sake of those cases, Email-Address is a better
description for this field

> >3.5.3 Message-Id
> >
> >   Unique identifier that can be used by the Notification Service or
> >   any other user agent (UA) to retrieve the message. The message id
> >   should comply with [RFC-2822].
> 
> This is very confusing, considering what you write below. Is
> it the value of Message-ID header or IMAP UID?
> 
> Why do you have this as a requirement?

The main purpose was to allow Notifcation end client to be able to retrieve
the message. Obviously in the case of IMAP IMAP uid + UIDVALIDITY would
allow this, however we cant assume the messaging server may not be IMAP4
server. Therefore I think it should be RFC822 message id. Since in the
context of IMAP, IMAP uid + UIDVALIDITY provide a faster way of retrieving
the message, I think a thought should be given to adding these fileds as
additional fields in the next version(such as Imap-Uid, Imap-Uid-Validity).
Another issue we were thinking about is using a URI field, supplied by the
notification source to the service which would provide user an instant
access to the message

> 
> >   The Message-Id MUST persist across
> >   sessions in the source,
> 
> You can't require this, because this can't be guarantied for
> IMAP, for example.

In the context of IMAP that's right. However, as I've mentioned before I
think Message-Id should reffer to RFC822 message-id header
> 
> >   in order to allow the UA to retrieve the
> >   message at any time.
> >
> >   In case where the source is an Email Server, the source
> SHOULD send
> >   the IMAP4 UID [RFC-IMAP4].
> 
> Why SHOULD here? Presumably Notification Service will pass
> this information to some client that is going to use it, so 
> the client must know exactly what format is used. You should 
> add protocol tags here, e.g.
> "Message-Id: IMAP;315@216", or even better, you can use URLs here.
> 
> Regarding IMAP specifically: A message UID is only valid
> while the corresponding mailbox UIDVALIDITY is the same. IMAP 
> server is allowed to change UIDVALIDITY at any time (although 
> this is not recommended). So, in order to uniquely identify a 
> message you MUST include the mailbox UIDVALIDITY value here as well.
> 
I agree. therefore I think that in the case of IMAP email server the source
should send IMAP UID and UIDVALIDITY over additional fields, as I proposed
in my previous remarks
> 
> >3.5.8 Message-Send-Time
> >
> >   The time the message has been sent as described in the message.
> >   This MAY be the value of the Date header as defined in [RFC-2822].
> 
> Why MAY here? Can this value be anything other than the value
> of Date header? If yes, you have to give more details what 
> can be used for this value.

Yes, it can be something else. the messaging system may not be a rfc-2822
complient system (such as voice mail server) and therefore, the notification
service doesn't require the source of this field to be associated with any
header, but requires it to be this specific value(retrieved from headers,
voice mail data, or any other form...)

> 
> >3.5.9 Message-Receive-Time
> >
> >   The time the message was received in the source expressed in GMT.
> >   This MAY be the value of the IMAP4 Internal Date Message Attribute
> >   as defined in [RFC-IMAP4]
> 
> Same as above.

Same as above

> 
> >3.5.10 Message-Size
> >
> >   A number that indicates the message size in bytes. If there are
> >   attachments to the message, the size SHOULD include the size of
> >   the attachments.
> 
> For IMAP message size (i.e. RFC822.SIZE) always includes
> attachments. Why SHOULD here?

Since the notification client may be a messaging server which doesn't
implememnt IMAP-4, this SNAP <--> IMAP-4 association can't be mandatory.(if
its an IMAP server that's correct but than again, it may not be one)

> 
> 
> >3.5.12 Body
> 
> This should probably be moved after 3.5.13.
> I will come back to this when I comment on ABNF.
> 
> >   The source SHOULD send the body of the MIME message in certain
> >   requests as described later. When doing so, the following apply:
> >
> >   The source MUST copy the Content-Type header from the MIME message
> >   to the request header.
> >
> >   The source MUST NOT send the body if the Content-Type is
> not "text".
> 
> >   All text subtypes are allowed.
> >
> >   The source MAY send only part of the body (for example
> the first 100
> 
> >   octets).
> >
> >   The source MUST add a Content-Length header to the request
> >   specifying the size of the body.
> 
> You can add here that Content-Length is required as per HTTP 1.1 spec.

Correct, this would be fixed in the next draft

> 
> >4.1.3 Redirection (3xx) Status Codes
> >
> >4.1.3.1 "301 Moved Permanently"
> >
> >   Upon receiving this status code, the source MUST resend the
> >   notification request to the new URI specified in the location
> >   field of the response.
> >
> >   When sending other requests after receiving this response, the
> >   source SHOULD use the new URL that is part of the URI returned in
> >   the "location" field.
> >
> >4.1.3.2 "307 Temporary Redirect"
> >
> >   Upon receiving this status code, the source MUST resend
> the request
> >   to the new URI specified in the location field of the
> response. The
> >   source MUST NOT change its behavior when sending future requests.
> 
> You have either define own version or URLs here (e.g.
> snap://test.example.com/...) or make say that if
> http URL is used, it MUST include port number, because SNAP
> is not running on the same port as HTTP.
> 

Correct. We certainly want to benefit from the usage of HTTP and therefore
use HTTP URL's. this would be fixed and added in the next draft.

> >5.2.1 General Attribute Syntax
> >
> ...
> >   MessageGroup =
> >     Message-Context
> >     [From]
> >     [To]
> >     [CC]
> >     [Subject]
> >     [Message-Send-Time]
> >     [Message-Receive-Time]
> >     [Message-Size]
> >     [Body]
> >     [Msg-Importance]
> >     [Msg-Sensitivity]
> >     [Message-Id]
> >     [Delivery-Report-Msg]
> 
> ABNF mandate ordering of fields (unless you add a comment 
> saying otherwise). [Body] should be moved to the end, as a 
> server will be unable to parse any attribute specified after 
> [Body]. Also, for the same reason there should be an empty 
> line to delimit Body from the rest. The proposed syntax would 
> be extensible as well.
> 

Correct, this would be fixed in the next draft

> >5.2.3 Attributes
> ...
> >   Message-Size = *DIGITS
> 
> This is wrong as allows for empty string and sequences like 
> 0...0. The correct syntax would be something like:
> 
> NZDIGITS = "1" / "2" / "3" / "4" / "5" / "6" / "7" / "8" / "9"
> DIGITS     = "0" / NZDIGITS
> NZINTEGER = NZDIGITS *DIGITS
> INTEGER = "0" / NZINTEGER
> 
> The same comment applies to all *DIGIST values ("counter" and 
> maybe others).
> 
> the syntax for "percentage" is wrong, but I think most people 
> understand what are you talking about. The correct syntax 
> would be (and you should leave "0".."100" as a
> comment):
> 
> percent = "0" / (NZDIGITS DIGITS) / ("1" 2*DIGITS)
> 

Correct, this would be fixed in the next draft

> >5.3 Response Syntax
> >
> >   Response = 1Status-Line *1Request-Id-Line *1Description-Line
> 
> This doesn't seem right, what exactly you are trying to say?

This is a private case of the general response definition in HTTP protocol
(section 6), when request-id line and description line would be considered
as Entity-Header fields.
> 
> >5.4 Examples:
> >
> >   Request example:
> >
> > POST /Notification-Service/notif.cgi HTTP/1.1    ;The URI
> 
> How does the client knows what URL to specify in the request? 
> This is not described anywhere in the document. If the 
> request URL is irrelevant, please say so.
> 

The request URL in this example is arbitrary. This is only an example. We
would add a remark in the next draft which would state that this URL isn't
obligatory.

> >        Content-Type: text/SNAP;                         ;From HTTP
> >        charset="utf-8"                                  ;From HTTP
> >        Content-Length: nnnn                             ;From HTTP
> >
> >        Notification-Protocol-Version:1.1
> >        Application-Name:Applic
> >        Application-Version:1.0
> >        Server-Type:Email
> >        Request-Type:New-Msg
> >        Request-Time:15Feb2000%2012:02:00%20+0000
> 
> Why are you encoding spaces? I don't think this is described in ABNF.

Your are right. This would be removed in the next version of the draft

> 
> >        Request-Id:9941401AA
> >        Message-Context:text-message                   
> ;Indicate email
> >        Message-Id:9999
> >        Email-Address:[email-masked]
> >        Server-Name:ES1
> >        Total-Email-Message:20
> >        Total-New-Email-Message:20
> >        Message-Send-Time:15Feb2000%2012:02:00%20+0000
> >        Message-Receive-Time:15Feb2000%2012:02:00%20+0000
> >        Message-Size:20000
> >        Msg-Importance:high
> >        From:[email-masked]
> >        To:[email-masked]
> >        Subject:Hello%20Joe
> 
>     Response example (1):
> >      HTTP/1.1 200 OK CRLF
> 
> Some mandatory HTTP headers are missing.

I'm not sure I know to which Headers u refer to. If your are refering to
Content-Type and/Or Content-Length, they would be added in the next draft's
example.
> 
> >      Request Id: 9941401AA CRLF
> 
> Typo: Should be Request-Id

This has already been fixed in Draft 5.

> 
> >      Request processed successfully CRLF
> 
> Here you use CRLF convention. I suggest you just add empty lines as
> appropriate:

You are right. We will use a consistent notations in the next draft's
examples. (either CRLF or emty lines, but in a consistent way throughout the
entire draft)
> 
>     Response example (1):
>       HTTP/1.1 200 OK
>       Content-Type: text/SNAP;                         ;From HTTP
>       charset="utf-8"                                  ;From HTTP
>       Content-Length: mmm                             ;From HTTP
> 
>       Request-Id: 9941401AA
>       Request processed successfully
> 
> >6.3 Impersonation
> >
> >   A Messaging System impersonation might cause the Notification
> >   Service to send notification messages on events that did 
> not occur.
> 
> This is why you need authentication. This is not going to be 
> good enough for IESG.
> 
This is one of the main issues raised towards the mailing list. we do intend
of dealing more seriously with the security aspect.

> >6.4 Network Snooping
> >
> >   Packet sniffing on the SNAP payload may impose a threat on the
> >   user's privacy. The SNAP's payload SHOULD be secured in order to
> >   prevent network snooping.
> 
> You have to give some indication how the payload can be 
> secured, otherwise your SHOULD is meaningless.

Once again, currently SNAP doesn't deal intesively with security issues. We
hope to add this aspects

> 
> > 7. IANA Considerations
> ...
> >     Author/Change controller:
> >
> >       [email-masked]
> 
> Usually author is you, and Change controller is IESG. This is 
> for a case when you can't be contacted.

This would be fixed in the next draft
> 
> >8. References
> 
> As per new IESG requirements this has to be split into to 
> parts: normative references (i.e. "required to implement") 
> and informative references.
> 
> P.S. I hope that my comments don't discourage you, as I think 
> it is a good start.
> 
> Best Regards,
> Alexey Melnikov
> __________________________________________
> R & D, ACI Worldwide/MessagingDirect
> Watford, UK
> 
> Work Phone: +44 1923 81 2877
> Home Page: http://orthanc.ab.ca/mel
> 
> I speak for myself only, not for my employer. 
> __________________________________________
> 
> 
> 
>

---

From: Shapira Noam <[email-masked]>
Date: Thu, 6 Mar 2003 19:31:46 +0200

-----Original Message-----
From: Decktor Gev 
Sent: Thursday, March 06, 2003 7:25 PM
To: [email-masked]'
Cc: Erev Ari; Shapira Noam
Subject: RE: Comments about draft-shapira-snap-04.txt

> System doesn't care whether the Notification Service received the 
> information and was able to process it.
> 

This would be corrected

Same as above