Re: [imapext] AD review of draft-ietf-imapapnd-appendlimit-extension-06

[Narendra Bisht <[e-mail]>]

Please find answers in-lined.
We are working on a new version, will update soon.

Thanks & Regards
- Naren

-----Original Message-----
From: imapext [mailto:[e-mail]] On Behalf Of Barry Leiba
Sent: Monday, December 07, 2015 1:24 PM
To: [e-mail]
Cc: [e-mail]
Subject: [imapext] AD review of draft-ietf-imapapnd-appendlimit-extension-06

Here's my AD review of draft-ietf-imapapnd-appendlimit-extension-06.
There are a lot of issues I'd like addressed or discussed with me -- please do discuss anything you don't agree with or feel you need to talk over.  I'm going to put this into "Revised I-D Needed" substate while we work this out.

There's one really substantive issue I have with the protocol (the rest of this is editorial stuff, albeit significant editorial stuff).
The substantive issue is this:  Suppose my server supports APPENDLIMIT, and wants to advertise that to the client, but there's no global limit.  So it says "APPENDLIMIT" in response to CAPABILITY, without giving a number.  Good.  Now you're requiring that there be a limit on every mailbox -- the protocol provides no way to tell the client that there's no limit on this mailbox.  Why is that not a problem?

[Naren] This draft is to publish the APPENDLIMIT, if there is any. If you accept any size then there is no need to publish this policy. 

Overall, this document could use a going-over for proper English -- use of articles, punctuation, that sort of thing.  The RFC Editor will do that, of course, but it'd be good for someone from the working group to do it, to make sure that the meaning remains correct.
There's a lot of editing needed here.  (It also doesn't help that you didn't use the typical tools, such as xml2rfc, which make sure that things are in a common format/layout.)

[Naren] We will provide a xml document going forward.

-- Abstract --

"This memo defines an extension to the IMAP service whereby a server can  advertise its capability, to support maximum mail upload size using  CAPABILITY, STATUS and LIST commands."

We have to stop the "this memo" stuff; please call it a "document".
And the extension isn't about a capability; it's about a policy.  The abstract should say why it's useful to do this, and doesn't need to list what IMAP commands are affected.

I suggest this:

NEW
   This document defines an extension to the IMAP service whereby a
   server can inform a client about a maximum mail upload size,
   allowing the client to avoid sending APPEND commands that will
   fail because the messages are too large.
END

[Naren] Fine

-- Introduction --
IMAP already provides a mechanism for avoiding the overhead of sending too-large APPEND data: synchronizing literals.  The problem that this is meant to resolve is caused specifically when APPEND commands use the non-synchronizing literals extension, and the Introduction should say that.

[Naren] we will address this in the next version.
-- Section 2 --

"An IMAP server that supports APPENDLIMIT extension advertises this by  including the name APPENDLIMIT in its capability list. IMAP server  MAY advertise this capability after user has logged in."

