Latest charter version and TODOs from BOF
Felix Sasaki
fsasaki at w3.org
Tue Mar 18 01:09:01 CET 2008
Lisa Dusseault wrote:
>
> Here's the charter version (at bottom) that went up on the slides
> during the IDN BOF: it's similar to the version that went for
> External Review, but I went ahead and made a few changes that seemed
> to have consensus during External Review (e.g. the name change to
> IDNABIS).
>
> Here are the TODOs on the charter from the meeting:
>
> - Consensus to be more specific which RFCs the new work would
> obsolete, vs update or leave alone
> - Consensus to mention that solving phishing is not in scope (needs
> wordsmithing)
> - Consensus to remove reference to 4690 from charter
> - Revised milestones
>
> TODOs for more list discussion:
>
> - Change the language about separate validity requirements for
> resolution vs registration?
> - Add a tutorial or similar work product?
>
> Lisa
>
> ----
>
> IDNABIS Charter
>
> Chair(s):
>
> TBD
>
> Applications Area Directors:
>
> Lisa Dusseault (ldusseault at commerce.net)
> Chris Newman (Chris.Newman at sun.com)
>
> Applications Area Advisor:
>
> Lisa Dusseault (ldusseault at commerce.net)
>
> Mailing List:
>
> General Discussion: idna-update at alvestrand.no
> To Subscribe:
> http://www.alvestrand.no/mailman/listinfo/idna-update
> Archive: http://www.alvestrand.no/pipermail/idna-update/
>
> Description:
>
> The original Internationalized Domain Name (IDN) WG set the
> requirements for international characters in domain names in
> RFC 3454, RFC3490, RFC3491 and RFC3492 in 2002. These documents
> were tied to Unicode version 3.2 and an update to the current
> version (5.x) is required to accommodate additional scripts.
> In addition, experience has shown a number of real or perceived
> defects or inadequacies with the protocol. Some of them are
> described in an IAB review (RFC4690), which also provides a good
> introduction to the subject matter.
>
> IDNA is currently tied to an old version of Unicode. This WG
> is chartered to untie IDNA from specific versions of Unicode using
> algorithms that define validity based on Unicode properties. It is
> recognized that some explicit exceptions may be necessary in any
> case, but attempts would be made to minimize these exceptions.
>
> Additional goals:
>
> - Separate requirements for valid IDNs at registration time,
> vs. at resolution time
> ??? - Revise bi-directional algorithms to produce a deterministic
> answer whether a label is allowed or not
> ??? - Determine whether bi-directional algorithm should allow
> additional mnemonics labels
> - Permit effective use of some scripts that were
> inadvertently excluded by the original protocols.
>
> The constraints of the original IDN WG still apply to IDNABIS,
> namely to avoid disturbing the current use and operation of the
> domain name system, and for the DNS to continue to allow any
> system to resolve any domain name. The basic approach of the
> original IDN work will be maintained -- substantially new
> protocols or mechanisms are not in scope. In particular, IDNs
> continue to use the "xn--" prefix and the same ASCII-compatible
> encoding, and the bidirectional algorithm follows the same basic
> design.
>
> The IDNABIS WG will work to ensure practical stability of the
> validity algorithms for IDNs.
>
> The work is currently organized (though not constrained in
> organization) as four Standards Track documents. If the WG does
> not come to early consensus around the general direction from
> this charter, the WG will need to stop and recharter so that
> the IETF can understand what the WG proposes to do.
>
> The Overview document with explanation and rationale is intended
> for Standards Track status because it has definitions and
> other normative text required by the other documents. The
> protocol specification explains how to map non-ASCII
> characters into ASCII DNS labels. It relies normatively on
> two other documents that are separate for readability: the
> bidirectional algorithm specification and the character
> validity tables. The validity of characters in IDNs is
> almost exclusively based on Unicode properties but is
> organized as tables and categories for readability.
draft
http://tools.ietf.org/html/draft-faltstrom-idnabis-tables-05#section-4
says that the tables itself are non-normative. If this is still intended
(I vaguely remember some discussion on this between Eric and Patrick), I
would propose to change "organized as tables and categories for
readability. " to
"organized as non-normative tables and categories for readability. " .
Probably "for readability" was meant to express the non-normative status
of the tables as well, but it sounds a bit ambiguous.
Felix
More information about the Idna-update
mailing list