Extended URLFETCH for Binary and Converted Parts
RFC 5524

[Ballot comment]
I suggest to explain or expand what is URLAUTH and URLFETCH at the start of the document. The terms are being used in the title, Anstract and then body of the document without any explanation.

[Ballot discuss]
The Gen-ART Review by Pete McCann includes a concern with the ABNF:
  >
  > I could not parse the ABNF as some productions seemed to be missing;
  > I looked for them in the referenced documents RFC 3501, RFC 3516,
  > and RFC 4467.  Specifically, I cannot find a definition for
  > "url-meta-bodystruct", "url-meta-body", or "url-meta-binary".
  > Did you mean for the last three productions ("url-bodystruct",
  > "url-binary", and "url-body") to have the word "meta" in them?
  > Those three seem to be unused elsewhere, and fit the examples given
  > earlier.  Or, did I just miss the definitions from somewhere else?
  > In that case, it might be nice to have a pointer to where the
  > production is actually defined, in a comment within the ABNF.

IANA Last Call comments:

Upon approval of this document, the IANA will make the following
assignment in the "IMAP 4 Capabilities" registry at
http://www.iana.org/assignments/imap4-capabilities

Capability Name Reference
-------------------------- ------------------
URLFETCH=BINARY [RFC-cridland-urlfetch-binary-03]

We understand the above to be the only IANA Action for this
document.

(1.a) Document Shepherd: Eric Burger, eburger@standardstrack.com,
personally reviewed this document. This document is ready for
publication.


(1.b) Work group review: The lemonade work group provided review of
this document. Note that despite the file name of the draft, this is
a work group document.


(1.c) Further review required: This document does not need further
specialized review.


(1.d.i) Document Shepherd Comfort Level: High

(1.d.ii) Document Useful and Needed: Yes

(1.d.iii) IPR Disclosures: None known


(1.e) WG Consensus: Consensus on publication and contents. Good
discussion by work group, including comments by most of the group,
including Mark Crispin, Greg Vaudrueil, Arnt Gilbrandsen, Ken
Murchison, and Neil Cook. There was discussion about combining this
document with the original URLFETCH document, RFC 4467. However, the
consensus was to leave that task for when these documents are ready
for DS.


(1.f) There are no members with objections or concerns. There are no
threats of appeal or process issues.


(1.g) ID-nits: Checked and verified with idnits 2.8.10

The intended status for this document is Proposed Standard.


(1.h) References: Normative and Informative references check.

RFC Editor Note: Ok to reference -19 of draft-ietf-lemonade-convert
and -05 of draft-ietf-lemonade-streaming. Both of those documents
should get RFC numbers soon.


(1.i) IANA Considerations: Present and correct. As there is a
registration, the RFC Editor can remove the statement, "This document
has no actions for IANA."


(1.j) ABNF: Validated with Bill Fenner’s ABNF on-line checker.


(1.k) Document Announcement:


Technical Summary


The URLFETCH command defined as part of URLAUTH provides a mechanism
for third-parties to gain access to data held within messages in a
user's private store, however, this data is sent verbatim, which is
not suitable for a number of applications. This memo specifies a
method for obtaining data in forms suitable for non-mail applications.


Working Group Summary


There is consensus in the WG to publish this document.



Document Quality


The Lemonade WG has reviewed the document.


The document has been checked manually and using idnits 2.08.10, and
passed both checks.


Eric Burger shepherds this document, has reviewed this document, and
believes that this version is ready for forwarding to the IESG for
publication.