Draft: draft-melnikov-imap-ext-abnf-05.txt Reviewer: Elwyn Davies [elwynd@dial.pipex.com] Review Date: Tuesday 11/1/2005 5:58 AM CST LC Date: 11/08/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 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.