Subject: [Extra] AD Review of draft-ietf-extra-imap4rev2

From: "Murray S. Kucherawy" <[email-masked]>
Date: Mon, 4 Jan 2021 00:18:46 -0800

At long last. Thanks for your patience. This is a lot of material to sift
through!

This AD review is based on -22.  I’m coming at this as someone who has made
almost no direct use of IMAP as a user and certainly never implemented it,
so expect some neophyte-style feedback here.  I also (briefly) reviewed the
diff between RFC 3501 and this version.

Away we go...

Section 1.2

Should the “C:” and “S:” paragraph also mention that CRLF termination is
implicit in examples?  I realize Section 2.2 makes it clear that’s the
protocol anyway, so maybe this isn’t necessary, but I’ve seen it made
explicit in other documents so I thought I’d mention it.

Section 2.2.1

  Clients MUST follow the syntax outlined in this specification

   strictly.  It is a syntax error to send a command with missing or

   extraneous spaces or arguments.

It seems unnecessary to say this in a standards track document.  There’s a
similar paragraph in Section 2.2.2.

Section 2.2.2

   In the case of certain server data, the data MUST be recorded.

This seems misplaced; the MUST should be in the descriptions for the
specific cases where this requirement exists.

Section 2.3

Most of the subsections below here start with a clause that defines the
term, but it’s not a sentence.  This may be personal preference, but I
suggest adjusting them slightly so they’re sentences.  I’ve included an
example below where I have an adjacent suggestion and thus fixed the whole
paragraph.

Section 2.3.1.1

“STRONGLY ENCOURAGES” in all caps seems awkward.  I’m tempted to say
something about it not being valid BCP 14, etc.

Section 2.3.2

The opening sentence isn’t a sentence.  Also later, “Keyword” is introduced
without indicating that it’s one of the two possible flag types (which I
believe to be the case).  I suggest:

  A message has associated with it a list of zero or more named tokens,

   known as “flags”. A flag is set by its addition to this list, and is
cleared by its

   removal.  There are two types of flags in IMAP4rev2: system flags, and
keywords.

   A flag of either type can also be permanent or session-only.

Second paragraph: s/begin/begins/

s/in used in/in use in/

The text surrounding $Phishing goes further into human factors work than
other working groups have felt appropriate.  (DKIM and DMARC come to
mind.)  Are we sure that belongs here?

It seems strange to oblige a client detecting both $Junk and $NotJunk being
set to deal with that condition by fixing it.  The advice to ignore them is
fine, however.

It’s also curious to put a normative SHOULD on registering keywords, as
IANA activity is outside of the protocol.  It’s more typical to say you
SHOULD ignore keywords you don’t recognize, and then make a reference to
the registry.

Should this section mention whether the system flags are permanent?  \Seen,
for example, is clearly a system flag, but it could also be a session flag.

Section 2.3.3

All the SHOULDs in here make me wonder when an implementor might
legitimately choose to do something different.  Or maybe instead of “SHOULD
be”, just say “is”?

Section 4.3

4th paragraph: s/alternate/alternative/

Section 5.1

There’s a reference “see the Formal Syntax” which could probably benefit
from a section number reference as well.  This is actually something I’d
thought about many times earlier in the document up to this point, but I’m
finally saying something here; some of them were clear references like
this, while others were references to commands or flags that are “described
elsewhere in this document”.

Section 5.1.2.1

Although both “Implementer” and “Implementor” appear to be correct, you use
the latter everywhere in the document except here.  (Actually, Google docs
suggests the former.)

Section 5.2

“Sometimes, such behavior is REQUIRED.”  This isn’t a specific normative
statement, so I’d use the lowercase version here, and use BCP 14 language
when you’re presenting specific cases.

Section 5.3

Maybe my understanding is wrong, but if you do a non-blocking write while
you don’t have enough buffer space available, won’t some of what you write
be lost, resulting in gibberish at the other end?  Maybe this needs to
mention retries of stuff that couldn’t be sent (if any) when a non-blocking
write returns?

I’m tempted to suggest just removing this.  This is something you deal with
at the socket layer, and IMHO isn’t really part of IMAP itself.

Section 6.1.1

Is the stuff about XBLURDYBLOOP still appropriate given BCP 178?

Section 6.1.2

This section says NOOP can be used to reset the autologout timer (which
seems definite), but Section 5.1.4 says any command only SHOULD reset the
timer.  Do these line up?

Section 6.2

s/alternate/alternative/

Section 6.2.3

I think there’s an “or” missing in the last paragraph.

Section 6.3.1

There’s another “X” reference here (BCP 178).

This section should make it more explicit, up front, that the response
names the extensions that were successfully enabled.  Right now the lede is
buried in about the 7th paragraph.

Section 6.3.2

Where is “Paragraph 10”?

Section 6.3.4

The all-caps “UNLESS” should probably be lowercase-ized.

Section 6.3.5

Same remark about “UNLESS”.

Section 6.3.6

Same remark about “UNLESS”.

It’s weird to say “renaming INBOX is permitted” followed immediately by
“some servers don’t let you do this”.  Which is the standard for this
version of IMAP?  If it’s an implementation choice, I think that’s what
this should say.

Section 6.3.9

   The LIST command returns a subset of names from the complete set of

   all names available to the client.

Names of what?

   Clients SHOULD use the empty reference

   argument.

Why might I not do this?

    For example, here are some examples …

You can probably drop “For example,”.

Section 6.3.9.2

This section (and the previous) require that \Subscribed be computed
accurately before the response is generated.  How does this square with the
text in Section 6.3.9 that insists replies come quickly?

Section 6.3.9.5

A grammar nit, which I encountered here but it’s not the first: “whether or
not” should usually just be “whether”; the “or not” is implied.

The second paragraph also gets into the presentation of the reply.  This is
human factors stuff the IETF tends to avoid.  Are we sure it belongs here?

Section 6.3.9.6

    Servers SHOULD ONLY return …

I think “ONLY” should be lowercase here (confusion with BCP 14).

Section 6.3.9.7

   another user renaming of deleting the

s/of/or/

Section 6.3.9.8

Another grammar nit: I keep running into sentences or clauses that end with
“subscribed to”, which should really be “to which the user is subscribed”,
or maybe just “subscribed”.

Sadly I must also point out that in example 8, contrary to my earlier
point, this use of “whether or not” is correct as-is.  But the prose later
on in example 8 refers to “subscribed children”, which is a good example of
avoiding the problem I just mentioned above.  (Whee, English.)

