Instant Message Disposition Notification (IMDN)
draft-ietf-simple-imdn-10

[Ballot discuss]
Version -09 addresses most of my concerns, with one exception:

"The document needs a better explanation of why (the rather ugly)
IMDN-Record-Route/IMDN-Route mechanism is needed (especially since
there's no similar mechanism for sending normal IM replies)."

In other words: why it's necessary or useful to ensure that certain
intermediaries see the IMDN, if it's not necessary for normal IM
replies? (this has probably been discussed on the mailing list at some
point during the draft's lifetime, but I'd like to see the explanation
in the document itself.)

Version -09 also changed the syntax of the Disposition-Notification
header (it now requires spaces on both side of commas and semicolons)
-- is this intentional? (if it is, the example in Section 7.1.1.3 is
not valid any more). Also, RFC 2434 has been obsoleted by RFC 5226.

[Ballot discuss]
1. I could not find a response to Frank Ellermann's last call comments
on "Wed, 16 Jan 2008 12:17:48 +0100" to the IETF mailing list.  I do not
consider it acceptable to simply ignore last call comments.  Please cc
me on any correspondence to Frank and the ietf list on this issue.  Most
of the issues he raised I consider discuss-level issues.

2. The "read" status is misleading for the reasons 3798 describes.  Why
did you choose not to use "displayed" as defined in RFC 3798?  Having
semantically misleading statements in protocols is simply not good
design and I'd like a justification for doing something different from
the previous IETF draft standard in this area.

3. This appears to combine DSN (RFC 3464) and MDN (RFC 3798) features
into one protocol.  As they are related and the primary reason for the
specification split is historic, I think combining the features is a
good thing.  But there are semantic differences between the two
protocols that are both useful and important.  In particular, when a
client requests a DSN it is guaranteed to get a response by RFC 3461,
while responses to MDNs are optional.  This is a very useful property
although it is only possible if the "relayed" action from RFC 3464 is
included in the model and generated in response to a request for
delivery success status.  Why did you choose not to provide this feature
of DSNs?  If the WG considered this and made a willful decision, I'm not
going to insist on a change, but I at least want to understand why the
IETF suite of standards will be inconsistent on such an important semantic.

5. I could find no record of the IETF-types review in the IETF-types
archives:
http://www.alvestrand.no/pipermail/ietf-types/2007-February/thread.html
Can someone please provide a copy of the review request as received from
the ietf-types list expander?  I want to make sure the message was
actually distributed to the list and not lost in transit.

6. RFC 3862 has an example message with the same subject in two
different languages.  How does the  element handle this in the
IMDN?  Is a lang parameter included on the subject typically?

7. When using a formal schema language, it is important to say in the
specification how it relates normatively to this document and future
extensions.  Is the schema a normative definition of the current format?
Is the schema a normative definition constraining all future extensions
of the format?  If the answer to the latter question is "yes", then I
recommend you read chapter 12 of "Relax NG" by Eric van der Vlist and
revise your Relax NG schema accordingly or you will be painting yourself
in a box.  Briefly: you should use the interleave pattern, I'm not sure
your 'anyIMDI' is correct (see "anything" in the book) and if you put
the addition of 'anyIMDI' in a separate define from the list of
pre-defined elements that will simplify extending the schema.  BTW,
thanks for using RelaxNG as it's much simpler to read and review than
W3C schema.

8. Section 15.4 says both "Specification Required" and "IETF Standards
track" (implying it's a "standards action" registry).  What is the
intended registry type?

9. Have all the questions IANA asked been resolved?

Note: I have deliberately not reviewed the security considerations
section assuming the security directoriate and ADs have that covered.

[Ballot comment]
Jon convinced me to make this a comment rather than a discuss position.  Partly because this fits in the model put forward by CPIM:

4. The decision to mix transitive routing information
(IMDN-Record-Route, IMDN-Route) into the IMDN content itself is bad
design, especially when that information is to be removed by
intermediaries. That makes any sort of content based signature
impossible, and such mechanisms are likely to become an important part
of the necessary reputation systems as the volume of IM spam increases
over time.

[Ballot discuss]
Process note: Eric Rescorla's SecDir review needs a response.

Note a single one of the XML examples is actually valid according
to the RelaxNG schema (they have things like misspelled attribute
names, missing required elements, etc.).

The document needs a better explanation of why (the rather ugly)
IMDN-Record-Route/IMDN-Route mechanism is needed (especially since
there's no similar mechanism for sending normal IM replies).

The RelaxNG schema has an "Extension" element, but there's no text
describing how the extension mechanism works. Also, the statement in
15.3 saying "Extensions MUST be standards track documents" isn't
very clear.

Sections 15.2 and 15.3 attempt to register the same URI for two
purposes; please clarify.

Section 15.4 says "Additional values may be defined by standards
track RFCs that update or obsolete RFC XXXX (Specification Required)";
please make this clearer.

From Eric Rescorla's SecDir review:

One thing I'm not clear on is how the recipient determines where to
send the IMDN. Are they supposed to read the "From" field? One thing
that I don't get is how the IMDN-Route header interacts here.
It looks to me like this gets stuffed in the "To" in the IMDN.
What happens if someone puts an IMDN-Record-Route that points
to an IMDN-ignorant UA?

I'm concerned about the bounce/reflection threats discussed in S14
(where the sender asks for notification to a third party victim). 
I'm particularly concerned about the "note" field, since a natural
implementation seems to be to include an excerpt from the message
you're acknowledging.  This draft identifies the threat but doesn't
specify any mechanism for ameliorating them. I think some suggested
mechanisms would be appoprirate here, or at least some analysis of
what the potential mechanisms were and why they would or would not
work.

5.3/14.3: I would avoid the term "non-repudiation" if at all possible
-- it's so overloaded that it's hard to know what it means (if
anything).  Something like "Thus, the protocol described here does not
provide reliable evidence of receipt for, e.g., legal purposes" could
be clearer.

[Ballot comment]
Section 5.3., paragraph 2:
>    In addition to text, some IMs may contain audio, video, and still
>    images.  Therefore, the state "read" includes playing the audio or
>    video file to the user.

  Does it indicate the start of playback, or when playback has
  concluded? (Probably the former, but it might be good to be explicit
  in the text.)


Section 5.3., paragraph 3:
>    Since there is no positive acknowledgement from the user, one cannot
>    determine _a priori_ the user actually read the IM.  Thus, one cannot
>    use the protocol described here as a non-repudiation service.

  That restriction - that getting a "read" IMDN doesn't actually mean
  that the recipient is guaranteed to have read the IM - seems important
  enough to describe more prominently, e.g., in the introduction. "Read"
  is maybe also a bit inaccurate, maybe "rendered" would be a better
  term, i.e., the IM has been rendered to the user, which is about as
  much as a program can guarantee it did. It's probably too late to make
  this wording change, but an explanation can still be added. (Nit: I
  don't understand what "a priori" is supposed to express in this
  sentence.)


Section 7.1.1.1., paragraph 1:
>    The Message-ID field is populated
>    with a value that is unique with at least 32 bits of randomness.

  Nit: It's not unique, it's _statistically_ unique.


Section 7.1.3., paragraph 2:
>    Once an IM Sender sends an IM containing an IMDN request, it MAY
>    preserve the IM context, principally the Message-ID, and other user-
>    identifiable information such as the IM subject or content, and date
>    and time it was sent.

  Isn't a MAY a bit weak? Requesting IMDNs when I'm not going to be able
  to correlate them to specific sent messages seems to be pretty
  pointless.


Section 12.1.1., paragraph 4:
>    An IM Recipient can ignore such request
>    if the IM Sender is anonymous.

  Nit: s/can/MAY/


Section 13., paragraph 1:
>    MSRP already provides a built-in mechanism to supply positive and
>    negative delivery reports.

  Reference to MSRP missing.


Section 14., paragraph 1:
>    IMDNs provide a fine-grained view of the activity of the IM Recipient
>    and thus deserves particularly careful confidentiality protection so
>    that only the intended recipient of the IMDN will receive the IMDN.
>    In most cases, the intended recipient of the IMDN is the IM Sender.

  When the IMDN recipient isn't the sender but instead the IMDN is
  addressed to multiple recipients, an amplification attack can be
  performed. Is this a new threat with IMDNs or is this already being
  discussed for the base IM transport?

[Ballot discuss]
1. I could not find a response to Frank Ellermann's last call comments
on "Wed, 16 Jan 2008 12:17:48 +0100" to the IETF mailing list.  I do not
consider it acceptable to simply ignore last call comments.  Please cc
me on any correspondence to Frank and the ietf list on this issue.  Most
of the issues he raised I consider discuss-level issues.

2. The "read" status is misleading for the reasons 3798 describes.  Why
did you choose not to use "displayed" as defined in RFC 3798?  Having
semantically misleading statements in protocols is simply not good
design and I'd like a justification for doing something different from
the previous IETF draft standard in this area.

3. This appears to combine DSN (RFC 3464) and MDN (RFC 3798) features
into one protocol.  As they are related and the primary reason for the
specification split is historic, I think combining the features is a
good thing.  But there are semantic differences between the two
protocols that are both useful and important.  In particular, when a
client requests a DSN it is guaranteed to get a response by RFC 3461,
while responses to MDNs are optional.  This is a very useful property
although it is only possible if the "relayed" action from RFC 3464 is
included in the model and generated in response to a request for
delivery success status.  Why did you choose not to provide this feature
of DSNs?  If the WG considered this and made a willful decision, I'm not
going to insist on a change, but I at least want to understand why the
IETF suite of standards will be inconsistent on such an important semantic.

4. The decision to mix transitive routing information
(IMDN-Record-Route, IMDN-Route) into the IMDN content itself is bad
design, especially when that information is to be removed by
intermediaries. That makes any sort of content based signature
impossible, and such mechanisms are likely to become an important part
of the necessary reputation systems as the volume of IM spam increases
over time. Deliberately designing a signature-hostile format when it is
so likely signatures will be critical to long term use of the protocol
is something that will require extensive justification to convince me
it's acceptable quality for an IETF standard.

5. I could find no record of the IETF-types review in the IETF-types
archives:
http://www.alvestrand.no/pipermail/ietf-types/2007-February/thread.html
Can someone please provide a copy of the review request as received from
the ietf-types list expander?  I want to make sure the message was
actually distributed to the list and not lost in transit.

6. RFC 3862 has an example message with the same subject in two
different languages.  How does the  element handle this in the
IMDN?  Is a lang parameter included on the subject typically?

7. When using a formal schema language, it is important to say in the
specification how it relates normatively to this document and future
extensions.  Is the schema a normative definition of the current format?
Is the schema a normative definition constraining all future extensions
of the format?  If the answer to the latter question is "yes", then I
recommend you read chapter 12 of "Relax NG" by Eric van der Vlist and
revise your Relax NG schema accordingly or you will be painting yourself
in a box.  Briefly: you should use the interleave pattern, I'm not sure
your 'anyIMDI' is correct (see "anything" in the book) and if you put
the addition of 'anyIMDI' in a separate define from the list of
pre-defined elements that will simplify extending the schema.  BTW,
thanks for using RelaxNG as it's much simpler to read and review than
W3C schema.

8. Section 15.4 says both "Specification Required" and "IETF Standards
track" (implying it's a "standards action" registry).  What is the
intended registry type?

9. Have all the questions IANA asked been resolved?

Note: I have deliberately not reviewed the security considerations
section assuming the security directoriate and ADs have that covered.

[Ballot discuss]
This is a process discuss.  Eric Rescorla's secdir review (first
posted February 8 and re-posted May 3) has never received a response.

I consider the issues he raised on bounce/reflection threats and
determining where to send the IMDN to be blocking.  (Is the latter
addressed in the last sentence of 12.1.3.1?) I also support
avoiding the term non-repudiation unless it is defined in this
document for this context.

[Ballot discuss]
Section 10:

The ABNF is not complete and lacks references to some definitions. To my check even after including the ABNF from RFC 3862 the followings are undefined:

COMMA
SEMI
generic-param

Then there is a typo in the the rule:

  notify-req =
      ("negative-delivery" / "positive-delivery" /
        "processing" / "read" / Token) *(SEMI disp-notif-params)

disp-notif-params is missing a "y"

IANA Last Call comments:

IANA has several questions/notes for the authors:

- In section 15.2, the section should be labeled XML Sub-
Namespace Registration, not URN Sub-Namespace Registration.

- In section 15.3, the URI looks incorrect for a Schema
Registration.

- In section 15.4, what are the registration procedures and
initial contents? The contents of 15.5 are assumed as the
initial contents, but you need to declare the registration
procedures for this registry. 15.4 appears to refer to both
Standards Track and Specification Required policies.

- Section 15.4 should not include a URL for the repository
to be created.

- In section 15.5 it's unclear whether you want to register CPIM
message headers as opposed to mail headers or apply this section
to the new registry in section 15.4.

- In section 15.6 it's unclear what kind of content disposition is
required, "Mail Content Disposition Values" is assumed.


IESG Note: Expert Review Required


Action 1 (Section 15.1):

Upon approval of this document, the IANA will make the following
assignments in the "Message Media Types" registry located at
http://www.iana.org/assignments/media-types/message/

message
imdn+xml [RFC-simple-imdn-06]


Action 2 (Section 15.2):

Upon approval of this document, the IANA will make the following
assignments in the "ns" registry located at
http://www.iana.org/assignments/xml-registry/ns.html

ID URI Registration template Reference
---- ----------- ----------- ------------
imdn urn:ietf:params:xml:ns:imdn [imdn] [RFC-simple-imdn-06]


Action 3 (Section 15.3):

Upon approval of this document, the IANA will make the following
assignments in the "schema" registry located at
http://www.iana.org/assignments/xml-registry/schema.html

ID URI Filename Reference
---- ----------- ----------- ------------
imdn urn:ietf:params:xml:schema:imdn [imdn] [RFC-simple-imdn-06]


Action 4:

Upon approval of this document, the IANA will make the following
assignment in the "IETF Protocol Parameter Identifiers" registry
located at

http://www.iana.org/assignments/params

Registered Parameter Identifier  Reference  IANA Registry Reference   
--------------------------------  ---------  --------------------------------------------------------
imdn    [RFC-simple-imdn-06]  http://www.iana.org/assignments/TBD


Action 5 (Sections 15.4, 15.5):

Upon approval of this document, the IANA will create the following
registry "IMDN Fields" located at http://www.iana.org/assignments/TBD
Initial contents of this registry will be:

Registration Procedures: UNDEFINED

URN Prefix: urn:ietf:params:imdn

Index Value Reference
------------- ------------------
Disposition-Notification [RFC-simple-imdn-06]
Message-ID [RFC-simple-imdn-06]
Original-To [RFC-simple-imdn-06]
IMDN-Record-Route [RFC-simple-imdn-06]
IMDN-Route [RFC-simple-imdn-06]


Action 5 (Section 15.5):

Upon approval of this document, the IANA will make the following
assignments in the "Common Presence and Instant Messaging
(CPIM) Headers" registry located at
http://www.iana.org/assignments/cpim-headers

ValueS Reference
------------- ------------------
Disposition-Notification [RFC-simple-imdn-06]
Message-ID [RFC-simple-imdn-06]
Original-To [RFC-simple-imdn-06]
IMDN-Record-Route [RFC-simple-imdn-06]
IMDN-Route [RFC-simple-imdn-06]


Action 6 (Section 15.6):

Upon approval of this document, the IANA will make the following
assignments in the "MAIL CONTENT DISPOSITION Values and
Parameters" registry located at
http://www.iana.org/assignments/mail-cont-disp
sub-registry "Mail Content Disposition Values"

Name Description Reference
----- ------------ ---------
notification notification the body of the message is a [RFC-simple-imdn-06]
notification according to an earlier request
for a disposition notification to an instant
message


We understand the above to be the only IANA Actions for this
document.

PROTO Write-up

(1.a) Robert Sparks is the document shepherd for this document, and has
personally reviewed this version. It is ready for IESG
consideration
for publication.

(1.b) This document has undergone intensive WG review. The authors
ensured
app-area cross review. A review from ietf-types was requested on
February 13, 2007 (there was no response).

(1.c) The authors have verified the RelaxNG schema. This working
group does
not have a lot of experience with this form of schema. The
draft has
not been through any formal external XML review.

(1.d) The shephard has no additional concerns to bring to the
attention of the
area director. No IPR has been disclosed pertaining to this
draft.

(1.e) WG consensus on this document is quite strong. A significant
fraction
of the WG actively participated in creating and reviewing it.
There
is one concept in the document that is likely to bring additional
comments during IETF LC - centered around the notion of a report
that claims a document was "read". There was discussion within
the
working group around the concept in this document and it reflects
consensus. Other documents attempting similar things have since
received (possibly not completely thought through) pushback from
the same group.

(1.f) There has been no threat of appeal or any apparent extreme
discontent.

(1.g) The shepherd has verified this version of the document passes
idnits and
meets the requirements in the ID-Checklist.

(1.h) The document references are appropriately split into normative and
non-normative. There are no normative references to works in
progress.
The document reference to RFC3798 was RFC2298 during WGLC.

(1.i) The document has an appropriate IANA considerations section. It
does ask
IANA to register a MIME type, an XML namespace and schema ,
and asks to
create a new registry named "imdn" with update mechanics of
"Specification
Required". IANAs actions are clearly identified. The document
does ask for
a significant number of IANA actions.

(1.j) The document shepherd has _not_ personally verified that the
RelaxNG
schema in this document validates correctly. Hisham Khartabil
verified
the schema using Oxygen.

(1.k) Proposed announcement writeup:

Technical Summary

This document provides a mechanism whereby endpoints can
request
Instant Message Disposition Notifications (IMDN),
including delivery,
processing and read notifications, for page-mode instant
messages.
The Common Profile for Instant Messaging (CPIM) data
format specified
in RFC 3862 is extended with new header fields that enable
endpoints
to request IMDNs. A new message format is also defined to
convey
IMDNs. This document also describes how SIP entities
behave using
this extension.

Working Group Summary

This document is a product of the SIMPLE working group.

Document Quality
Robert Sparks is the document shepherd. A media-type
review request
was posted February 13, 2007