Background for those on the CC list, who may be unaware of GenART:
GenART is the Area Review Team for the General Area of the IETF. We
advise the General Area Director (i.e. the IETF/IESG chair) by providing
more in depth reviews than he could do himself of documents that come up
for final decision in IESG telechat. I was selected as the GenART
member to review this document. Below is my review, which was written
specifically with an eye to the GenART process, but since I believe that
it will be useful to have these comments more widely distributed, others
outside the GenART group are being copied.
Document: draft-melnikov-imap-ext-abnf-05.txt
Intended Status: Proposed Standard (Individual submission via AD)
Shepherding AD: Allison Mankin
Review Trigger: IETF Last Call ending 8 November 2005
Summary:
A slightly odd 'standard' this one. I spent a few minutes wondering why this
wasn't defining any capability names and had a 'null' IANA considerations before
twigging that the majority (originally, back at version -00, all) of this
document was a set of patterns (maybe a 'meta-standard') telling extension
authors that if they needed to add options to certain commands 'do it this
(common) way'. I think this could be spelt out more clearly in the
introduction, but I don't have any objection in principle to the purpose of the
document. It seems to be a useful set of 'class definitions' (in object
oriented terms) that can be instantiated by real extensions and will allow for
commonality in the parser.
However, there is (IMO) an impostor lurking in section 2.7. The extension of
the MULTIAPPEND capability to allow data with embedded nuls is not a class
definition but a real extension. I *think* this needs a capability identifier
to be registered with IANA. In any case it is an update of RFC3502 which is not
mentioned at present. I feel that this extension sits awkwardly with the rest
of the document and it might be better hived off into a separate draft.
In addition, there are a number of minor points and editorial nits that need
fixing up.
I haven't checked the validity of the ABNF in s3.
Review:
The abstract and introduction (to section 2.1) should explain more clearly that
the majority of the document provides a number of standard patterns for adding
options and extensions to standard IMAP commands that are currently and SHOULD
(in the future) be used by any new extensions that needs this sort of
capability, but, except for s2.7, does not define any actual extensions.
Section 2.7 appears to define a real extension and needs (IMO) a capability name.
Issues:
Abstract: As it stands the document updates RFC3502 (MULTIAPPEND) by allowing
for nuls in data (and rewriting the ABNF). This needs to be mentioned.
Abstract: As far as I can understand, the *addition* of the <literal8>
production does not update RFC2088 but merely draws on the syntax used to define
a similar format. I think RFC2088 can be removed from the list of updated RFCs.
Abstract: The abstract says that RFC2342 (NAMESPACE) is updated by this draft.
If my (manual) parsing of the ABNF is correct, the ABNF is equivalent with just
one extra 'convenience' production added in to make the display clearer. Does
this *really* constitute an update? The *usage* of the namespace-response in
the alternative mailbox-data rules doesn't seem to update RFC2342, but rather
(probably) require that the server had this capability to be able to support
this option. Maybe this needs some extra explanation.
s2: This list of updated RFCs (not including RFC2088) should be reiterated and
given as references.
s2.1: Needs some pointers to the pieces of RFC3501 that are updated (as in s2.2
etc).
s2.6: Should there be a section describing the namespace-response as a new
alternative response (as with the ESEARCH response)? The introduction of RFC2342
stuff is not otherwise talked about except in the ABNF.
s2.6.1: According to the ABNF comments, the response to SEARCH should be exactly
one instance of either a SEARCH response or an ESEARCH response... I think the
'Responses' line in s2.6.1 should be saying this. The 'footnote' attached to
the SEARCH response is not very clear .. it should probably say explicitly that
the ESEARCH response is a possibility and that there should be exactly one
response (i.e., SEARCH and ESEARCH responses are mutually exclusive).
s2.7: This section should have a ref to [MULTIAPPEND] (RFC3502). It should
probably also remind implementers that it interacts with RFC2359 (and now
2359bis). As stated above I believe that this is defining an actual capability
and needs a capability identifier.
s4: The extra security considerations in RFC2342 also apply.
s5: There may be IANA considerations if my view on s2.7 is correct.
Editorial nits:
===============
global: s/don't/does not/
global: s/can't/cannot/
s2.1, para 1: s/behaviour/behaviours/
s2.1, bullets: s/effects/affects/ (2 places)
s2.1, bullet 2: s/For/for/
s2.6.1: s/define any result option/define any result options/
s2.6.2: s/is immediately followed by/may contain/
s2.6.2: s/missing than/missing then/
s2.6.2: s/if it is present than/whereas if it is present/
s2.6.2: s/is referring/refers/ (2 places)
[Paras 3 and 4 of s2.6.2 should then read:
The ESEARCH response may contain an optional search
correlator. If it is missing then the response was not caused by a
particular IMAP command, whereas if it is present it contains the tag
of the command that caused the response to be returned.
The search correlator is followed by an optional UID indicator. If
this indicator is present, all data in the ESEARCH response refers to UIDs,
otherwise all returned data refers to message numbers.
]
s6.1: [ABNF] - The new version has been published as RFC4234.
_______________________________________________
Gen-art mailing list
[email protected]
https://www1.ietf.org/mailman/listinfo/gen-art