Section 6.3.10

   The NAMESPACE command causes a single ungagged NAMESPACE …

You probably meant “untagged”, unless NAMESPACE is generally noisy.

  In this example, a server supports 2 Personal Namespaces.  …

s/2/two/

There’s a reference to X-PARAM in here that probably needs updating in
light of BCP 178.

      refer to sections Section 7
<https://tools.ietf.org/html/draft-ietf-extra-imap4rev2-22#section-7>,

      Section 7.3.1
<https://tools.ietf.org/html/draft-ietf-extra-imap4rev2-22#section-7.3.1>
for more information about …

Remove “sections” and stick an “and” between them.

Section 6.3.12

I’m not sure that 310 is the correct length for the first example.  I get
312.  Am I misunderstanding how this gets determined?  I get this by adding
the length of each line (including the empty ones) plus two for each line
representing the terminating CRLF.

Using that method, the second example also appears to be off by two.

Section 6.3.13

  Without the IDLE command a client requires to poll the server for

s/requires/needs/ (or maybe “would need”)

  responses at any time.  If the server choose to send unsolicited

s/choose/chooses/

The specific advice about reissuing IDLE every 29 minutes presumes the
auto-logout timeout is fixed at 30 minutes.  Since I think I read higher up
that this could be some other time limit, it might be a good thing to
negotiate somehow via a capability, or the continuation reply to IDLE, or
something like that.

Section 6.4.2

   The UNSELECT command frees server's resources associated with the

   selected mailbox and returns the server to the authenticated state.

I suggest changing “server’s” to “session’s”.  As written here, it could be
read to say you’re deleting the selected mailbox.

Section 6.4.4

The use of “(*)” to make a footnote that’s actually just the next paragraph
can probably be eliminated by just merging the paragraphs.

OLD:

  Individual options may contain parameters enclosed in

   parentheses (*).  If an option has parameters, they consist of atoms

   and/or strings and/or lists in a specific order.  Any options not

   defined by extensions that the server supports must be rejected with

   a BAD response.

   (*) - if an option has a mandatory parameter, which can always be

   represented as a number or a sequence-set, the option parameter does

   not need the enclosing ().  See the ABNF for more details.

NEW:

Individual options may contain parameters enclosed in parentheses.
(However, if an option has a mandatory parameter, which can always be
represented as a number or a sequence-set, the option parameter does not
need the enclosing parentheses.  See the ABNF for more details).  If an
option has parameters, they consist of atoms and/or strings and/or lists in
a specific order.  Any options not defined by extensions that the server
supports MUST be rejected with a BAD response.

(END)

In “Return number of the messages”, I think it should be “Return the number
of messages”.

The definitions of several search keys should be reviewed to ensure use of
the terms “header field” (not simply “header”) and “header field value”
appropriately, matching current convention.

Does TEXT matching ignore line breaks?  For instance, does searching for
“foo bar” match “foo<newline>bar”?  Given the text about flexible matching,
I was wondering.

Section 6.4.4.2

“as described in by Section 5.5
<https://tools.ietf.org/html/draft-ietf-extra-imap4rev2-22#section-5.5>.”
-- s/in by/in/

Section 6.4.4.4

I think the inline comments in the various examples don’t really need to be
inline.  They could just as easily be prose below each example.

Section 6.4.7

There’s a lot of SHOULD and SHOULD NOT here that make me think a discussion
of why one might do otherwise would be helpful.  There are otherwise too
many different ways in which this command could legitimately behave.

Section 6.5

Is this appropriate in light of BCP 178?

Section 7.1

Why would CONTACTADMIN be returned as part of an OK message, such as in the
example given?  I read that as “Your login was successful, but you should
contact your help desk.”

Section 7.2.2

The stuff about capability names starting with “X” should be reviewed in
light of BCP 178.

Section 7.2 and its subsections

A fair bit of this text is repeated verbatim from earlier sections and
should probably be consolidated.  I really noticed this when I hit Section
7.2.3 where, for instance, \HasChildren is defined both here and in Section
6.3.9.5, with the paragraphs in both sections being identical.  However,
now that I look earlier in 7.2.2, I see the same issue.

Section 7.4.2

In the ENVELOPE section, there are references to “header” that should be
“header field”.

Section 13.1

RFCs 2152 and 2180 are normative downrefs; please make sure the shepherd
writeup calls this out.

-MSK

---

From: Alexey Melnikov <[email-masked]>
Date: Mon, 4 Jan 2021 14:05:18 +0000

Hi Murray,

Thank you for your detailed review! Below I removed some comments I 
still need to act upon/investigate. Detailed replies below:

On 04/01/2021 08:18, Murray S. Kucherawy wrote:
>
> At long last. Thanks for your patience. This is a lot of material to 
> sift through! This AD review is based on -22.  I’m coming at this as 
> someone who has made almost no direct use of IMAP as a user and 
> certainly never implemented it, so expect some neophyte-style feedback 
> here.  I also (briefly) reviewed the diff between RFC 3501 and this 
> version.
>
> Away we go...
>
>
> Section 1.2
>
>
> Should the “C:” and “S:” paragraph also mention that CRLF termination 
> is implicit in examples?  I realize Section 2.2 makes it clear that’s 
> the protocol anyway, so maybe this isn’t necessary, but I’ve seen it 
> made explicit in other documents so I thought I’d mention it.
>
CRLF is implied by use of term "line" (which is defined later in the 
document), but I clarified this here.
> It seems unnecessary to say this in a standards track document.  
> There’s a similar paragraph in Section 2.2.2.
>
I think the text is there due to various bugs in implementations, so I 
would rather keep it as is.

> specific cases where this requirement exists.
I think this text is actually Ok where it is, as it warns/requires the 
client to implement proper cashing. It is more a statement of intent.

If you think use of RFC 2119 language here is not right, we can discuss 
that.

