IDNABIS AGENDA

IETF 75

Stockholm

Agenda

     Agenda Bashing

    Principles + Objectives (brief) - Cerf

    Mapping (Resnick)

      Specific Mapping rules

      Normative or informational reference?

    Tables Update - Faltstrom

    BiDi Update - Alvestrand  

    Outline of required changes to Defs, Protocol, Rational - Klensin

Principles + Objectives

    We need to finish this work now

    A-label/U-label correspondence must be preserved as a key

      element of IDNA2008

    No amount of mapping, contexting or restricting will absolutely

    prevent phishing or confusion. Nor can those measures force

    absolute consistency among system or between applications

    on the same system.

Principles + Objectives (2)

    We have to rely on zone administrators ("registries") to be

    thoughtful and on implementors of applications that call

    on DNS lookup functions to exercise good, balanced

    judgment about protecting their users while providing

    maximum flexbillity.

    Corollary: some zone administrators will be anywhere from

    negligent to deliberately abusive.

Mapping

    If mapping happens during the registration process, the

    registrant needs to see the resulting domain name

    (which must be valid in accordance with IDNA2008

    specifications)

    If mapping is done on lookup, strings must be in valid

    IDNA2008 form after any mapping

    We are NOT trying to be conformant to IDNA2003

    We ARE seeking to reduce user surprise (principle

    of reduced astonishment)

       - Width mapping

       - Upper case to lower case maping

       - NFC form

    General consensus: the case/width/NFC mapping

    before lookup is not MUST; might be SHOULD or

    MAY or simply advice.