[Technical Errata Reported] RFC5890 (4695)
RFC Errata System <rfc-editor@rfc-editor.org> Tue, 17 May 2016 15:58 UTC
Return-Path: <wwwrun@rfc-editor.org>
X-Original-To: idna-update@alvestrand.no
Delivered-To: idna-update@alvestrand.no
Received: from localhost (localhost [127.0.0.1]) by mork.alvestrand.no (Postfix) with ESMTP id B68CC7C82E5 for <idna-update@alvestrand.no>; Tue, 17 May 2016 17:58:14 +0200 (CEST)
X-Virus-Scanned: Debian amavisd-new at alvestrand.no
Received: from mork.alvestrand.no ([127.0.0.1]) by localhost (mork.alvestrand.no [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EsmgstDFOQPe for <idna-update@alvestrand.no>; Tue, 17 May 2016 17:58:13 +0200 (CEST)
X-Greylist: domain auto-whitelisted by SQLgrey-1.8.0
X-Greylist: domain auto-whitelisted by SQLgrey-1.8.0
Received: from rfc-editor.org (rfc-editor.org [4.31.198.49]) by mork.alvestrand.no (Postfix) with ESMTPS id B3EE77C82DC for <idna-update@alvestrand.no>; Tue, 17 May 2016 17:58:12 +0200 (CEST)
Received: by rfc-editor.org (Postfix, from userid 30) id 74B3D180004; Tue, 17 May 2016 08:58:00 -0700 (PDT)
To: john+ietf@jck.com, ben@nostrum.com, alissa@cooperw.in, aamelnikov@fastmail.fm, vint@google.com
Subject: [Technical Errata Reported] RFC5890 (4695)
X-PHP-Originating-Script: 30:errata_mail_lib.php
From: RFC Errata System <rfc-editor@rfc-editor.org>
Message-Id: <20160517155800.74B3D180004@rfc-editor.org>
Date: Tue, 17 May 2016 08:58:00 -0700
Cc: idna-update@alvestrand.no, juan@sparkpost.com, rfc-editor@rfc-editor.org
X-BeenThere: idna-update@alvestrand.no
X-Mailman-Version: 2.1.16
Precedence: list
List-Id: IDNA update work <idna-update.alvestrand.no>
List-Unsubscribe: <http://www.alvestrand.no/mailman/options/idna-update>, <mailto:idna-update-request@alvestrand.no?subject=unsubscribe>
List-Archive: <http://www.alvestrand.no/pipermail/idna-update/>
List-Post: <mailto:idna-update@alvestrand.no>
List-Help: <mailto:idna-update-request@alvestrand.no?subject=help>
List-Subscribe: <http://www.alvestrand.no/mailman/listinfo/idna-update>, <mailto:idna-update-request@alvestrand.no?subject=subscribe>
X-List-Received-Date: Tue, 17 May 2016 15:58:14 -0000
The following errata report has been submitted for RFC5890, "Internationalized Domain Names for Applications (IDNA): Definitions and Document Framework". -------------------------------------- You may review the report below and at: http://www.rfc-editor.org/errata_search.php?rfc=5890&eid=4695 -------------------------------------- Type: Technical Reported by: Juan Altmayer Pizzorno <juan@sparkpost.com> Section: 2.3.2.1 Original Text ------------- expansion of the A-label form to a U-label may produce strings that are much longer than the normal 63 octet DNS limit (potentially up to 252 characters) Corrected Text -------------- expansion of the A-label form to a U-label may produce strings that are much longer than the normal 63 octet DNS limit (potentially up to 59 Unicode code points or 236 octets) Notes ----- The contents of U-labels are encoded in the up to 59 ASCII characters (see 2.3.2.1 itself) output by the Punycode algorithm in their corresponding A-labels. The Punycode decoder (https://tools.ietf.org/html/rfc3492#section-6.2) consumes at least one of those ASCII characters for each code point inserted into the U-label. An U-label, thus, can contain at the most 59 Unicode code points. Since U-labels are defined (in 2.3.2.1) to be expressed in a standard Unicode Encoding Form, and UTF-32, UTF-16 and UTF-8 (as revised by RFC3629) all can encode a code point in at most 4 octets, 236 octets is an upper bound for an U-label's length. I think it should be possible to derive a tighter bound, but its rationale would likely be less straighforward. I imagine the number 252 was originally derived by multiplying 63, the maximum length of an A-label (including the "xn--" prefix), by 4, the maximum number of octets needed to represent a code point. Instructions: ------------- This erratum is currently posted as "Reported". If necessary, please use "Reply All" to discuss whether it should be verified or rejected. When a decision is reached, the verifying party (IESG) can log in to change the status and edit the report, if necessary. -------------------------------------- RFC5890 (draft-ietf-idnabis-defs-13) -------------------------------------- Title : Internationalized Domain Names for Applications (IDNA): Definitions and Document Framework Publication Date : August 2010 Author(s) : J. Klensin Category : PROPOSED STANDARD Source : Internationalized Domain Names in Applications (Revised) Area : Applications Stream : IETF Verifying Party : IESG
- Re: [Technical Errata Reported] RFC5890 (4695) Martin J. Dürst
- [Technical Errata Reported] RFC5890 (4695) RFC Errata System
- Re: [Technical Errata Reported] RFC5890 (4695) John C Klensin
- Re: [Technical Errata Reported] RFC5890 (4695) Juan Altmayer Pizzorno
- Re: [Technical Errata Reported] RFC5890 (4695) Juan Altmayer Pizzorno
- Re: [Technical Errata Reported] RFC5890 (4695) Juan Altmayer Pizzorno
- Re: [Technical Errata Reported] RFC5890 (4695) Vint Cerf