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 protected]
https://www1.ietf.org/mailman/listinfo/gen-art
