Subject: [Gen-art] Gen-ART Last Call review of draft-ietf-simple-imdn-06

From: Spencer Dawkins <[email-masked]>
Date: Wed, 23 Jan 2008 07:40:31 -0600

Hi, Eric and Hisham,

I have been selected as the General Area Review Team (Gen-ART) reviewer for
this draft (for background on Gen-ART, please see
http://www.alvestrand.no/ietf/gen/art/gen-art-FAQ.html).

Please resolve these comments along with any other Last Call comments you 
may receive.

Document: draft-ietf-simple-imdn-06
Reviewer: Spencer Dawkins
Review Date: 2008-01-22
IETF LC End Date:
2008-01-29
IESG Telechat date: (if known)

Summary: Almost ready for publication as a Proposed Standard, with 
questions.

Comments: This draft is very well-written. I have a number of questions, 
most of which are probably editorial in nature (I'm just making sure).

Abstract

   Instant Messaging (IM) refers to the transfer of messages between
   users in real-time.  This document provides a mechanism whereby
   endpoints can request Instant Message Disposition Notifications
   (IMDN), including delivery, processing, and read notifications, for

Spencer: please feel free to tell me "no", but this specification is very 
careful to distinguish between "rendered" and "read" (to the point of using 
Latin in explaining how "read" doesn't really mean that a user read 
something), so I'm not sure why the notification type is called "read". 
Could this type of notification be more clearly called "rendered"?

   page-mode instant messages.

1.  Introduction

   Message/CPIM [2] is a message format used to generate instant

Spencer (nit): please expand CPIM on first use (yes, this is a message type, 
but CPIM isn't expanded two paragraphs down, either).

   messages.  SIP [8] can carry instant messages generated using
   message/CPIM in SIP MESSAGE requests [9].

   IMDNs include positive delivery, negative delivery (i.e. a message
   did not get delivered successfully), read notifications as well as

Spencer (nit): since "read" is actually past tense here, the sentence might 
be clearer as "read notifications (which notify the sender that an IM 
Receiver has rendered the IM to a user)"...

   processed notifications.  By using CPIM header fields, the IMDN
   request and delivery are abstracted outside the transport protocol
   allowing interoperability between different IM systems.

3.  Terminology

   o  Intermediary: An entity in the network that is on the path of an

Spencer: Is this "An entity in the network that forwards IMs"? as distinct 
from anything that doesn't operate at the SIP/SIMPLE level?

      IM to its final destination.  Intermediaries also can generate and
      send processing IMDNs to IMs, if requested by the IM Sender and
      allowed by policy.

   o  Disposition type: the type of IMDN that can be requested.  This
      specification defines three, namely "delivery", "processing" and
      "read" disposition types.

Spencer (nit): I understand that "three" is correct here, but the 
Introduction breaks out successful and unsuccessful delivery, so it lists 
four notifications, while this definition lists three IMDN types. And then 
Section 5 breaks out all KINDS of notifications. Could these be presented 
consistently?

4.  Overview

   +--------------+                        +--------------+
   |  IM Sender   |                        | IM Recipient |
   |IMDN Recipient|                        | IMDN Sender  |
   +--------------+                        +--------------+
           |                                       |
           |                                       |
           |         1. IM requesting IMDN         |
           |-------------------------------------->|
           |                                       |
           |                                       |
           |         2. IMDN (disposition)         |
           |<--------------------------------------|
           |                                       |
           |                                       |

Spencer (nit): it would be lovely if this diagram was numbered and labeled.

Spencer: It would be double-lovely if there was a corresponding diagram that 
showed an intermediary, either here or (more likely) in Section 8 
("Intermediary Behavior").

   Note that the recipient of an IMDN, in some instances, may not be the
   IM Sender.  This is specifically true for page-mode IMs where the
   Address of Record (AOR) of the IM Sender, that is present in the IM,
   resolves to a different location or user agent than the IM
   originated.  For simplicity, the rest of this document assumes that

Spencer: could this say something like "IMDN delivery to an AOR uses normal 
AOR resolution, which may involve serial or parallel forking to multiple 
UAs, but for simplicity ..."? I think most people would guess the right 
answer, given a moment to think, but ...

   the IM Sender and the IMDN Recipient are the same and therefore will
   refer to both as the IM Sender.

5.  Disposition Types

   There are three broad categories of disposition states.  They are
   delivery, processing, and read.  Future extensions may introduce
   others.

Spencer: note to reviewer - how are extensions identified? :-)

5.3.  Read

   Since there is no positive acknowledgement from the user, one cannot
   determine a priori the user actually read the IM.  Thus, one cannot

Spencer (nit): "Latin as a Second Language (LSL)"...

   use the protocol described here as a non-repudiation service.

6.1.  CPIM Header Field Namespace

   Of course, clients are free to use any prefix and servers must accept

Spencer: is this "intermediaries must accept"? If "servers" and 
"intermediaries" are interchangeable, you might pick one...

   any legal namespace prefix specification.

6.2.  Disposition-Notification

   The IM Sender MUST include the Disposition-Notification header field
   to indicate the desire to receive IMDNs from the IM Recipient, for

Spencer: "MUST include ... if it wishes to receive"? "MUST ... or maybe not" 
in two different sentences seems a little unclear.

   that specific IM.  This header field is not needed if the IM Sender
   does not request an IMDN.  Section 10 defines the syntax.

7.1.4.  Aggregation of IMDNs

   An IM Sender may send an IM to multiple recipients in one Transport
   Protocol Message (typically using a URI-List server) and request

Spencer (nit): suggest reference to [13] for URI-List here.

   IMDNs.  An IM Sender that requested IMDNs MUST be prepared to receive
   multiple aggregated or non-aggregated IMDNs.  See Section 8.2 for
   details.

7.2.1.  Constructing IMDNs

   IM recipients examine the contents of the Disposition-Notification
   header field of the CPIM message to determine if an IMDN must be
   generated for that IM.  Disposition-Notification header fields of

Spencer: I didn't see a description of receiver behavior when a 
Disposition-Notification value isn't known to the receiver - is this just 
"error"? ("is this just obvious to everyone except Spencer"?)

   CPIM messages can include one or more values.  This implies that IM
   recipients may need to generate zero, one, or more IMDNs for that IM,
   for example a delivery notification as well as a read notification.
   In this case, the IM Recipient MUST be able to construct multiple
   IMDNs per IM.  An IM Recipient MUST NOT construct more than one IMDN
   per disposition type.  That is, it must not generate a delivery
   notification indicating "delivered" then followed by a delivery
   notification indicating "failed" for the same IM.  If the IM Sender
   requested only failure notifications and the IM was successfully
   delivered, then no IMDNs will be generated.

   As stated in CPIM [2], CPIM messages may need to support MIME headers
   other than Content-type.

Spencer (nit): I'm not sure what it means for a message to "support" a MIME 
header, but I'm kinda confused about what an implementor does to conform 
with "MIME headers other than Content-type". If it's obvious from [2], fine.

   IM Recipients MUST insert a Content-
   Disposition header field, set to the value "notification".  This
   indicates to the IM Sender that the message is an IMDN to an IM it
   has earlier sent.

7.2.1.2.  Constructing Read Notifications

   There are situations where the IM Recipient cannot determine if or
   when the IM has been read.  The IM Recipient in this case generates a
   read notification with a <status> value of "error" to indicate an
   internal error by the server.  Note that the IM Recipient may choose

Spencer: is "cannot determine if or when the IM has been read" the same as 
"internal error by the server"? The document seems to prefer "cannot 
determine" but uses both more-or-less interchangeably.

   to ignore any IMDN requests and not to send any IMDNs.  An IM
   recipient may not wish to let a sender know she read, or did not
   read, a particular message.  Likewise, she may not want anyone to
   know if she reads messages.  This could be on a per-message, per-
   sender, or programmed policy choice.

8.  Intermediary Behaviour

   In this context, intermediaries are application servers (including
   URI-List servers and Store-and-Forward server) and gateways.  A
   gateway is a server that translates between different IM systems that
   use different protocols.

Spencer: this doesn't seem entirely consistent with previous uses of 
"intermediary" and/or "proxy" (see previous comment asking whether 
"intermediary" and "proxy" were interchangeable). If this is the right 
definition, it would be good to include it in the terminology section.

   A URI-List server may change the IM Recipient address from its own to
   the address of the final recipient of that IM for every copy it makes
   that it sends to the list members (see [13] for details).  In this
   case, if the IM Sender is requesting an IMDN, the intermediary SHOULD

Spencer: is this SHOULD "unless the intermediary has been administratively 
configured not to reveal", etc at the end of the paragraph? It would be nice 
if this conditional was part of the same sentence, if so.

   add an Original-To header field to the IM populating it with the
   address that was in the CPIM To header field before it was changed.
   I.e., the Original-To header field is populated with the intermediary
   address.  An intermediary MUST NOT add an Original-To header field if
   one already exists.  An intermediary MAY have an administrative
   configuration to not reveal the original Request-URI, and as such,
   MAY chose not to add an Original-To header.

   An intermediary receiving an IMDN checks the top IMDN-Route header
   field.  If that header field carries the intermediary address, the
   intermediary removes that value and forwards the IMDN to the address
   indicated in the now top IMDN-Route header field.  If no IMDN-Route

Spencer (nit): s/If no/If no additional/ ?

   header fields are present, the IMDN is forwarded to the address in
   the CPIM To header field.

8.2.  Aggregation of IMDNs

   In this context, URI-List servers are defined as intermediaries.

Spencer: I'm confused here (not sure what "this context" is), but don't 
understand why this choice was made (it's a reasonable choice, but it might 
be worth a sentence to explain).

Spencer: this choice lets you call URI-List servers "intermediaries" in this 
section, but you only do it once (in the next sentence). Could you replace 
"intermediary" with "URI-List server" in the next sentence, just for 
consistency?

   A URI-List server MAY aggregate IMDNs for the case where the list
   membership information is not disclosed.  There may be scenarios
   where the URI-List server starts sending aggregated IMDNs and switch
   to individual ones or visa versa.  A timer firing so often may in
   fact have that effect.

Spencer: does this turn into a requirement that an IMDN receiver should be 
prepared to accept aggregated IMDNs and to accept mixed 
aggregated/non-aggregated IMDNs?

9.  Identifying Messages

   Messages are typically carried in a transport protocol like SIP [8].
   If the payload carried by the transport protocol does not contain any
   parts of type Message/CPIM then the message is an IM.  If the payload
   contains any parts of type Message/CPIM, and none of those parts
   contains a payload that is of type "message/imdn+xml", the message is
   an IM.  It is not valid to attempt to carry both an IM and an IMDN in
   a multipart payload in a single transport protocol message.

Spencer: I'm only asking because BLISS seems to be identifying an unlimited 
number of possible return codes in any situation - do IMDN-capable 
intermediaries and receivers need to check for this condition? If so, do you 
have a suggested return code in mind?

11.1.  Structure of XML-Encoded IMDN Payload

   <disposition> and <status> can be extended in the future to include
   new sub-elements not defined in this document.  Those new elements
   MUST be defined in an RFC.

Spencer: "MUST be defined in an RFC" doesn't match what's in the IANA 
considerations section for imdn ("standards track"), but is probably 
unnecessary here, anyway. I'd delete the last sentence, and instead point to 
the IANA considerations section of this document.

12.1.2.  Sending Responses

   An endpoint receiving a SIP MESSAGE request constructs a SIP response
   according to RFC 3428 [9].  Of course, an endpoint will send a
   response to the MESSAGE request regardless of the type of message (IM

Spencer: s/response/SIP response/?

   or IMDN) is has received, or the disposition type it has been asked
   for.

12.2.  Intermediary Behaviour

   If the Disposition-Notification header field contains a value of
   "positive-delivery", the intermediary MUST NOT generate a delivery
   notification if it receives a SIP 2xx class response for the sent IM.
   This is in anticipation of a failure downstream after a 2xx response
   has been generated.

Spencer: I'm confused. Is this saying "This is to allow an IM recipient to 
report a failure after it has generated a 2XX response"?

13.  Transporting Messages using MSRP

   While MSRP does not provide a built-in Read or Processing
   notification dispositions, those are generally not considered as
   useful information for session IM.  This is because the assumption
   behind MSRP is that SEND requests do not reach a mailbox where
   incoming IMs have to be open, but to an application that renders

Spencer: sorry - don't understand "have to be open" here.

   sequentially those incoming IMs, providing the session experience.
   This kind of applications has no means of identifying when a user has
   read the IM and therefore cannot be useful information for the
   sender.

14.  Security Considerations

   o  A malicious endpoint that attempts to fish for a Request-URI of an

Spencer: "to fish for" is clear to me, but it is slang and may not be clear 
to others. Perhaps "to discover"?

      endpoint beyond an intermediary, where the endpoint would normally
      wish to keep its identity private from the malicious endpoint. 

_______________________________________________
Gen-art mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/gen-art