>
> Section 2.3
>
>
> Most of the subsections below here start with a clause that defines 
> the term, but it’s not a sentence.  This may be personal preference, 
> but I suggest adjusting them slightly so they’re sentences.  I’ve 
> included an example below where I have an adjacent suggestion and thus 
> fixed the whole paragraph.
>
I think I fixed these.
> something about it not being valid BCP 14, etc.
Changed.
>
> Section 2.3.2
>
>
> The opening sentence isn’t a sentence.  Also later, “Keyword” is 
> introduced without indicating that it’s one of the two possible flag 
> types (which I believe to be the case).  I suggest:
>
>    known as “flags”. A flag is set by its addition to this list, and 
> is cleared by its
>
>    removal. There are two types of flags in IMAP4rev2: system flags, 
> and keywords.
>
This is much better. Thank you.
> Second paragraph: s/begin/begins/
Applied, thanks
>
> The text surrounding $Phishing goes further into human factors work 
> than other working groups have felt appropriate.  (DKIM and DMARC come 
> to mind.)  Are we sure that belongs here?
>
Yes, considering this is a security consideration, a good example of UI 
is necessary here.
>
> It seems strange to oblige a client detecting both $Junk and $NotJunk 
> being set to deal with that condition by fixing it.  The advice to 
> ignore them is fine, however.
>
This is how they were defined when they were registered. I appreciate 
that this might be strange, but changing semantics at this point is not 
going to work.

If you suggest changing the description without changing the semantics, 
we should consider this.

> It’s also curious to put a normative SHOULD on registering keywords, 
> as IANA activity is outside of the protocol.
>
I've seen this done in other RFCs. This is a requirement on 
implementors, which might look odd, but I think this is still a 
legitimate use of RFC 2119 keyword.
>
> It’s more typical to say you SHOULD ignore keywords you don’t 
> recognize, and then make a reference to the registry.
>
>
> Should this section mention whether the system flags are permanent?  
> \Seen, for example, is clearly a system flag, but it could also be a 
> session flag.
>
No, implementations differ and sometimes even \Seen is not permanent. 
(The last sentence of the first paragraph already says "A flag of either 
type can also be permanent or session-only.")

> legitimately choose to do something different.  Or maybe instead of 
> “SHOULD be”, just say “is”?
>
I think for delivery by SMTP, I agree. For COPY/MOVE there is actually a 
posibility that some mailstores wouldn't preserve original values, so 
this is asking them to really think hard about preserving it.

And for APPEND, this is a similar requirement on MUAs to preserve this 
information. (Some don't and it is very awkward.)

So I prefer to keep the last 2 SHOULDs.

> 4th paragraph: s/alternate/alternative/
  [snip]
>
> Section 5.1.2.1
>
>
> Although both “Implementer” and “Implementor” appear to be correct, 
> you use the latter everywhere in the document except here.  (Actually, 
> Google docs suggests the former.)
>
I changed it to implementors and I am happy for RFC Editor to tell me 
which one they prefer ;-)
>
> Section 5.2
>
>
> “Sometimes, such behavior is REQUIRED.”  This isn’t a specific 
> normative statement, so I’d use the lowercase version here, and use 
> BCP 14 language when you’re presenting specific cases.
>
I agree. Changed.

  [snip]
>
> Section 6.1.2
>
>
> This section says NOOP can be used to reset the autologout timer 
> (which seems definite), but Section 5.1.4 says any command only SHOULD 
> reset the timer.  Do these line up?
>
(I assume you meant 5.4)

Well spotted. I changed text in 5.4 to readL

  The receipt of any command from the client during that interval resets 
the autologout timer.

> s/alternate/alternative/
Changed.
> I think there’s an “or” missing in the last paragraph.
This looks Ok to me. Can you elaborate?

  [snip]

> names the extensions that were successfully enabled.  Right now the 
> lede is buried in about the 7th paragraph.
I didn't move the paragraph that talks about ENABLED response, but I 
clarified it.
> Where is “Paragraph 10”?
This is pointing to paragraph 10 within Section 7.1. (Server Responses - 
Status Responses). I.e. this is pointing to the CLOSED response code 
definition.

This looks like an xml2rfc glitch and I added a note in XML for RFC 
Editor to look at it.

> Same remark about “UNLESS”.
Changed all 3.
>
> It’s weird to say “renaming INBOX is permitted”
>
This is saying that the server wouldn't return "BAD" to it.
>
> followed immediately by “some servers don’t let you do this”.
>
But this is saying that the server can still return "NO".
>
> Which is the standard for this version of IMAP?  If it’s an 
> implementation choice, I think that’s what this should say.
>
Yes, it is.
>    all names available to the client.
Mailbox names. I will clarify.
>    Clients SHOULD use the empty reference
If you want "change directory" kind of behaviour (where the directory is 
the reference name argument).
> You can probably drop “For example,”.
Done.
> accurately before the response is generated.  How does this square 
> with the text in Section 6.3.9 that insists replies come quickly?
>
You have to comply with both :-). It is quite important for \Subscribed 
to be accurate, so implementations need to do that while maintaining 
reasonable performance.

  [snip]

>
> The second paragraph also gets into the presentation of the reply.  
> This is human factors stuff the IETF tends to avoid.  Are we sure it 
> belongs here?
>
This is copy of the text from another RFC and I personally found this 
text to be useful when implementing.
> I think “ONLY” should be lowercase here (confusion with BCP 14).
Changed.
>    another user renaming of deleting the
Fixed, thank you.

  [snip]

> You probably meant “untagged”, unless NAMESPACE is generally noisy.
Thank you :-)
>       refer to sectionsSection 7,
>
>  Section 7.3.1 for more information about …
>
>
Changed.
>
> Section 6.3.12
>
>
> I’m not sure that 310 is the correct length for the first example.  I 
> get 312.
>
I just checked and I got 310.
>
> Am I misunderstanding how this gets determined?  I get this by adding 
> the length of each line (including the empty ones) plus two for each 
> line representing the terminating CRLF.
>
Correct. But note that the CRLF at the end of the command (it appears as 
an empty line) doesn't count, because it is part of the command line, 
not the literal itself.
>   responses at any time.  If the server choose to send unsolicited
Fixed.
> auto-logout timeout is fixed at 30 minutes.  Since I think I read 
> higher up that this could be some other time limit, it might be a good 
> thing to negotiate somehow via a capability, or the continuation reply 
> to IDLE, or something like that.
>
The limit can't be smaller than 30 minutes, without violating IMAP4rev2. 
So 29 limit is a safe default that should work in all cases.

Unfortunately there is no way to advertise the limit at the moment.

