A thousand pardons. Missing ekr's comments should have warned me that  
we missed other comments. I only just now reviewed the DISCUSSes.  
Please have pity for this mistake.

There have been so many DISCUSSes and comments, specifically GEN-ART  
and SECDIR, that a new draft will be forthcoming.

> DISCUSSES AND COMMENTS:

> ======================

> Lars Eggert: Comment [2008-05-08]: 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.)
Start of playback. Fixed.
> 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.)
I can take a hint. You are the third person to question a'priori. It  
comes out.

NEW
In addition to text, some IMs may contain audio, video, and still  
images. Therefore, the state "read" includes the start of rendering  
the audio or video file to the user. Note that the term "read" is a  
token indicating the User Agent began to render or display the IM.
> 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.
Fixed, but this will depend on ekr's analysis of the new wording  
(posted to IETF and SIMPLE lists).

> 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.
I agree, but the consensus of the work group was that mandating the IM  
Sender to keep this state will not be practical for devices with  
limited or volatile memory. That is also why we keep the sending time  
so the sender might have a clue what IM this IMDN is in reference to.
> Section 12.1.1., paragraph 4: > An IM Recipient can ignore such  
> request > if the IM Sender is anonymous. Nit: s/can/MAY/
Fixed.
> Section 13., paragraph 1: > MSRP already provides a built-in  
> mechanism to supply positive and > negative delivery reports.  
> Reference to MSRP missing.
Fixed.
> 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?
Not an issue, as one cannot have multiple addresses, UNLESS one  
inserts a IMDN-Route that is a list server.



> Pasi Eronen: Discuss [2008-05-08]:

> Process note: Eric Rescorla's SecDir review needs a response.
Done.
> 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.).
Will fix
> 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).
Personally, I think it's wholly unnecessary, but it appears to be work  
group consensus. I will defer to the chairs on this one.
> 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.
Fixed in EKR response
> 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.
Standards Action. Fixed.
> From Eric Rescorla's SecDir review: [snip]
Dealt with in a separate e-mail.

>  Chris Newman: Discuss [2008-05-06]: 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.
Here are Frank's issues:
 > | It is strongly RECOMMENDED that the IM Recipient obtain
 > | the user's consent before sending an IMDN. Circumstances
 > | where the IM Recipient does not ask for the user's consent
 > | include IM systems that, for regulatory reasons, are
 > | required to issue an IMDN, such as in the health care
 > | field or financial community.
 > IMO nothing less than a MUST is acceptable, no matter what RFC 3798  
says. Assuming that anybody allows MDNs without explicit permission, I  
don't.
Unfortunately, this was (a) something with strong work group  
consensus, due to the factors enumerated above and (b) something  
wholly unenforceable at the protocol level. What is the point of  
making something a MUST that never sees the light of day?

 > | Electronic Mail [10] deals with this situation with Message
 > | Delivery Notifications [11]. After the recipient views the
 > | message, her mail user agent generates a Message Delivery
 > | Notification, or MDN.
 > Dubious. E-mail *offers* this (in RFC 3798), but MUAs doing it  
without explicit permission would be considered harmful.
Correct on the assertion that e-mail offers, not deals with the  
situation. However, again mandating that a MUA *never* automatically  
generates an MDN with out explicit permission is pure wishful thinking.

How about:
    Electronic Mail offers a solution to this need with Message  
Delivery Notifications.

 > | unique with at least 32 bits of randomness
 > If it's random it isn't necessarily unique, or I miss a clue.
You are again correct. Already fixed.
 > | Message-ID = "Message-ID" ": " Token
 > What's a <Token> ? The 34jk324j example isn't supposed to be  
"worldwide unique forever" as in all "Message-ID" definitions since  
1994, or is it ? Maybe the draft should say "Token" where it says  
"Message-ID", and of course define the <Token>.
Will fix.


> 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.
Historic drivel from the merge of the two IMDN root documents. I am  
willing to change all of the "read"s to "diplayed"s. However, I will  
leave that decision to the chairs to determine if we should go to the  
work group to ask if the 4-byte string that happens to decode to 'r'  
'e' 'a' 'd' in ASCII should be changed to something meaningful and not  
misleading.
> 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.
Willful decision of the WG, over the objection of this editor. The  
editor humbly complied, as while it is painful, it is not harmful.
> 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.
This editor agrees. The claim is this is the WG consensus.
> 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.
I don't see it, either. I would offer we cycle through these comments  
before resending.
> 6. RFC 3862 has an example message with the same subject in two  
> different languages. How does the <subject> element handle this in  
> the IMDN? Is a lang parameter included on the subject typically?
Can only be one, unless we are in to machine translation. How about:
NEW
    The <subject> element is optional. If present it MUST cary the
    text and, if present, language attribute, that was in the Subject
    header field, if any. This allows for a human level correlation
    between an IM and an IMDN.
> 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.
Will fix.
> 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?
Standards Action. Fixed
> 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.
Yes.


> Tim Polk: Discuss [2008-05-06]:

> 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?)
There is a lively debate between the editors and no one else on the  
SIMPLE list on this issue. See the thread starting with:
http://www.ietf.org/mail-archive/web/simple/current/msg07846.html
> I also support avoiding the term non-repudiation unless it is  
> defined in this document for this context.
Fixed.


> Magnus Westerlund: Discuss [2008-05-06]:

> 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"
Will fix.
_______________________________________________
Simple mailing list
Simple@ietf.org
https://www.ietf.org/mailman/listinfo/simple