Re: [EAI] AD review of draft-ietf-eai-downgraded-display-01.txt

[fujiwara at jprs.co.jp]

Thank you for your comments.

> From: Alexey Melnikov <alexey.melnikov at isode.com>
>>     3. Consideration of displaying downgraded message
>>
>>
>>   The following way is to remove "Downgraded-" from the decoded
>>   "Downgraded-" header fields' name and remove the corresponding header
>>   field at the same time.
> 
> This sentence doesn't read well, I am not quite sure what it is trying
> to convey. Is it just saying that the proper procedure is described in
> the next section?

This sentence tried to introduce next section.
I will remove it.

>>     4. Displaying downgraded message
>>
>>   Step 4:   Compare the output of Step 3 and the original header
>>      fields.  If the same header fields exist for the output of Step 3
>>      and the original header fields, remove the same header fields from
>>      the original header fields.
>
> I think the last part "remove the same header fields ..." can be
> worded
> in a better way.
> I suppose if the two [sets of] headers match, then either one can be
> removed?

As commented by Harald, I wil remain as before.

>>This step outputs the original header
>>      fields which is modified by this step 4.  Before this comparison,
>>      a canonicalization described below is useful.
> 
> I think the canonicalization described below this text should be
> required. But I don't have a strong feeling about that.

I will rewrite this as 
  "Before this comparison, canonicalize each header field described below."

>>   Step 5:   Decode MIME encoded header fields and MIME body part header
>>      fields according to [RFC2047] and [RFC2231].
> 
> I think this should say "Decode all *other* ...", i.e. that you
> already
> dealt with address related header fields in previous steps.

I will rewrite this as 
  "Decode all other MIME encoded header fields and MIME body part header fields"

> The Security Considerations section says:
> 
>>    While displaying downgraded message changes the header fields of the
>>    message and it may lose the original information, MUAs should have a
>>    function to read the original received message (with/without MIME
>>    decoding).
> 
> I am thinking that it might be a good idea to recommend that UIs can
> emphasize when original and Downgraded- headers don't match.
> If EAI downgrade gets deployed, I am sure new sorts of scams
> will take advantage of 2 ways to represent information.

I will add a sentence in Security considerations.

  "MUAs can emphasize Downgraded header fields which don't match in
   step 4 of section 4."

>>9.  Normative References
> 
> [...]
> 
>>   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
>>              Requirement Levels", BCP 14, RFC 2119, March 1997.
> 
> I don't think the document is using any RFC 2119 keywords. Either it
> should, or this reference should be deleted.

I use one "MUST NOT" in section 3.

  "Although it is very easy, it MUST NOT be used because of the following reasons."

>>   [RFC5321]  Klensin, J., "Simple Mail Transfer Protocol", RFC 5321,
>>              October 2008.
>>
>>   [RFC5336]  Yao, J. and W. Mao, "SMTP Extension for Internationalized
>>              Email Addresses", RFC 5336, September 2008.
>>
>>   [RFC5337]  Newman, C. and A. Melnikov, "Internationalized Delivery
>>              Status and Disposition Notifications", RFC 5337,
>>              September 2008.
> 
> I think these 3 references should be Informative.

I will upodate.

Regards,

--
Kazunori Fujiwara, JPRS <fujiwara at jprs.co.jp>