> I suggest changing “server’s” to “session’s”.  As written here, it 
> could be read to say you’re deleting the selected mailbox.
>
Ok.
>
> Section 6.4.4
>
>
> The use of “(*)” to make a footnote that’s actually just the next 
> paragraph can probably be eliminated by just merging the paragraphs.
>
>
> OLD:
>
> not need the enclosing parentheses.  See the ABNF for more details).  
> If an option has parameters, they consist of atoms and/or strings 
> and/or lists in a specific order.  Any options not defined by 
> extensions that the server supports MUST be rejected with a BAD response.
>
>
> (END)
>
I used your text. Thank you.
>
> In “Return number of the messages”, I think it should be “Return the 
> number of messages”.
>
Changed.
>
> The definitions of several search keys should be reviewed to ensure 
> use of the terms “header field” (not simply “header”) and “header 
> field value” appropriately, matching current convention.
>
Ok, I think I found all cases. If you find anything I miss, please let 
me know.
>
> Does TEXT matching ignore line breaks?  For instance, does searching 
> for “foo bar” match “foo<newline>bar”? Given the text about flexible 
> matching, I was wondering.
>
It might. Some implementations canonicalize whitespace, so that would 
match. This is implementation specific.
>
> Section 6.4.4.2
>
>
> “as described in by Section 5.5.” -- s/in by/in/
>
Fixed.

  [snip]

> Section 7.1
>
>
> Why would CONTACTADMIN be returned as part of an OK message, such as 
> in the example given?  I read that as “Your login was successful, but 
> you should contact your help desk.”
>
You are right, using CONTACTADMIN with NO is more useful. So I've 
updated the example.

[snip]

> Section 7.4.2
>
> In the ENVELOPE section, there are references to “header” that should 
> be “header field”.
>
I hope I caught most of these as well.
>
> Section 13.1
>
> RFCs 2152 and 2180 are normative downrefs; please make sure the 
> shepherd writeup calls this out.
>
>
> -MSK

---

From: Alexey Melnikov <[email-masked]>
Date: Mon, 4 Jan 2021 15:39:05 +0000

Hi Murray,

Replying to some remaining editorial comments:

On 04/01/2021 08:18, Murray S. Kucherawy wrote:
>
> Section 5.1
>
>
> There’s a reference “see the Formal Syntax” which could probably 
> benefit from a section number reference as well.  This is actually 
> something I’d thought about many times earlier in the document up to 
> this point, but I’m finally saying something here; some of them were 
> clear references like this, while others were references to commands 
> or flags that are “described elsewhere in this document”.
>
I fixed several cases of missing references. If you find anything else I 
missed, please let me know.

> Section 6.4.4.4
>
>
> I think the inline comments in the various examples don’t really need 
> to be inline.  They could just as easily be prose below each example.
>
For some examples this might be more involved than for others. Are you 
happy for this to be addressed directly with RFC Editor via an XML comment?

> should probably be consolidated.  I really noticed this when I hit 
> Section 7.2.3 where, for instance, \HasChildren is defined both here 
> and in Section 6.3.9.5, with the paragraphs in both sections being 
> identical. However, now that I look earlier in 7.2.2, I see the same 
> issue.
>
I struggled with some of this, as initially not all mailbox attributes 
were listed in Section 7.2.3 (LIST Response). In other sections it is 
had to talk about some options without introducing the corresponding 
mailbox attribute(s) first. So it would really help to have some 
specific suggestions on where you think text can be dropped.

Best Regards,

Alexey

---

From: Alexey Melnikov <[email-masked]>
Date: Mon, 4 Jan 2021 17:06:48 +0000

Hi Murray,

I've changed subject for this issue, so that it doesn't get lost in 
myriad of other replies.

On 04/01/2021 08:18, Murray S. Kucherawy wrote:

> Section 5.3
>
>
> Maybe my understanding is wrong, but if you do a non-blocking write 
> while you don’t have enough buffer space available, won’t some of what 
> you write be lost, resulting in gibberish at the other end?
>
All the API I've seen tell you how much (possibly 0 octets) were 
written, so a properly written application will not send gibberish. 
Because IMAP is line oriented and, in some cases, octet counted (like 
literals), a partial write is never a problem on the receiving side.
>
> Maybe this needs to mention retries of stuff that couldn’t be sent (if 
> any) when a non-blocking write returns?
>
Possibly. Can you suggest some text on this point?
>
> I’m tempted to suggest just removing this.  This is something you deal 
> with at the socket layer, and IMHO isn’t really part of IMAP itself.
>
Personally, I found warning in this section useful. If it is removed, it 
is not going to change my implementation ;-).

But seriously: I think I would like WG's feedback on this one.

Thank you,

Alexey

---

From: Alexey Melnikov <[email-masked]>
Date: Mon, 4 Jan 2021 17:18:34 +0000

Hi Murray,

I extracted this issue into another message as well:

On 04/01/2021 08:18, Murray S. Kucherawy wrote:
> Section 6.4.7
>
> There’s a lot of SHOULD and SHOULD NOT here that make me think a 
> discussion of why one might do otherwise would be helpful.  There are 
> otherwise too many different ways in which this command could 
> legitimately behave.
>

Ok, so below I quote the whole section and try to explain each use of 
SHOULD/SHOULD NOT:

>    The COPY command copies the specified message(s) to the end of the
>    specified destination mailbox.  The flags and internal date of the
>    message(s) SHOULD be preserved in the copy.
This use of SHOULD is that some mailstores are less capable and can't 
preserve this data.
>
>    If the destination mailbox does not exist, a server SHOULD return an
>    error.
I don't really know the origin of this SHOULD. (Maybe some mailstores 
can't report back whether a destination mailbox doesn't exist?) This 
sounds like a MUST to me.
> It SHOULD NOT automatically create the mailbox.
Again, sounds like a MUST NOT.
> Unless it is
>    certain that the destination mailbox can not be created, the server
>    MUST send the response code "[TRYCREATE]" as the prefix of the text
>    of the tagged NO response.  This gives a hint to the client that it
>    can attempt a CREATE command and retry the COPY if the CREATE is
>    successful.
>
>    If the COPY command is unsuccessful for any reason, server
>    implementations MUST restore the destination mailbox to its state
>    before the COPY attempt.
>
>    On successful completion of a COPY, the server SHOULD return a
>    COPYUID response code (see Section 7.1).
COPYUID was added in an extension, thus the SHOULD. Also see a couple of 
examples given the the following 2 paragraphs:
>    In the case of a mailbox that has permissions set so that the client
>    can COPY to the mailbox, but not SELECT or EXAMINE it, the server
>    SHOULD NOT send an COPYUID response code as it would disclose
>    information about the mailbox.
I would be Ok with "MUST NOT" here.
>
>    In the case of a mailbox that has UIDNOTSTICKY status (see
>    Section 7.1), the server MAY omit the COPYUID response code as it is
>    not meaningful.
>
>    If the server does not return the COPYUID response code, the client
>    can discover this information by selecting the destination mailbox.
>    The location of messages placed in the destination mailbox by COPY
>    can be determined by using FETCH and/or SEARCH commands (e.g., for
>    Message-ID).

