Subject: Re: [EAI] New Version Notification - draft-ietf-eai-simpledowngrade-06.txt

From: Arnt Gulbrandsen <[email-masked]>
Date: Mon, 13 Aug 2012 13:55:16 +0200

On 08/13/2012 01:47 PM, [email-masked] wrote:
> A new version (-06) has been submitted for draft-ietf-eai-simpledowngrade:
> http://www.ietf.org/internet-drafts/draft-ietf-eai-simpledowngrade-06.txt

Wording only.

I even changed one item with which I violently disagree. Clearly I need 
a vacation.

Arnt

---

From: Barry Leiba <[email-masked]>
Date: Mon, 13 Aug 2012 10:30:50 -0400

>> http://www.ietf.org/internet-drafts/draft-ietf-eai-simpledowngrade-06.txt

The last paragraph of 2.1 doesn't set off "for example" properly with
commas, and because "Received" is a regular word I'm afraid the RFC
Editor might get it wrong.

OLD
   The affected header fields are Bcc, Cc, From, Reply-To, Resent-Bcc,
   Resent-Cc, Resent-From, Resent-Sender, Resent-To, Return-Path, Sender
   and To.  Any addresses present in other header fields, Received for
   example, are not regarded as addresses by this specification.

NEW
   The affected header fields are Bcc, Cc, From, Reply-To, Resent-Bcc,
   Resent-Cc, Resent-From, Resent-Sender, Resent-To, Return-Path, Sender
   and To.  Any addresses present in other header fields, such as Received,
   are not regarded as addresses by this specification.

