A Protocol for Remotely Managing Sieve Scripts
RFC 5804
Yes
No Objection
Note: This ballot was opened for revision 09 and is now closed.
Lars Eggert No Objection
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.
(Chris Newman; former steering group member) (was Discuss) Yes
(Lisa Dusseault; former steering group member) Yes
(Cullen Jennings; former steering group member) No Objection
(Dan Romascanu; former steering group member) No Objection
(David Ward; former steering group member) No Objection
(Jari Arkko; former steering group member) (was Discuss) No Objection
(Jon Peterson; former steering group member) No Objection
(Magnus Westerlund; former steering group member) (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)
(Mark Townsley; former steering group member) No Objection
(Pasi Eronen; former steering group member) (was No Record, Discuss) No Objection
(Ron Bonica; former steering group member) No Objection
(Ross Callon; former steering group member) No Objection
(Russ Housley; former steering group member) No Objection
(Tim Polk; former steering group member) No Objection
[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 2.2.1.1) 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.