Best Regards,

Alexey

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Mon, 4 Jan 2021 09:21:15 -0800

> would rather keep it as is.
I would use "need to" instead of "MUST" here.  It's otherwise a bit
hand-wavy for use of BCP 14 language.  But I'll leave this to the WG.

Section 2.2.2
> If you think use of RFC 2119 language here is not right, we can discuss
Similar to the previous case, I suggest "needs to" here, and then wherever
you talk about certain server data, that's where the BCP 14 language should
go.

I also didn't think you meant caching when you said "recorded"; I took that
to refer to logging.  Possibly something else to clarify.

> Yes, considering this is a security consideration, a good example of UI is
> necessary here.
>

I'm curious to see if anyone else raises this given how much energy those
other WGs used in the past to resist providing any UI advice at all.

> being set to deal with that condition by fixing it.  The advice to ignore
> them is fine, however.
>
> This is how they were defined when they were registered. I appreciate that
> this might be strange, but changing semantics at this point is not going to
> work.
>

Fair enough.

If you suggest changing the description without changing the semantics, we
> should consider this.

No, it's the semantics I found odd, but I realize you're not doing
something new here.

> IANA activity is outside of the protocol.
>
> I've seen this done in other RFCs.
>

Doesn't mean they're right.  :-)

> No, implementations differ and sometimes even \Seen is not permanent. (The
> last sentence of the first paragraph already says "A flag of either type
> can also be permanent or session-only.")
>
Yep, that's what caused me to make the comment.

> posibility that some mailstores wouldn't preserve original values, so this
> is asking them to really think hard about preserving it.
>
I guess I'm wondering if those implementations chose not to for some reason
you think is valid, or was it purely an oversight on their part and you're
using SHOULD to grandfather them in?  Would it be fine to say MUST here and
just say that an implementation not doing this is therefore not compliant
with rev2?

>
> Section 5.1.2.1
>
> Although both “Implementer” and “Implementor” appear to be correct, you
> use the latter everywhere in the document except here.  (Actually, Google
> docs suggests the former.)
>

Yeah, I'm fine with either.  I just wanted internal consistency.

>  The receipt of any command from the client during that interval resets
Why would a command deviate from the SHOULD and not reset the timer?

> This looks Ok to me. Can you elaborate?
Uh, no, I can't. Ignore this one.  It was very late.

> I didn't move the paragraph that talks about ENABLED response, but I

It seems like a pretty important aspect of the response, so I thought it
was strange that it wasn't presented until so late in the section.  Your
call though.

> Which is the standard for this version of IMAP?  If it’s an implementation
> choice, I think that’s what this should say.
>
> Yes, it is.
>

That's fine, then, if this is clarified.  I just found that bit to be
self-contradicting as written in -22.

> the reference name argument).

Ah, yes.  Then this could use a bit of clarification.

> You have to comply with both :-). It is quite important for \Subscribed to
> be accurate, so implementations need to do that while maintaining
> reasonable performance.
>

OK.  I just wanted to make sure the reader isn't getting "You MUST be
fast!" from one direction while also doing "You MUST do all this expensive
stuff!" from the other with no guidance about how to resolve this.

>
>
>  [snip]
>
>
> The second paragraph also gets into the presentation of the reply.  This
> is human factors stuff the IETF tends to avoid.  Are we sure it belongs
> here?
>
> This is copy of the text from another RFC and I personally found this text
> to be useful when implementing.
>

You might consider putting these presentation advice paragraphs into an
appendix too.

-MSK

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Mon, 4 Jan 2021 09:29:19 -0800

> missed, please let me know.

I'll check out -23.

Section 6.4.4.4
>
> I think the inline comments in the various examples don’t really need to
> be inline.  They could just as easily be prose below each example.
>

Sure.  I just found the inline comments caused the whole example to appear
a bit cluttered, and it didn't seem necessary to have them inline.  It's
more of a presentation thing.

> were listed in Section 7.2.3 (LIST Response). In other sections it is had
> to talk about some options without introducing the corresponding mailbox
> attribute(s) first. So it would really help to have some specific
> suggestions on where you think text can be dropped.
>

Basically anything that's a verbatim copy from one section to the next
should be common factored someplace.  For a first suggestion, maybe a
section early on enumerating known mailbox attributes, to which later
sections can then refer?

You could also constrain Section 6 to discuss only the syntax and semantics
of the commands themselves and their options, and leave discussion of the
responses until their Section 7 counterparts.  To cite one particular
example, Section 6.3.9.5, the first paragraph is all you need because it
describes the modification to the LIST request in general prose; it can
then refer to the piece of Section 7 that gives details about the reply.
So 6.3.9.5 is reduced to something like:

   The CHILDREN return option is simply an indication that the client
   wants information about whether or not mailboxes contain children
   mailboxes; a server MAY provide it even if the option is not
   specified.

   This will cause the reply to contain \HasChildren or \HasNoChildren

   attributes on the responses to LIST.  These are described in Section

   7.x.y where the LIST response is defined.

-MSK

---

From: Barry Leiba <[email-masked]>
Date: Mon, 4 Jan 2021 13:11:00 -0500

>>> It seems unnecessary to say this in a standards track document.  There’s a similar paragraph in Section 2.2.2.
>>
>> I think the text is there due to various bugs in implementations, so I would rather keep it as is.
>
> I would use "need to" instead of "MUST" here.  It's otherwise a bit hand-wavy for use of BCP 14 language.

Over the years, we have seen a LOT of implementations that mess this
up, thinking that because IMAP command streams are "readable", they
can add spaces to "improve readability", and then they complain that
things break.  Because of that, I think it's important to have this
text, and I think it's important to use BCP 14 language (it's a *real*
interoperability issue).  I feel pretty strongly about this, as
someone who's many times had to help people fix their implementations
because they weren't warned explicitly about it.

Barry

---

