Message Submission BURL Extension
RFC 4468

Note: This ballot was opened for revision 04 and is now closed.

(Ted Hardie) Yes

(Brian Carpenter) No Objection

Comment (2005-09-01 for -)
No email
send info
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:


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.


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.


* 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.

(Margaret Cullen) No Objection

(Bill Fenner) No Objection

Comment (2005-09-01 for -)
No email
send info
draft-ietf-lemonade-burl should use the ABNF from 3986, in which 'absoluteURI' is spelled 'absolute-URI'.

(Sam Hartman) (was Discuss) No Objection

(Scott Hollenbeck) (was Discuss) No Objection

Comment (2005-08-30)
No email
send info
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.

(Russ Housley) (was Discuss) No Objection

Comment (2005-09-01)
No email
send info
  In draft-ietf-lemonade-urlauth-07, the [RANDOM] reference should
  point to RFC 4086.

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

  In draft-ietf-lemonade-urlauth-07, section 2 says:
  > ";URLAUTH=<access>:<mech>:<token>" 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 <access> portion 
  > provides the authorized access identifiers which may constrain the
  > operations and users that are permitted to use this URL.  The <mech>
  > portion provides the authorization mechanism used by the IMAP server
  > to generate the authorization token that follows.  The <token>
  > 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.

(David Kessens) No Objection

(Allison Mankin) No Objection

(Jon Peterson) No Objection

(Mark Townsley) No Objection

(Bert Wijnen) No Objection

(Alex Zinin) No Objection