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

Alfred Hönes <ah@TR-Sys.de> Tue, 19 January 2010 20:42 UTC

Return-Path: <A.Hoenes@TR-Sys.de>
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 BD65E3A696B for <yam@core3.amsl.com>; Tue, 19 Jan 2010 12:42:28 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.559
X-Spam-Level:
X-Spam-Status: No, score=0.559 tagged_above=-999 required=5 tests=[AWL=-0.692, BAYES_00=-2.599, CHARSET_FARAWAY_HEADER=3.2, HELO_EQ_DE=0.35, MIME_8BIT_HEADER=0.3]
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 6gqaFzXFYBTG for <yam@core3.amsl.com>; Tue, 19 Jan 2010 12:42:27 -0800 (PST)
Received: from TR-Sys.de (gateway.tr-sys.de [213.178.172.147]) by core3.amsl.com (Postfix) with ESMTP id C2E563A6874 for <yam@ietf.org>; Tue, 19 Jan 2010 12:42:26 -0800 (PST)
Received: from ZEUS.TR-Sys.de by w. with ESMTP ($Revision: 1.37.109.26 $/16.3.2) id AA209203732; Tue, 19 Jan 2010 21:42:13 +0100
Received: (from ah@localhost) by z.TR-Sys.de (8.9.3 (PHNE_25183)/8.7.3) id VAA24070; Tue, 19 Jan 2010 21:42:11 +0100 (MEZ)
From: Alfred Hönes <ah@TR-Sys.de>
Message-Id: <201001192042.VAA24070@TR-Sys.de>
To: yam@ietf.org
Date: Tue, 19 Jan 2010 21:42:11 +0100
X-Mailer: ELM [$Revision: 1.17.214.3 $]
Mime-Version: 1.0
Content-Type: text/plain; charset="hp-roman8"
Content-Transfer-Encoding: 8bit
X-Mailman-Approved-At: Tue, 19 Jan 2010 13:17:48 -0800
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: Tue, 19 Jan 2010 20:42:28 -0000

Please note that the Transport Area is in the process to update
the Port Numbers IANA registry -- see:
  <http://tools.ietf.org/html/draft-ietf-tsvwg-iana-ports-04>

In pursuit of long-standing IESG recommendations, the new unified
Service Names and Port Numbers registry will no longer allow
multiple port numbers to be registered for a single conceptual
service (and different service names for variants of a service),
and it intends to start applying the new policy on legacy registry
content during the planned (annual?) "garbage collection" phases
that IANA will conduct in the future.
So unless a specific use case can be shown to be supported by a very
strong momentum, the registry garbage collection phases will perhaps
some day start challenging the service name registrations and default
port assignments for 'imaps' and similar "services over TLS" that do
not use in-band security negotiation on the same port number as the
basic service and hence do not conform to the new registry rules for
service names and default port number assignment.

That draft says in the description of the new rules (Section 7.2):

   The process and protocol identifier use suggests that anything a
   single process can demultiplex, or that can be encoded into a single
   protocol, should be.  The firewall filtering use suggests that some
   uses that could be multiplexed or encoded must be separated to allow
|  for firewall management.  Note that this latter use is much less
|  sound, because port numbers have meaning only for the two endpoints
|  involved in a connection, and drawing conclusions about the service
|  that generated a given flow based on observed port numbers is not
|  always reliable.  Further, previous separation of protocol variants
|  based on security capabilities (e.g., HTTP on port 80 vs. HTTPS on
|  port 443) is not recommended for new protocols, because all should be
|  security-capable and capable of negotiating the use of security in-
|  band.

Please read draft-ietf-tsvwg-iana-ports-04 and comment on the
TSVWG list, if you want.  Releated discussion also happend on the
apps-discuss at ietf dot org mailing list.

Conclusion:

It might be worth adding a strong note to your draft that again
discourages further use of email-related "<someservice->s" service
names and related default port numbers.


Kind regards,
  Alfred Hönes.

-- 

+------------------------+--------------------------------------------+
| TR-Sys Alfred Hoenes   |  Alfred Hoenes   Dipl.-Math., Dipl.-Phys.  |
| Gerlinger Strasse 12   |  Phone: (+49)7156/9635-0, Fax: -18         |
| D-71254  Ditzingen     |  E-Mail:  ah@TR-Sys.de                     |
+------------------------+--------------------------------------------+