Subject: [Gen-art] Gen-ART LC Review of draft-ietf-eai-rfc5721bis-07,

From: Ben Campbell <[email-masked]>
Date: Tue, 18 Sep 2012 20:45:19 -0500

I am the assigned Gen-ART reviewer for this draft. For background on
Gen-ART, please see the FAQ at

<http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq> .

Please resolve these comments along with any other Last Call comments
you may receive.

Document:  draft-ietf-eai-rfc5721bis-07
Reviewer: Ben Campbell
Review Date: 2012-09-18
IETF LC End Date: 2012-09-20

Summary:   The draft is mostly ready for publication as a draft standard. I have a few editorial comments that should be considered prior to publication.

Major issues: None

Minor issues: 

Nits/editorial comments:

-- IDNits has some complaints; please check.

-- The abstract should mention that this obsoletes 5721

-- section 2.1, 2nd paragraph: "The character encoding format of maildrops may not be UTF-8 or ASCII."

I'm confused by this sentence, as it seems to say that the format can't be UTF-8 or ASCII, which otherwise seem to be the only ones contemplated by the draft.  Do you mean to say that it may be some format other than those?

-- same paragraph : "The UTF8 command MAY fail."

Under what circumstances? (this seems sort of tacked onto the paragraph--does it belong there?)

-- 2.1, 4th paragraph: "...need not be accurate, but it is preferable if they were."

Not preferable enough for a SHOULD? (Note that the previous sentence used SHOULD for reporting actual message size counts)

-- section 7, 3rd paragraph: "It is possible for a man-in-the-middle attacker to insert a LANG command in the command stream, thus making protocol-level diagnostic responses unintelligible to the user."

This seems a bit unnecessary to call out, given that a MiTM could just change the diagnostic responses into Klingon even in the absence of the LANG command. It's at least worth mentioning that the LANG command really doesn't make this issue worse than it already was.

---

From: Pete Resnick <[email-masked]>
Date: Fri, 21 Sep 2012 10:23:23 -0500

> -- IDNits has some complaints; please check.

They were checked.

> -- The abstract should mention that this obsoletes 5721

It does.

> I'm confused by this sentence, as it seems to say that the format can't be UTF-8 or ASCII, which otherwise seem to be the only ones contemplated by the draft.  Do you mean to say that it may be som…

Yes, I believe that is an editing error. I will confirm and put in an 
RFC Editor note.

> Under what circumstances? (this seems sort of tacked onto the paragraph--does it belong there?)

AFAICT, it is simply a warning to client writers that the server may 
(for whatever reasons under whatever circumstances) send back an -ERR 
response to the command, even if it advertises the capability. Seems 
appropriate.

> Not preferable enough for a SHOULD? (Note that the previous sentence used SHOULD for reporting actual message size counts)

There is no interoperability impact regarding sizes in STAT and 
free-form text (unlike LIST), so SHOULD is inappropriate.

> This seems a bit unnecessary to call out, given that a MiTM could just change the diagnostic responses into Klingon even in the absence of the LANG command. It's at least worth mentioning that the…

Taken under advisement.

pr

-- 
Pete Resnick<http://www.qualcomm.com/~presnick/>
Qualcomm Incorporated - Direct phone: (858)651-4478, Fax: (858)651-1102

---

From: Pete Resnick <[email-masked]>
Date: Fri, 21 Sep 2012 10:44:18 -0500

>> -- The abstract should mention that this obsoletes 5721

Sorry. You said abstract, not intro. Got it.

pr

---

From: Glen Zorn <[email-masked]>
Date: Fri, 21 Sep 2012 22:52:33 +0700

>>> -- The abstract should mention that this obsoletes 5721

Why?  There is a statement in the header, 10 lines above the abstract, 
that says "Obsoletes: 5721 (if approved)".

---

From: Ben Campbell <[email-masked]>
Date: Fri, 21 Sep 2012 11:15:12 -0500

On Sep 21, 2012, at 10:52 AM, Glen Zorn <[email-masked]> wrote:

> Why?  There is a statement in the header, 10 lines above the abstract, that says "Obsoletes: 5721 (if approved)".

The abstract is sometimes displayed without the rest of the document, for example, in new RFC announcements.

> _______________________________________________
> Gen-art mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/gen-art

---

From: Dave Crocker <[email-masked]>
Date: Fri, 21 Sep 2012 09:21:57 -0700

On 9/21/2012 8:23 AM, Pete Resnick wrote:
> On 9/18/12 8:45 PM, Ben Campbell wrote:abstract should mention that this obsoletes 5721
>
> It does.

Stylistic point:  RFCs last a long time.  Including ephemeral 
information can be distracting, especially in the Abstract.  5 and 10 
years from now, the fact that this RFC replaces another will be 
essentially irrelevant, but the Abstract will still be spending valuable 
space citing the fact.

It is better to have the document written as standing on its own, rather 
than focus on its relationship to its predecessors, except perhaps in 
isolated 'background' or 'history' discussions (and, of course, the 
Updates field...)

d/
-- 
  Dave Crocker
  Brandenburg InternetWorking
  bbiw.net

---

From: Ben Campbell <[email-masked]>
Date: Fri, 21 Sep 2012 13:03:31 -0500

Thanks for the response!

On Sep 21, 2012, at 10:23 AM, Pete Resnick <[email-masked]> wrote:

[...]

> AFAICT, it is simply a warning to client writers that the server may (for whatever reasons under whatever circumstances) send back an -ERR response to the command, even if it advertises the capability. Seems appropriate.
> 
> There is no interoperability impact regarding sizes in STAT and free-form text (unlike LIST), so SHOULD is inappropriate.
> 

Okay.