Subject: Recommended ManageSieve TCP port 2000 is already allocated to Cisco SCCP

From: "Alexey Melnikov" <[email-masked]>
Date: Mon, 12 Jan 2009 19:22:32 +0000

On Mon, Jan 5, 2009 at 11:21 PM, Amanda Baber via RT
<[email-masked]> wrote:
> IESG:
>
> IANA has questions about draft-ietf-sieve-managesieve-05.txt:
>
> - This document requests the allocation of a TCP port that has
> already been registered (2000, Cisco SCCP). Should the existing
> registration be changed from "Cisco SCCP" to "ManageSieve"?

Dan,
ManageSieve was invented about 10 years ago and some implementations
used port 2000 (unfortunately without registering it with IANA). How
widely is Cisco SCCP implemented and would be changing the IANA
allocated port number an option for you?

To the WG: how widespread is usage of port 2000 for ManageSieve? Are
people using any other port numbers?

---

From: "Dan Wing" <[email-masked]>
Date: Mon, 12 Jan 2009 11:32:55 -0800

> -----Original Message-----
> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Alexey Melnikov
> Sent: Monday, January 12, 2009 11:23 AM
> To: Dan Wing; [email-masked]
> Subject: Recommended ManageSieve TCP port 2000 is already 
> allocated to Cisco SCCP
> 

SCCP is our proprietary signaling protocol between our VoIP phones
and Unified Communication Manager (formerly called Call Manager),
with somewhere above 6 million IP phones in the field (as of 
2005, 
<http://newsroom.cisco.com/dlls/global/asiapac/news/2005/pr_09-23.html>,
most of which use SCCP.

-d

---

From: Arnt Gulbrandsen <[email-masked]>
Date: Tue, 13 Jan 2009 09:28:27 +0100

Pushing SCCCP out of the way isn't going to work very well... I suggest 
getting a new port (x) and using these rules:

Clients MUST try port x first. If a client gets connection refused on 
the right port number, it MAY try 2000, but in that case it should 
watch out for SCCCP. Sieve banners look like <example>, and always 
contain a line starting with "SIEVE " and one starting with 
"IMPLEMENTATION ". SCCCP banners look like <example>, and always 
<dan?>.

Servers MUST listen to port x, and MAY also listen to 2000 to cater to 
old clients.

Client and server implementers using port 2000 should note that 
some/many old servers and clients have a bug wrt. literals. Sending 
correct literals may cause the peer to detect a "syntax error", and so 
does sending incorrect literals.

Arnt

---

From: Jeffrey Hutzelman <[email-masked]>
Date: Tue, 13 Jan 2009 09:38:13 -0500

--On Tuesday, January 13, 2009 09:28:27 AM +0100 Arnt Gulbrandsen 
<[email-masked]> wrote:

> Clients MUST try port x first. If a client gets connection refused on the
> right port number, it MAY try 2000, but in that case it should watch out
> for SCCCP. Sieve banners look like <example>, and always contain a line
> starting with "SIEVE " and one starting with "IMPLEMENTATION ". SCCCP
> banners look like <example>, and always <dan?>.

Instead of standardizing a multi-port search procedure, I suggest we 
standardize the use of DNS SRV records to discover managesieve servers.

-- Jeff

---

From: Arnt Gulbrandsen <[email-masked]>
Date: Tue, 13 Jan 2009 15:55:10 +0100

> standardize the use of DNS SRV records to discover managesieve 

I thought so too, but I couldn't formulate a good and complete set of 
rules. That's why I haven't suggested that (for a couple of years).

The best I could come up with is:

1. Get a port (x) from IANA.
2. Servers listen to port x by default, but must be configurable to use 
another port.
3. Clients do an SRV lookup for _managesieve._tcp.target and fall back 
to target port x if no SRV record is found.

It's possible to make old clients work (except for the literal/literal+ 
problem) by pointing at port 2000 in the SRV record. But I'm not happy 
enough to really like this solution.

Arnt

---

From: Ned Freed <[email-masked]>
Date: Tue, 13 Jan 2009 06:59:26 -0800 (PST)

> standardize the use of DNS SRV records to discover managesieve servers.

Excellent idea. I strongly support doing this.

				Ned

---

From: "Alexey Melnikov" <[email-masked]>
Date: Tue, 13 Jan 2009 15:02:37 +0000

On Tue, Jan 13, 2009 at 2:59 PM, Ned Freed <[email-masked]> wrote:
>> > the

The latest ManageSieve draft already does that ;-).

---

From: Arnt Gulbrandsen <[email-masked]>
Date: Tue, 13 Jan 2009 16:07:28 +0100

> The latest ManageSieve draft already does that ;-).

Did you use the text I suggested ages ago? I had misgivings later...

Arnt

---

From: "Alexey Melnikov" <[email-masked]>
Date: Tue, 13 Jan 2009 15:11:36 +0000

> Did you use the text I suggested ages ago? I had misgivings later...

I don't remember which version I've used. Please review the latest draft.

---

From: Ned Freed <[email-masked]>
Date: Tue, 13 Jan 2009 07:22:28 -0800 (PST)

> The latest ManageSieve draft already does that ;-).

Sorry, forgot that was in there.

Given that support for SRV records is already required, old servers that are
listening on port 2000 can be made to work with a new client that defaults to a
different port simply by adding an appropriate SRV record. And an old client
that goes straight to port 2000 on the named server isn't going to interoperate
with a new SRV-dependent setup anyway. So I see no compelling reason to
continue to mess around with port 2000. Let's just get a new port assigned, put
it in there and be done with it.

				Ned

---

From: Troy Benjegerdes <[email-masked]>
Date: Tue, 13 Jan 2009 09:33:27 -0600

> standardize the use of DNS SRV records to discover managesieve servers.

I would second the DNS SRV record approach. It would be quite convenient
to have a MUA that used DNS SRV records to find it's IMAP, SMTP-MSA,
and Managesieve servers.

---

From: Cyrus Daboo <[email-masked]>
Date: Tue, 13 Jan 2009 10:49:55 -0500

Hi,

--On January 13, 2009 7:22:28 AM -0800 Ned Freed <[email-masked]> 
wrote:

> Given that support for SRV records is already required, old servers that
> are listening on port 2000 can be made to work with a new client that
> defaults to a different port simply by adding an appropriate SRV record.
> And an old client that goes straight to port 2000 on the named server
> isn't going to interoperate with a new SRV-dependent setup anyway. So I
> see no compelling reason to continue to mess around with port 2000. Let's
> just get a new port assigned, put it in there and be done with it.

+1

-- 
Cyrus Daboo