This says nothing about whether the server is allowed to advertise the capability before the user has logged in.  I also don't think this is an appropriate use of 2119 "MAY".  If you mean, "The IMAP server MUST NOT advertise this capability until after the user has logged in,"
then you should say it that way.  (And if that's not what you mean, please discuss it with me and clarify.)

[Naren] We purposefully marked it as a MAY, because it alerts implementations to the possibility, but doesn't have any effect in interoperability.
What we mean here is client should be ready to handle this no matter when the capability is sent.

"APPENDLIMIT capability without any value indicates that the IMAP  server has specific upload limit for different mailboxes."

Isn't it possible that the server might still have the same limit for all mailboxes, but just doesn't know that up front?  Isn't it also possible that the server might have no limit at all for some (or all) mailboxes, but is just indicating support for the extension and
*allowing* for limits?

Maybe this?:

NEW
   The APPENDLIMIT capability without any value indicates that
   the IMAP server supports this extension, and that the client
   will need to discover upload limits for each mailbox, which
   might differ from mailbox to mailbox.
END

[Naren] This is fine
-- Section 3 --

"In this case, client can
 issue STATUS or LIST in combination with STATUS command, if the server  supports LIST-STATUS capability, to get the per mailbox specific limit."

I find this to be a very confusing sentence, perhaps partly because of the punctuation.  But I also think it's not necessary, because you already said (in Section 2) what the client needs to do, and the subsections say what changes are made to the protocol.  So:

NEW
   The following subsections describe the changes to the STATUS and
   LIST commands in support of this situation.
END

[Naren] Fine
-- Section 3.1 --

"IMAP server MUST return the mailbox name that matches the STATUS  specification and the requested mailbox status information."

What does this mean?
Are you saying that the mailbox name is part of the STATUS response?
That's in RFC 3501, and doesn't belong here.  I don't think you need that paragraph at all, unless you're trying to say something else that I don't understand.

[Naren] We will remove the redundant info here.
-- Section 3.2 --
You have "LIST-STATUS" in the section title, but nothing is actually called "LIST-STATUS" (it's just the name of the IMAP capability string that RFC 5819 uses).  I think a better section title here would be
"3.2 STATUS response in the LIST command".  Which would then mean that the previous section title should be "3.1 STATUS response in the STATUS command".

[Naren] Fine, we will change the title accordingly.
"IMAP client can issue LIST in combination with STATUS command to get  the mailbox specific upload value, if the server supports LIST-STATUS  extension."

This is not anything "in combination with STATUS command"; this is using the STATUS return option on the LIST command.  Also, you do need your citation to 5819 here, rather than waiting.

NEW
   If the server advertises the LIST-STATUS capability [RFC5819], the
   client can issue LIST in combination with the STATUS return option
   to get the mailbox-specific upload value.
END

[Naren] Fine.
"IMAP server MUST recognize an extra "RETURN (STATUS (APPENDLIMIT))"
 at the end of a LIST command and emit an extra STATUS response for each  matching mailbox."

There's nothing "extra" here:

NEW
   The IMAP server MUST recognize the APPENDLIMIT attribute and emit
   include an appropriate STATUS response for each matching mailbox.
END
[Naren] Fine
"Refer [RFC5819]
 for the usage of LIST in combination with STATUS command."

You can now eliminate that sentence, because you already have the 5819 citation (above).

"If the server does not support this extension, then client should use  STATUS command instead."

The antecedent to "this" isn't clear.  Say "If the server does not support the STATUS return option on the LIST command, then the client should use the STATUS command instead."

[Naren] Fine
-- Section 4 --

"Client can avoid use of LITERAL+ [RFC2088], when maximum upload size  supported by the IMAP server is unknown."

What?
Don't you mean "The client SHOULD avoid"?  I'd even use this as an opportunity to make it firmer, and say "The client MUST avoid".  No?
If not, why not?

And please don't say "LITERAL+"; please say "non-synchronizing literals".  (We should use capability strings only when we're talking about what's in the CAPABILITY response.)
 [Naren] We will change it to a MUST, as well we will use NSL in place of LITERAL+ 

"STATUS APPENDLIMIT is considered to be fast"

What does that mean?
Is this meant to be advice to the server, to make sure that it *is* fast?  If so, then say it more that way.  If not, then please tell me what it's supposed to mean.

[Naren] It's not an advice to the server, we are trying to convey that this approach is considered to be faster than evaluating the remaining quota for a mailbox.  
-- Section 5 --

"Except as noted otherwise, all alphabetic characters are case-  insensitive."

There's nowhere that it's noted otherwise, so please eliminate that phrase.

[Naren] Ok

"APPENDLIMIT=0 indicates the server SHALL NOT  accept APPEND command due to size restriction."

That's an incorrect use of 2119 "SHALL NOT".  The "due to size restriction" is also a bit odd here.  Also also, I presume you want this to apply to "APPENDLIMIT=0" in the CAPABILITY response and *also* "APPENDLIMIT 0" in the STATUS response, yes?  I would just say this:

NEW
   An APPENDLIMIT number of 0 indicates the server will not accept
   any APPEND commands at all for the affected mailboxes.
END

[Naren] Fine

"The syntax of the
 parameter follows the augmented BNF notation of [RFC5234]."

Why is this here?  Didn't you already say it above?

"If this
 capability is omitted, no information is conveyed about the server's  fixed maximum mail upload size."

Why is this here?  It needs to be in Section 2, not here.

[Naren] ok

-- Section 6 --

"The IMAP APPENDLIMIT extension described in this document can  conceivably be used to facilitate Denial-of-Service attacks.
 Specifically, the information contained in the APPENDLIMIT capability  and use of the APPEND command make it somewhat quicker and easier to  devise an efficacious Denial-of-Service attack."

What?  How?
If it's true (it might be, but you haven't said), then you should explain it.

[Naren] What we meant here is that using this extension it will easy and quicker to get the upload limit and using that limit against the server.

"In addition, no
 issues are addressed involving trusted systems and possible release  of information via the mechanisms described in this document."

What does this mean, and why is it here?

"IMAP APPENDLIMIT extension doesn't add any new security considerations  that are not already present in the base IMAP protocol [RFC3501]."

Doesn't the presence of the first paragraph belie that?

-- Section 7 --

"IMAP4 capabilities are registered by publishing a standards track or  IESG approved experimental RFC.  The registry is currently located at:

 http://www.iana.org/assignments/imap-capabilities

 This document requests that IANA adds "APPENDLIMIT" capability  pointing to this document to the above registry."

You don't need to tell IANA how capabilities are registered, and this is an oddly worded way to do it anyway.  Just ask them to register the
item:

NEW
   IANA is asked to add "APPENDLIMIT" to the IMAP Capabilities
   registry, using this document as its reference.
END

(You can also include the URL if you like, but it's not really needed in this case.)

[Naren] Fine

-- Section 8.2 --
The Section title is malformed (there's a space in "8. 2"), which is what's causing the "missing reference" warning from IDnits.  Please fix that.
[Naren] Sure
--
Barry

_______________________________________________
imapext mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/imapext