If you really want to use "for example", you have to do it this way
(and I think it's more awkward): "Any addresses present in other
header fields -- Received, for example -- are not regarded as
addresses by this specification."

In Section 3, version -05 introduced a typo, "nFETCH"; please fix
that, because the RFC Editor won't know what to do with it.

In Section 5, you aren't consistent in capitalizing header field names
(which you do in the rest of the document):

   If any excised information is significant, then that information does
   not arrive at the recipient. Notably, the message-id, in-reference-to
   and/or references fields may be excised, which might cause a lack of
   context when the recipient reads the message.

Please fix that (three field names); the RFC Editor won't.

Also introduced in -05:
OLD
   Some POP/IMAP clients delete the original message and use only the
   what they downloaded, Fetchmail is one well-known example. This may
   lead to permament loss of information.

Apart from the spurious "the", the misspelling, and the comma splice,
there's a general problem with how this paragraph explains the
situation.  I suggest this:

NEW
   Some POP or IMAP clients, such as Fetchmail, download messages
   and delete the version on the server.  This may lead to permanent loss
   of information when the only remaining version of a message is the
   downgraded one.

While you're making changes: in section 7, just get the registry name
right (which you pretty much have) and you don't have to babble at the
RFC Editor:

OLD
   The IANA is requested to add DOWNGRADED to the IMAP response code
   registry.

   (RFC editor: Please edit the previous paragraph suitably once the
   IANA has added the code. The registry is the one specified in RFC
   5530.)

NEW
   The IANA is requested to add DOWNGRADED to the IMAP Response
   Codes registry.

-----------

That's it; the RFC Editor will sort out the rest of the
language/grammar issues, so with the above changes I think this is
ready to go.

--
Barry

---

From: John C Klensin <[email-masked]>
Date: Mon, 13 Aug 2012 11:21:49 -0400

--On Monday, August 13, 2012 10:30 -0400 Barry Leiba
<[email-masked]> wrote:

> The last paragraph of 2.1 doesn't set off "for example"
> properly with commas, and because "Received" is a regular word
> I'm afraid the RFC Editor might get it wrong.
> 
> OLD
>    The affected header fields are Bcc, Cc, From, Reply-To,
> Resent-Bcc,    Resent-Cc, Resent-From, Resent-Sender,
> Resent-To, Return-Path, Sender    and To.  Any addresses
> present in other header fields, Received for    example, are
> not regarded as addresses by this specification.
> 
> NEW
>    The affected header fields are Bcc, Cc, From, Reply-To,
> Resent-Bcc,    Resent-Cc, Resent-From, Resent-Sender,
> Resent-To, Return-Path, Sender    and To.  Any addresses
> present in other header fields, such as Received,    are not
> regarded as addresses by this specification.
> 
> If you really want to use "for example", you have to do it
> this way (and I think it's more awkward): "Any addresses
> present in other header fields -- Received, for example -- are
> not regarded as addresses by this specification."

An alternate way to deal with this is to use the convention
about header field names used in many other documents.  That
would turn the original paragraph into:

	The affected header fields are "Bcc:", "Cc:", "From:",
	"Reply-To:", "Resent-Bcc:", "Resent-Cc:",
	"Resent-From:", "Resent-Sender:", "Resent-To:",
	"Return-Path:", "Sender:" and "To:".  Any addresses
	present in other header fields, "Received:" for example,
	are not regarded as addresses by this specification.

Barry's suggestion about setting '"Received:" for example' off
with dashes would further improve even that form, IMO.

The choice is left to author discretion as far as I'm concerned.
But I vaguely recall a recent debate with the RFC Editor about
header field names and would predict that, if you go with the
unquoted alternative, we will have questions to answer during
the editing process.

>...
> language/grammar issues, so with the above changes I think
> this is ready to go.

See above.  

best,
   john

p.s. Barry, thanks for the careful checking.

---

From: Barry Leiba <[email-masked]>
Date: Mon, 13 Aug 2012 12:17:56 -0400

>         The affected header fields are "Bcc:", "Cc:", "From:",

Yeah, I really wanted to avoid the ugly gobs of quotation marks.  If
the RFC Editor will put them in anyway, we might as well.  But if we
can manage without them, I think the document will read better without
them.  Why don't we try?

> with dashes would further improve even that form, IMO.

I think it's quite necessary, actually.  Consider this sentence:

   I have a lot of friends, John for example.

That's simply wrong.  First, it's a comma splice (a form of a run-on
sentence), and second, "for example" itself needs to be separated from
"John" by a comma.  That's why I think the long-dash isn't just nice,
but necessary:

  I have a lot of friends -- John, for example.

In any case, as long as we fix it so it's unambiguous, the RFC Editor
will take care of the fine grammatical points.  I'm just worried about
what the RFC Editor might not quite understand.  So, yes, adding all
those icky quotation marks will make it clear.

b

---

From: John C Klensin <[email-masked]>
Date: Mon, 13 Aug 2012 12:34:56 -0400

--On Monday, August 13, 2012 12:17 -0400 Barry Leiba
<[email-masked]> wrote:

> Yeah, I really wanted to avoid the ugly gobs of quotation
> marks.  If the RFC Editor will put them in anyway, we might as
> well.  But if we can manage without them, I think the document
> will read better without them.  Why don't we try?

Wfm.  As with other things, I'm much happier going into the
review and editing process with "we discussed that, and...".

>>         present in other header fields, "Received:" for
> That's simply wrong.  First, it's a comma splice (a form of a
> run-on sentence), and second, "for example" itself needs to be
> separated from "John" by a comma.  That's why I think the
> long-dash isn't just nice, but necessary:
> 

Indeed.  The original sentence read badly to me for other
reasons and I would have preferred, using this example, 

    I have a lot of friends including, for example, John.

or, using the original sentence,

	Any addresses present in other header fields such as
	"Received:" are not regarded as addresses by this
	specification.

with the question of whether there should be commas around 'such
as "Received:"' (and before "including," is part of another
discussion (the RFC Editor would probably say "yes").

But I think this is a matter that would be certain to be spotted
and fixed by the RFC Editor so, other than getting rid of the
original (and clearly incorrect) sentence, I think this can be
left to author discretion and to them.

    john

> In any case, as long as we fix it so it's unambiguous, the RFC
> Editor will take care of the fine grammatical points.  I'm
> just worried about what the RFC Editor might not quite
> understand.  So, yes, adding all those icky quotation marks
> will make it clear.
> 
> b

---

From: Arnt Gulbrandsen <[email-masked]>
Date: Mon, 13 Aug 2012 22:59:15 +0200

> would turn the original paragraph into:

... would turn the paragraph into something rather foreign. We (the 
audience for the RFC) don't usually quote field names when writing to 
each other, so why should an RFC?

Barry: I'm too tired to attend to your mail tonight.

Arnt