From: Alexey Melnikov <[email-masked]>
Date: Mon, 4 Jan 2021 18:26:33 +0000

Hi Murray/Barry,

I've extracted all of your comments related to BCP 178 ("X- convention 
considered harmful):

> Is the stuff about XBLURDYBLOOP still appropriate given BCP 178?
I deleted this text, as it really belongs to future revision of RFC 4422 
(SASL), if at all.

> There’s another “X” reference here (BCP 178).
This is section defines the ENABLE command. The example is using 
X-GOOD-IDEA as an example of a fictitious capability that can be 
enabled. Use of X-GOOD-IDEA in the example is not critical, but it makes 
it more explicit that this is not registered. I can change the example.

> There’s a reference to X-PARAM in here that probably needs updating in 
Here, I think we need to use an unregistered parameter. It doesn't have 
to be X-PARAM, but X-PARAM seems a bit more obvious due to old usage, 
even if it is considered wrong these days.

> Is this appropriate in light of BCP 178?
So this section is titled "Client Commands - Experimental/Expansion" and 
talks in general terms about implementation specific commands (that were 
required to start with "X" in RFC 3501) and some generic requirements on 
clients/servers in regards to extensions. I can extract useful text 
about the latter and drop the former.
>
> Section 7.2.2
>
>
> The stuff about capability names starting with “X” should be reviewed 
> in light of BCP 178.
>
This section is titled "CAPABILITY Response". Below is the offending text:

    Capability names MUST either begin with "X" or be informational,
    experimental or standards-track IMAP4rev2 extensions, revisions, or
    amendments registered with IANA.

Dropping "X" from the above list would be fine with me. But this raises 
a related question: should this document allow Experimental RFCs outside 
of IETF stream in order to encourage people to document their private 
extensions?

    A server SHOULD NOT offer
    unregistered or non-standard capability names, unless such names are
    prefixed with an "X".

This probably should be dropped.

Best Regards,

Alexey

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Mon, 4 Jan 2021 10:48:09 -0800

On Mon, Jan 4, 2021 at 10:11 AM Barry Leiba <[email-masked]> wrote:

> hand-wavy for use of BCP 14 language.
>

OK, I'm done pushing on this one.  Just wanted to make sure.  :-)

-MSK

---

From: Barry Leiba <[email-masked]>
Date: Mon, 4 Jan 2021 13:54:48 -0500

For what it's worth, I don't think that BCP 178 means to say that you
should never use things that start with "X".  It says that you should
not specifically use "X"-prefixed stuff to make a distinction between
registered and unregistered things when you lay out registries.

Therefore, I think it's fine to use examples that start with "X".
They're only examples.

For the other cases, such as these:

...well, they clearly fall under BCP 178 and we should fix those.

Barry

On Mon, Jan 4, 2021 at 1:26 PM Alexey Melnikov
<[email-masked]> wrote:
>
> Hi Murray/Barry,
>
> I've extracted all of your comments related to BCP 178 ("X- convention considered harmful):
>
> I deleted this text, as it really belongs to future revision of RFC 4422 (SASL), if at all.
>
> Section 6.3.1
>
>
> This is section defines the ENABLE command. The example is using X-GOOD-IDEA as an example of a fictitious capability that can be enabled. Use of X-GOOD-IDEA in the example is not critical, but it makes it more explicit that this is not registered. I can change the example.
>
> There’s a reference to X-PARAM in here that probably needs updating in light of BCP 178.
>
> Here, I think we need to use an unregistered parameter. It doesn't have to be X-PARAM, but X-PARAM seems a bit more obvious due to old usage, even if it is considered wrong these days.
>
>
> Section 6.5
>
> So this section is titled "Client Commands - Experimental/Expansion" and talks in general terms about implementation specific commands (that were required to start with "X" in RFC 3501) and some generic requirements on clients/servers in regards to extensions. I can extract useful text about the latter and drop the former.
>
>
> Section 7.2.2
>
>
> The stuff about capability names starting with “X” should be reviewed in light of BCP 178.
>
> Dropping "X" from the above list would be fine with me. But this raises a related question: should this document allow Experimental RFCs outside of IETF stream in order to encourage people to document their private extensions?
>

---

From: Michael Peddemors <[email-masked]>
Date: Mon, 4 Jan 2021 12:58:58 -0800

Lets' talk some real world examples, and what the consensus is..

X-Archive
X-Attachment-Id
X-Auth-ID
X-Authority-Analysis
X-Auto-Response-Suppress
X-BeenThere
X-CampTrackID
X-Classification-ID
X-CL-ID
X-CMAE-Envelope
X-Contact-Form-Submission
X-CTCH
X-FE-Policy-ID-smtp.fortinet.com
X-Footer
X-Forwarded-Message-Id
X-Gmail-Original-Message-ID
X-Gm-Message-State
X-Gm-Phishy
X-Gm-Spam
X-GOOD-IDEA as an example of a fictitious capability that can be=20
X-Google-DKIM-Signature
X-Google-Original-From
X-Google-Passthru
X-Google-Smtp-Source
X-Headerized
X-LinkedIn-Class
X-LinkedIn-fbl
X-LinkedIn-Id
X-LinkedIn-Template
X-MagicMail-Quarantine
X-MagicMail-SourceIP
X-Mailbox-Line
X-Mailer
X-Mailman-Approved-At
X-Mailman-Version
X-MDID
X-MessageID-Signature
X-Microsoft-Antispam-Mailbox-Delivery
X-Microsoft-Antispam-Message-Info
X-MS-Exchange-CrossTenant-AuthAs
X-MS-Exchange-CrossTenant-AuthSource
X-MS-Exchange-CrossTenant-fromentityheader
X-MS-Exchange-CrossTenant-id
X-MS-Exchange-CrossTenant-mailboxtype
X-MS-Exchange-CrossTenant-Network-Message-Id
X-MS-Exchange-CrossTenant-originalarrivaltime
X-MS-Exchange-CrossTenant-rms-persistedconsumerorg
X-MS-Exchange-CrossTenant-RMS-PersistedConsumerOrg
X-MS-Exchange-CrossTenant-userprincipalname
X-MS-Exchange-Organization-AuthSource
X-MS-Exchange-Organization-Network-Message-Id
X-MS-Exchange-Organization-RecordReviewCfmType
X-MS-Exchange-Transport-CrossTenantHeadersStamped
X-MS-Has-Attach
X-MS-TNEF-Correlator
X-No-Archive
X-OriginalArrivalTime
X-Original-To
X-Originating-IP
X-OriginatorOrg
X-PPP-Message-ID
X-PPP-Vhost
X-Priority
X-RADICALE-NAME
X-Received
X-SES-Outgoing
X-Spam-Flag
X-Spam-Level
X-Spam-Score
X-Spam-Status
X-Telus-Authed
X-Time-IN
X-Virus-Scanned

