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

[Eric Burger <[e-mail]>]

Inline.   Sorry for the delay.


On 1/23/08 8:40 AM, "Spencer Dawkins" <[e-mail]> wrote:

> 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"?

"No."  Not because "read" is special, but because it is what is out there,
and users never see this state indicator.  And, because I'm too harried to
edit the entire document, missing 3 places where it should be rendered and
incorrectly changing 5 places where it should remain read.
 
> 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).

Done

>    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)"...

MDNs include positive delivery, negative delivery (i.e., a message did not
get delivered successfully), read notifications (i.e., a message was
rendered) as well as 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?

Done.  Took "forwards" langague.

>       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?

Got text?  Does it matter?  I'm in the "it doesn't matter, except for a
symmetry that isn't there" camp.

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

Done.  I love xml2rfc :-)

> 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").

Not done.  Let's leave that for the PS revision :-))

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

Done.

>    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? :-)

Done.  Just say No.  Non sequitur.

> 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)"...

:-)  In the HTML version you get italic :))

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

Too tired to do the write thing [sic].  How about:
Of course, clients are free to use any prefix while servers and
intermediaries must accept 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.

Deleted superfluous sentence.

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

Done.

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

How about:
IM recipients examine the contents of the Disposition-Notification header
field of the CPIM message to determine if the recpient needs to generate an
IMDN for that IM. Disposition-Notification header fields of CPIM messages
can include one or more values. 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. If the IM recipient does not understand a value of the
Disposition-Notification header field, the IM recipient ignores that value.

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

It should be.

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

Partially that is because there are non-error cases when the server cannot
determine if the message has been read, and there are error cases.  It
really doesn't matter - we just report that we could not report.

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

This is the only time the word proxy (actually, proxies) appears in the
entire document.  Added Gateway to the terminology section.  Expanded
Intermediary 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.

Done

>    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/ ?
Done
 
> 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?

Done.

>    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?

Already there, 7.1.4
 
> 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?

Nope.

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

Done

> 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/?

Done
 
> 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"?

f 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. Just
because a downstream entitiy received a MESSAGE request does not mean the
message was relayed to its ultimate destination or was delivered. Thus, the
intermediary cannot say delivery occured just because it received 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.

MSRP already provides a built-in mechanism to supply positive and negative
delivery reports. These reports do not provide built-in Read or Processing
notifications. However, these notifications in session mode are not as
useful as they are for page-mode. This is because the base use case for MSRP
is that the recipient user agent immediately renders SEND requests
sequentially, providing the session experience. This is unlike page-mode
requests where a user has to actively read the message. That is, they need
to click on a button, open a message, and so on to read the message.

If new requirements arise in the future determining the need for IMDN in
MSRP, new specifications can be drafted.
 
> 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"?

Done.


Notice:  This email message, together with any attachments, may contain information  of  BEA Systems,  Inc.,  its subsidiaries  and  affiliated entities,  that may be confidential,  proprietary,  copyrighted  and/or legally privileged, and is intended solely for the use of the individual or entity named in this message. If you are not the intended recipient, and have received this message in error, please immediately return this by email and then delete it.
_______________________________________________
Gen-art mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/gen-art