A Protocol for Remotely Managing Sieve Scripts
Note: This ballot was opened for revision 09 and is now closed.
(Lisa Dusseault) Yes
(Chris Newman) (was Discuss) Yes
(Jari Arkko) (was Discuss) No Objection
(Ron Bonica) No Objection
(Ross Callon) No Objection
(Lars Eggert) No Objection
Comment (2009-01-15 for -)
Section 1.9., paragraph 0: > 1.9. Link Level > > The ManageSieve protocol assumes a reliable data stream such as that > provided by TCP. I think you want to make TCP support for ManageSieve REQUIRED. (Also, nit, "Link Level" isn't the greatest section name for this - maybe "Transport"?) Section 1.9., paragraph 1: > When TCP is used, a ManageSieve server typically > listens on port 2000. [[anchor7: IANA registration of port 2000 is > pending.]] Port 2000 is unavailable, but I see Chris is holding the DISCUSS.
(Pasi Eronen) (was No Record, Discuss) No Objection
(Russ Housley) No Objection
(Cullen Jennings) No Objection
(Jon Peterson) No Objection
(Tim Polk) No Objection
Comment (2009-01-15 for -)
[Sorry for the long winded comment that follows, but I noticed in the gen-art email thread that this anchor was specifically left in to prompt my feedback. Just trying to be responsive!] Anchor9 highlights Chris Newman's observation on differences between the specifications and existing practice for wildcard matching when performing the server identity check. The PKIX wg spent some time discussing this problem at the Philadelphia IETF. To paraphrase the minutes: Wildcards in DNS names in certificates are commonly supported, both in terms of certificates issued by some major CAs and in platforms processing them, but it has never been acknowledged in PKIX standards. 2818 allows wildcards, but inconsistently with some common platforms (e.g., Windows). Note also that 2818 is Informational, not standards track. Also, TLS is used in many other environments, and these environments can write standards to address this issue in their context. Basically, I agree with Chris that wildcard matching is supported on many platforms, including the scenario where the CN contains the server identity (Section 2.2.1, Rule 3.) However, there is no specific standard to reference that accurately describes the behavior of existing clients, since that processing is not uniform. This is unfortunate, but there are so many legacy implementations that developing a standard seems unlikely at this point. Given that, the text (in sections 2.2.1 and 22.214.171.124) as written seems reasonable and complete. It establishes clear and unambiguous expectations for this context. I would also note that the matching rule used here is less complicated than that in 2818. (2818 permits matching substrings in a domain name: "f*.com matches foo.com but not bar.com". Personally, I do not think that is a very useful feature.) One change you *might* consider is relaxing rule 3 and permitting wildcard matches in the CN, since this is permitted by 2818. One last thing: I support Pasi's request for text in the Security Considerations highlighting TRANSITION-NEEDED.
(Dan Romascanu) No Objection
(Mark Townsley) No Objection
(David Ward) No Objection
Magnus Westerlund (was Discuss) No Objection
2.3. LOGOUT Command The client sends the LOGOUT command when it is finished with a connection and wishes to terminate it. The server MUST reply with an OK response and terminate the connection. The server MUST ignore commands issued by the client after the LOGOUT command. Example: C: Logout S: Ok <connection terminated> To reduce the TCP Timed-wait loading on the server, wouldn't it be smarter to have the client close the TCP connection upon receiving the response? Section 4: number = 1*DIGIT ;; A 32-bit unsigned number. ;; (0 <= n < 4,294,967,296) Why isn't the number of digits restricted? Because clearly a 32-bit unsigned number will never need more than 10 DIGITs, thus the construct would make more sense as: number = 1*10DIGIT ;; A 32-bit unsigned number. ;; (0 <= n < 4,294,967,296)