Re: [yam] draft-daboo-srv-email: POP3S/IMAPS?

Sabahattin Gucukoglu <mail@sabahattin-gucukoglu.com> Wed, 20 January 2010 12:59 UTC

Return-Path: <mail@sabahattin-gucukoglu.com>
X-Original-To: yam@core3.amsl.com
Delivered-To: yam@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C38A83A6902 for <yam@core3.amsl.com>; Wed, 20 Jan 2010 04:59:43 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.134
X-Spam-Level:
X-Spam-Status: No, score=-2.134 tagged_above=-999 required=5 tests=[AWL=0.465, BAYES_00=-2.599]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aY5dwC90ecF7 for <yam@core3.amsl.com>; Wed, 20 Jan 2010 04:59:43 -0800 (PST)
Received: from mail-fx0-f215.google.com (mail-fx0-f215.google.com [209.85.220.215]) by core3.amsl.com (Postfix) with ESMTP id ACACB3A688F for <yam@ietf.org>; Wed, 20 Jan 2010 04:59:42 -0800 (PST)
Received: by fxm7 with SMTP id 7so673936fxm.28 for <yam@ietf.org>; Wed, 20 Jan 2010 04:59:36 -0800 (PST)
Received: by 10.223.92.142 with SMTP id r14mr5296362fam.93.1263992375720; Wed, 20 Jan 2010 04:59:35 -0800 (PST)
Received: from ?192.168.1.3? (cpc4-dals7-0-0-cust274.hari.cable.virginmedia.com [62.31.227.19]) by mx.google.com with ESMTPS id p17sm9513733fka.5.2010.01.20.04.59.32 (version=SSLv3 cipher=RC4-MD5); Wed, 20 Jan 2010 04:59:33 -0800 (PST)
Mime-Version: 1.0 (Apple Message framework v1077)
Content-Type: text/plain; charset="us-ascii"
From: Sabahattin Gucukoglu <mail@sabahattin-gucukoglu.com>
In-Reply-To: <F85B667B-B1F9-4065-80A8-C392F7A6C59D@nokia.com>
Date: Wed, 20 Jan 2010 12:59:31 +0000
Content-Transfer-Encoding: quoted-printable
Message-Id: <D6294D81-AC42-4285-AE47-AE0A81F7EDD2@sabahattin-gucukoglu.com>
References: <201001192042.VAA24070@TR-Sys.de> <01NINCMHCJIW004042@mauve.mrochek.com> <4B56C4D8.3090103@gulbrandsen.priv.no> <BB76B773-67C8-416E-871A-358D1CEAE529@nokia.com> <m/STDn1MQ4lECjx6D1UU3A.md5@lochnagar.gulbrandsen.priv.no> <F85B667B-B1F9-4065-80A8-C392F7A6C59D@nokia.com>
To: Lars Eggert <lars.eggert@nokia.com>
X-Mailer: Apple Mail (2.1077)
Cc: Magnus Westerlund <magnus.westerlund@ericsson.com>, Joe Touch <touch@ISI.EDU>, Michelle Cotton <michelle.cotton@icann.org>, yam@ietf.org
Subject: Re: [yam] draft-daboo-srv-email: POP3S/IMAPS?
X-BeenThere: yam@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Yet Another Mail working group discussion list <yam.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/yam>, <mailto:yam-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/yam>
List-Post: <mailto:yam@ietf.org>
List-Help: <mailto:yam-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/yam>, <mailto:yam-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 20 Jan 2010 12:59:43 -0000

On 20 Jan 2010, at 09:36, Lars Eggert wrote:
> thanks for the summary.
> 
> On 2010-1-20, at 11:28, Arnt Gulbrandsen wrote:
> 
>> Lars Eggert writes:
>>> I'm not on the yam list and this is the first message in this thread 
>>> that I was CC'ed on. It seems like you are suggesting changes to 
>>> draft-ietf-tsvwg-iana-ports, but due to the lack of context I'm at a 
>>> loss as to what they are...
>> 
>> Tthe thead in a nutshell: The iana-ports document says "one port for 
>> each purpose" etc.
> 
> yes - as a guideline for *new* assignments. No existing assignment is modified by this document. (Maybe we need to explicitly say this if we aren't already.)
> 
>> IMAP, POP3 and perhaps SMTP, however, exist in two. 
>> 993 ("imaps") and 143 ("imap") for IMAP. Everyone on the list dislikes 
>> port 993. The question is whether port 993 should survive in the IANA 
>> registry.
> 
> It should and it will.
> 
>> My suggestion for the iana-ports document is to permit more than one 
>> port in those cases where that's currently deployed, and apply the 
>> one-port-per-purpose rule only to new allocations.
> 
> Exactly. The intent is not to revisit past assignments and check whether they comply with the new rules.
> 
>> My rationale for that is that the extra ports/service names aren't 
>> really free. You can't use port 993 or service name imaps for anything 
>> else, and IMO that's reason enough to keep it in the registry.
> 
> Exactly.

Deployment consideration is AFAIK the one and only reason to specify this usage.  I'm not asking for a definitive answer, but does the revocation procedure not give us a reason to discourage its usage altogether using at least some warning language?  It might be a flight of fancy, but if in a decade's time the world has migrated to IPSec, for instance, we'll be left with lots of obsolete port assignments and no documentation for them, which IMO is not so good.  Would like to think that, although we must not break existing deployments, we should try to observe current and future reservation guidelines.

Cheers,
Sabahattin