Latest charter version and TODOs from BOF

[Felix Sasaki]

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