Many of these are now semi-permanent, and it is doubtful they will be 
deprecated any time soon in many cases..

What are we suggesting here? And in some cases the headers are placed by 
a receiving MTA, and only meant for local decision making, and aren't 
expected to be seen in MTA->MTA traffic..

On 2021-01-04 10:54 a.m., Barry Leiba wrote:
> _______________________________________________
> Extra mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/extra
> 

-- 
"Catch the Magic of Linux..."
------------------------------------------------------------------------
Michael Peddemors, President/CEO LinuxMagic Inc.
Visit us at http://www.linuxmagic.com @linuxmagic
A Wizard IT Company - For More Info http://www.wizard.ca
"LinuxMagic" a Registered TradeMark of Wizard Tower TechnoServices Ltd.
------------------------------------------------------------------------
604-682-0300 Beautiful British Columbia, Canada

This email and any electronic data contained are confidential and intended
solely for the use of the individual or entity to which they are addressed.
Please note that any views or opinions presented in this email are solely
those of the author and are not intended to represent those of the company.

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Mon, 4 Jan 2021 16:39:07 -0800

On Mon, Jan 4, 2021 at 12:59 PM Michael Peddemors <[email-masked]>
wrote:

> [...]

BCP 178 discourages standards track documents from establishing practices
where an "X-" prefix means "experimental", because in reality once that
name is out there, it never changes.  Indeed, as you point out, they're
unlikely to change anytime soon, so this document shouldn't make the
problem worse.

The point I'm making in this comment is that this document shouldn't do
that with capability names.  Barry's correct that the ones starting with
"X" in examples are just examples and don't violate the BCP; I agree, but
there's enough similarity to that deprecated practice that I suggest
(though less urgently) avoiding it in those cases as well.

-MSK

---

From: Alexey Melnikov <[email-masked]>
Date: Tue, 5 Jan 2021 09:51:31 +0000

On 05/01/2021 00:39, Murray S. Kucherawy wrote:

> On Mon, Jan 4, 2021 at 12:59 PM Michael Peddemors 
> <[email-masked] <mailto:[email-masked]>> wrote:
>
> BCP 178 discourages standards track documents from establishing 
> practices where an "X-" prefix means "experimental", because in 
> reality once that name is out there, it never changes.  Indeed, as you 
> point out, they're unlikely to change anytime soon, so this document 
> shouldn't make the problem worse.
To add to this: before BCP 178 none of the above could be registered, 
but now they are treated as any other header field and thus can be 
registered.
>
> The point I'm making in this comment is that this document shouldn't 
> do that with capability names.  Barry's correct that the ones starting 
> with "X" in examples are just examples and don't violate the BCP; I 
> agree, but there's enough similarity to that deprecated practice that 
> I suggest (though less urgently) avoiding it in those cases as well.

---

From: Alexey Melnikov <[email-masked]>
Date: Tue, 5 Jan 2021 13:56:14 +0000

Hi Murray,

On 04/01/2021 17:21, Murray S. Kucherawy wrote:
> On Mon, Jan 4, 2021 at 6:05 AM Alexey Melnikov 
> <[email-masked] <mailto:[email-masked]>> wrote:
>
>>
>>     Section 2.2.1
>>
Barry replied to this and I think you are Ok with MUST staying as is.
>>     This seems misplaced; the MUST should be in the descriptions for
>>     the specific cases where this requirement exists.
>>
>     I think this text is actually Ok where it is, as it warns/requires
>     the client to implement proper cashing. It is more a statement of
>     intent.
>
>     If you think use of RFC 2119 language here is not right, we can
>     discuss that.
>
> Similar to the previous case, I suggest "needs to" here, and then 
> wherever you talk about certain server data, that's where the BCP 14 
> language should go.
The latter would be difficult, because there are several responses like 
EXISTS and EXPUNGE that needs to be remembered by clients, but this list 
is not exhaustive.
>
> I also didn't think you meant caching when you said "recorded"; I took 
> that to refer to logging.  Possibly something else to clarify.

So this paragraph says:

    Server data SHOULD
    be recorded, so that the client can reference its recorded copy
    rather than sending a command to the server to request the data.  In
    the case of certain server data, the data MUST be recorded.

I think caching is intended here. Is "remembered" better that "recorded" 
above?

>>
>>     The text surrounding $Phishing goes further into human factors
>>     work than other working groups have felt appropriate.  (DKIM and
>>     DMARC come to mind.)  Are we sure that belongs here?
>>
>     Yes, considering this is a security consideration, a good example
>     of UI is necessary here.
>
>
> I'm curious to see if anyone else raises this given how much energy 
> those other WGs used in the past to resist providing any UI advice at all.
There are obvious counter examples in recent history, like TLS and OAUTH WG.

