Internet Message Access Protocol (IMAP) CATENATE Extension
draft-ietf-lemonade-catenate-05

[Ballot discuss]
I appreciate the excellent work that went into addressing my discuss.
I do have one minor point left which I believe still needs to be
addressed.  Currently when resolving an imap URL the specification
says that plain credentials should be passed to the imap server as
received by the submit server.  I agree this configuration should be
supported.  I agree that this is a reasonable default if the imap
server and submit server are in the same administrative domain.  I'm
not convinced it is a reasonable default if the imap server is an
arbitrary internet server.  I thought I brought this up in the
discussion.  I don't see a message where I was convinced that I was
wrong nor do I see a response to this specific point.

[Ballot comment]
In draft-ietf-lemonade-urlauth-07, the [RANDOM] reference should
  point to RFC 4086.

  In draft-ietf-lemonade-urlauth-07, section 2 says:
  >
  > ";URLAUTH=::" (the URLAUTH) MUST be at the end
  > of the URL.
  >
  This seems awkward to me.  I suggest:
  >
  > The URLAUTH is comprised of ";URLAUTH=::".
  > The URLAUTH MUST be at the end of the URL.

  In draft-ietf-lemonade-urlauth-07, section 2 says:
  >
  > ";URLAUTH=::" indicates the access identifiers
  > which are permitted to use this URL, the authorization mechanism, and
  > the authorization token.
  >
  This also seems awkward to me.  Building on the previous suggestion,
  I propose:
  >
  > The URLAUTH is composed of three parts.  The  portion
  > provides the authorized access identifiers which may constrain the
  > operations and users that are permitted to use this URL.  The
  > portion provides the authorization mechanism used by the IMAP server
  > to generate the authorization token that follows.  The
  > portion provides authorization token.

  In draft-ietf-lemonade-urlauth-07, section 6 says:
  >
  > (see below for more details about the URLMECH status response code).
  >
  Please provide a forward pointer to the section where this can be found.

[Ballot discuss]
In draft-ietf-lemonade-urlauth-07, Status of this Memo, the document
  says:
  >
  > A revised version of this document will be submitted to the RFC
  > editor as an Informational Document for the Internet Community.
  >
  This document is being recommended for standards-track.  Do the
  authors have other expectations?

  In draft-ietf-lemonade-urlauth-07, section 2, the definition of
  "access identifiers" is unclear.  In my COMMENT, I have suggested a
  clarification based on my reading of the document.  I could easily
  have gotten something wrong, and I will accept any rewording that
  makes the meaning clear.

  In draft-ietf-lemonade-urlauth-07, section 2, the document says:
  >
  > The "submit+" access identifier, followed by a userid, indicates ...
  >
  and
  >
  > The "user+" access identifier, followed by a userid, indicates ...
  >
  Neither "submit+" and "user+" are authorized access identifiers, as
  they are not a complete  portion of the URLAUTH.  Perhaps
  these should be called authorized access identifiers prefixes.

  In draft-ietf-lemonade-burl-02, section 8,  the document says:
  >
  > To address this expectation, the message submission server should use
  > STARTTLS or a mechanism providing equivalent data confidentiality when
  > fetching the content referenced by that URL.
  >
  Is there a reason that this text says "should" instead of "SHOULD"?

[Ballot comment]
Some curious text in the "status of this memo" section of -urlauth-07:

    A revised version of this document will be submitted to the RFC
    editor as an Informational Document for the Internet Community.

    A revised version of this draft document will be submitted to the RFC
    editor as a Proposed Standard for the Internet Community.

Gen-ART review comments from Lakshimnath Dondeti, for
consideration if there are new versions:

BURL
-------

No additional issues other than those on the tracker already.

What does BURL stand for?

There are some typos toward the end of the security considerations section.  Please run a spell check.  Also, the RFC ed process will take care of it too.

Lemonda-Catenate:
------------------------

Note: The author of this draft, Pete Resnick and I are colleagues, however I was not aware of this work until I read the draft for the first time to review it for Gen-ART.

*) I would like to see more in the security considerations section.  I understand that the draft says the proposal does not introduce any threats.  However, this is in contradiction to the BURL draft's sec considerations section.  I think that the first part of that section might be appropriate in this draft as well.

*) The draft says "Responses behave just as the original APPEND command described in IMAP [1]."
But the examples are somewhat inconsistent (may be I am being too picky):
In Example 1:
S: A003 OK catenate append completed

In Example 3:
A003 OK append Completed

In Example 4:
... CATENATE append has failed, one message expunged

Should they all use the keyword APPEND?  Is the keyword CATENATE allowed in responses?  I realize it is allowed in capabilities as specified in Section 5.

URLauth
-----------

* I am uncomfortable with the word Authorization and the mechanisms for it in this draft.  However, it is late in the process to have a philosophical discussion.  Since this is a WG consensus, I can live with it.

  To explain: The first sentence notes that RFC 2192 requires authorization

My reading of that RFC is that it is talking about authenticating a user and then verifying whether the user is authorized to read/read-write.  Authorization comes from local policy and enforced after authenticating the user.

Section 1.4 concerns me.  First, I am not sure I understand the use of HMAC-SHA-1 as an authorization mechanism.  More importantly, the draft only recommends something such as that algorithm and notes that there is no way to change the algorithm without severe consequences.  While HMAC is holding up, there are concerns about SHA-1 already; I am not sure about advancing protocol specs in which algorithms cannot be updated.

[Ballot discuss]
The burl draft does not provide enough information and does not
require a mandatory to implement mechanism such that a submit server
from one vendor is guaranteed to be able to interoperate with an imap
server from another vendor.

Here are examples of missing information:

1) Mandatory to implement authentication mechanism for submit servers
to support when contacting imap servers.

2) How does the submit server log in?  Obvious answers include using
the submit credential with no authorization id or the submit
credential with the authorization ID of the user after submit+/user+.
I think the first option is probably preferable, although it may
involve some imap ickyness.

[Ballot comment]
Some curious text in the "status of this memo" section of -urlauth-07:

    A revised version of this document will be submitted to the RFC
    editor as an Informational Document for the Internet Community.

    A revised version of this draft document will be submitted to the RFC
    editor as a Proposed Standard for the Internet Community.

[Ballot comment]
Some curious text in the "status of this memo" section of -urlauth-07:

    A revised version of this document will be submitted to the RFC
    editor as an Informational Document for the Internet Community.

    A revised version of this draft document will be submitted to the RFC
    editor as a Proposed Standard for the Internet Community.  Discussion
    and suggestions for improvement are requested, and should be sent to
    lemonade@IETF.ORG.

[Ballot comment]
The documents contain normative references to RFC 2234, which has been obsoleted.  It's replacement (draft-crocker-abnf-rfc2234bis) is in the RFC Editor queue.  References to 2234 should probably be replaced with references to 2234bis.

[Ballot discuss]
draft-ietf-lemonade-catenate:
The ABNF in section 5 contains two instances of an illegal character.  The "_" characters in "toobig_response_code / badurl_response_code" should probably be changed to "-" characters.