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 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 and 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.