>>     Should this section mention whether the system flags are
>>     permanent?  \Seen, for example, is clearly a system flag, but it
>>     could also be a session flag.
>>
>     No, implementations differ and sometimes even \Seen is not
>     permanent. (The last sentence of the first paragraph already says
>     "A flag of either type can also be permanent or session-only.")
>
Basically I don't think we can say anything useful about system flags in 
this respect. They may or may not be permanent, same as keywords. So I 
think no change for this one.
>>     legitimately choose to do something different.  Or maybe instead
>>     of “SHOULD be”, just say “is”?
>>
>     I think for delivery by SMTP, I agree. For COPY/MOVE there is
>     actually a posibility that some mailstores wouldn't preserve
>     original values, so this is asking them to really think hard about
>     preserving it.
>
>     And for APPEND, this is a similar requirement on MUAs to preserve
>     this information. (Some don't and it is very awkward.)
>
> I guess I'm wondering if those implementations chose not to for some 
> reason you think is valid, or was it purely an oversight on their part 
> and you're using SHOULD to grandfather them in?  Would it be fine to 
> say MUST here and just say that an implementation not doing this is 
> therefore not compliant with rev2?

I think I already gave an example of limited mailstores that are not 
able to preserve some information on COPY/MOVE. (For example they might 
be gatewaying data to other more restrictive formats). I don't think we 
want to make them non compliant at this time.

In regards to clients preserving internaldates on APPEND. If they use 
APPEND to migrate/copy data between 2 different IMAP servers or between 
a local and remote mailstore, they must preserve it. But APPEND can also 
be used for other creating modifications, so again I think SHOULD is 
fine as is.

>>     (which seems definite), but Section 5.1.4 says any command only
>>     SHOULD reset the timer.  Do these line up?
>>
>     (I assume you meant 5.4)
>
>      The receipt of any command from the client during that interval
>     resets the autologout timer.
>
There is no reason I can think of, so the new text I suggested above no 
longer uses "SHOULD". I think that addresses your issue. Do you disagree?

>      [snip]
>
>>     This section should make it more explicit, up front, that the
>>     response names the extensions that were successfully enabled. 
>>     Right now the lede is buried in about the 7th paragraph.
>     I didn't move the paragraph that talks about ENABLED response, but
>     I clarified it.
>
>
> It seems like a pretty important aspect of the response, so I thought 
> it was strange that it wasn't presented until so late in the section.  
> Your call though.
I think the new text is clear, as it explains what appears in the 
ENABLED response the first time ENABLED response is mentioned. So have a 
look at -23 and let me know.
> self-contradicting as written in -22.

I think IMAP is a bit subtle in places, as NO and BAD have very 
different semantics. "BAD" means that the client shouldn't have tried 
this. "NO" means some other reason why this fails, which can be entirely 
server specific.

Anyway, I clarified this.

Best Regards,

Alexey

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Wed, 6 Jan 2021 14:53:35 -0800

> Barry replied to this and I think you are Ok with MUST staying as is.

Yep, I just wanted to have the discussion.  Thanks for indulging.

Section 2.2.2
> EXISTS and EXPUNGE that needs to be remembered by clients, but this list is
> not exhaustive.
>

I hear you.  The thing that I was hoping to solve for is that it's not very
crisp.  Which server data MUST be cached, and which server data is OK to
toss?  You can't tell just from that sentence.  If it's specified more
clearly later on, then this isn't needed.

> I think caching is intended here. Is "remembered" better that "recorded"
Somehow when I read it the first time I didn't realize that was simply
caching; it seemed to be describing something more elaborate.  Anyway, yes,
this is fine.

> There are obvious counter examples in recent history, like TLS and OAUTH

Huh.  OK.  I learned something today.  :-)

> think no change for this one.

OK.

> reason you think is valid, or was it purely an oversight on their part and
> you're using SHOULD to grandfather them in?  Would it be fine to say MUST
> here and just say that an implementation not doing this is therefore not
> compliant with rev2?
>
> I think I already gave an example of limited mailstores that are not able
> to preserve some information on COPY/MOVE. (For example they might be
> gatewaying data to other more restrictive formats). I don't think we want
> to make them non compliant at this time.
>
> APPEND to migrate/copy data between 2 different IMAP servers or between a
> local and remote mailstore, they must preserve it. But APPEND can also be
> used for other creating modifications, so again I think SHOULD is fine as
> is.
>
OK, thanks for explaining.  I don't have any particular remedy in mind now
that I know what's going on behind this.

> longer uses "SHOULD". I think that addresses your issue. Do you disagree?

Nope, we're good here.

> I think the new text is clear, as it explains what appears in the ENABLED
> response the first time ENABLED response is mentioned. So have a look at
> -23 and let me know.
>

Good to go.

> I think IMAP is a bit subtle in places, as NO and BAD have very different
> semantics. "BAD" means that the client shouldn't have tried this. "NO"
> means some other reason why this fails, which can be entirely server
> specific.
>

Thanks!

-24 covers all of the major stuff except the text duplication (nice
work!).  Did we figure out how you'd like to deal with that?  That's not a
Last Call blocker for me -- I'll send -24 if you think it's ready -- but I
wouldn't be surprised if some downstream reviewer or AD makes the same
observation.

-MSK

---

From: Alexey Melnikov <[email-masked]>
Date: Wed, 6 Jan 2021 23:06:04 +0000

Hi Murray,

> On 6 Jan 2021, at 22:53, Murray S. Kucherawy <[email-masked]> wrote:
> 
>> On Tue, Jan 5, 2021 at 5:56 AM Alexey Melnikov <[email-masked]> wrote:

>>>>> Which is the standard for this version of IMAP?  If it’s an implementation choice, I think that’s what this should say.
>>>> Yes, it is.
>>> 
>>> That's fine, then, if this is clarified.  I just found that bit to be self-contradicting as written in -22.
>> I think IMAP is a bit subtle in places, as NO and BAD have very different semantics. "BAD" means that the client shouldn't have tried this. "NO" means some other reason why this fails, which can be entirely server specific.
>> 
> -24 covers all of the major stuff except the text duplication (nice work!).  Did we figure out how you'd like to deal with that?  That's not a Last Call blocker for me -- I'll send -24 if you think it's ready -- but I wouldn't be surprised if some downstream reviewer or AD makes the same observation.

Yes, please start IETF LC on -24 and I fix the rest in -25.

Thank you,
Alexey

---

From: Alexey Melnikov <[email-masked]>
Date: Sun, 24 Jan 2021 12:27:02 +0000

Hi Murray,

Following up on a few little things:

  [snip]

>
>>
>>     Section 6.3.9.2
>>
>>
>>     This section (and the previous) require that \Subscribed be
>>     computed accurately before the response is generated.  How does
>>     this square with the text in Section 6.3.9 that insists replies
>>     come quickly?
>>
>     You have to comply with both :-). It is quite important for
>     \Subscribed to be accurate, so implementations need to do that
>     while maintaining reasonable performance.
>
>
> fast!" from one direction while also doing "You MUST do all this 
> expensive stuff!" from the other with no guidance about how to resolve 
> this.
I will clarify this in the next version.
>
>     [snip]
>>
>>     The second paragraph also gets into the presentation of the
>>     reply.  This is human factors stuff the IETF tends to avoid.  Are
>>     we sure it belongs here?
>>
>     This is copy of the text from another RFC and I personally found
>     this text to be useful when implementing.
>
>
> You might consider putting these presentation advice paragraphs into 
> an appendix too.

Due to a similar comment in SecDir review, I now removed the offending 
text. I think this should address your comment.

Best Regards,

Alexey