Re: [regext] [Last-Call] last call reviews of draft-ietf-regext-epp-eai-12 (and -15)

["Gould, James" <[e-mail]>]

John, 

I will address your point (5), based on the prior thread that we had back in May (https://mailarchive.ietf.org/arch/msg/regext/G08akVkCjnXEPw8k7NiCHbeEamo/), where I stated:

I don't agree that section 2.7 of RFC 5730 defines the only forms of extensibility that can ever be supported by EPP and by defining a new form of extensibility to solve a specific problem in EPP is disallowed or non-compliant with RFC 5730.  In this case, the form of extensibility (Functional Extension) is formerly defined in draft-ietf-regext-epp-eai for clarity for use in solving the specific problem of EAI in EPP.  The intent is not to define a new form of extensibility to EPP in RFC 5730 to solve other similar problems.  I agree if a Functional Extension is meant to be a new formal form of extensibility for use in other yet to be defined EPP extensions, then it would make sense to define it in a draft by itself, but that is not the case with draft-ietf-regext-epp-eai.

Thanks,

-- 
 
JG



James Gould
Fellow Engineer
[e-mail] <applewebdata://13890C55-AAE8-4BF3-A6CE-B4BA42740803/[e-mail]>

703-948-3271
12061 Bluemont Way
Reston, VA 20190

Verisign.com <http://verisigninc.com/>

On 8/21/22, 12:25 PM, "John C Klensin" <[e-mail]> wrote:

    Dmitry and James,

    I think several different issues are getting intertwined here,
    some of which rise to the level of principles.  It is clear that
    we are making different assumptions about what is relevant and
    important and almost as clear that we are not going to convince
    each other.  As I said earlier, that is why we pay the IESG the
    big bucks.

    In no particular order:

    (1) I believe that, if you are trying to create an IETF
    standards track protocol that draws on another IETF standards
    track protocol for its motivation, you are obligated to follow
    the specifications of that protocol and associated experience,
    not just pick up its syntax.  In the case of non-ASCII email
    addresses, that includes making all-ASCII addresses available as
    an alternative unless there is great confidence that they will
    not be needed (e.g., for communications within a country using
    that country's major script (and where relevant, language) and a
    restricted set of email providers.  Such a restriction might
    actually be reasonable within a constrained business
    transaction, especially when registrant, registry, registry, and
    the domain itself primarily serve a particular country or
    cluster of countries (see below).  

    The IETF and its predecessors have carefully avoided specifying
    MUA, especially MUA-UI, behavior for well over 40 years.  In
    that context, the key difficulty with non-ASCII addresses may
    not be easily discerned from our specifications.  However, as
    the EAI WG understood from the beginning, transporting non-ASCII
    addresses across the Internet,in message header formats, even
    delivery status notification (DSN) messages, is fairly easy.  It
    is especially easy by comparison to actually designing and
    building software that interacts with users across a very broad
    range of languages and writing systems.  The usual solutions are
    to either give up on that quality of MUA/UI-UX design and
    instead design for a particular language community or small
    cluster of them, but that leaves messages that use, or embed
    addresses in, other languages and scripts in need of all-ASCII
    (or some other common/agreed form) in greater or lesser trouble.

    As a different, extreme, and nit-picky, example of where this
    specification has failed to appreciate what the
    Internationalized Email specifications say, thse specifications
    for non-ASCII email addresses and headers make it quite clear
    that there are no such things as an "EAI Address" or an "EAI
    extension" and that the correct term is "SMTPUTF8".  That would
    not be important except that IETF specs should not be creating
    confusion by using incorrect terminology (no matter how
    prevalent elsewhere) and because it reinforces the concern that
    the WG may not have paid careful attention to the relevant
    specifications (beyond a citation of syntax) in creating this
    one.


    (2) As Patrik pointed out, there is a community interest (both
    general and in ICANN policy) in making it easy for registrants
    to switch registrars (whether the earlier registrar remains in
    business or not).  For a registrar to treat business
    relationship data that do not affect users, various authorities,
    or elements of the DNS itself, as confidential is entirely
    reasonable. However, usable contact information for registrants
    does not fall into that category but, instead, is information
    registries have been required to have in their possession since
    before there was an ICANN (a principle reaffirmed many times
    since then). 


    (3) Whether a registrant is allowed to supply a non-ASCII email
    address at all and, if they are allowed to do that, whether an
    ASCII alternative should (or must) be supplied is, we are
    agreed, a matter for registry-registrar agreements -- at least
    until national governments, other authorities, or ICANN itself
    step in.  I don't think anyone has suggested that supplying an
    alternative all-ASCII address through the protocol should be a
    requirement imposed by the IETF (certainly I have not).  I
    imagine that the REGEXT WG making a strong recommendation on the
    subject would even be viewed by some as an intrusion on ICANN's
    scope of authority.   However, it is important that the protocol
    be able to accommodate the inclusion and transfer of that
    alternate address information lest someone --perhaps even
    someone acting on behalf of a registrar who believes its
    interests would be served by making transfers difficult-- claim
    in an ICANN forum that such information is unnecessary and
    difficult to provide --and hence should be excluded from
    discussions-- because the IETF decided it was not allowed in the
    protocol.

    (4) To say almost the same thing from a different perspective,
    if the purpose of this specification is to reduce the number of
    incompatible ways in which registry-registrar pairs do things,
    then please recognize that there is a strong possibility (as
    predicted by the SMTPUTF8 specification family), either
    immediately or after experience starts to accumulate, that
    alternate all-ASCII addresses will be required for some
    combinations of actors (before you removed the text, it strongly
    implied just that).  If you allow them in the protocol and data
    structure, then people who need to transmit them will have a
    guide as to how to do so.  If they are not allowed in the
    protocol, they you would be actively encouraging different ways
    of doing things by forcing different arrangements for
    transferring that information.  Given what everyone who has
    studied database theory knows about the dangers of transmitting
    closely linked data in separate pieces it is even more likely
    that they will invent alternatives to this protocol as soon as
    the requirement (or even an option) for transmitting an
    all-ASCII alternative address to the registry arises.

    (5) Finally, there is a procedural issue that seems to have
    gotten lost in the other (particularly i18n) discussions.  The
    base EPP spec [RFC5730] says that there are three ways to extend
    the protocol -- protocol, object, and command-response levels.
    It does not say there can never be additional ways or that other
    ways are not possible but it does say "three ways".   This
    document defines and adds a fourth, a "functional extension".
    No matter how harmless that addition is and even if the WG is
    certain it would never be used for anything other than this
    particular spec (in which case the reasoning should probably
    appear in the spec), that constitutes an update to 5730 that
    should be appropriately reflected in the RFC header and other
    document metadata.  If it really were a change to allow changes
    to the function of EPP (I don't think it is and believe the term
    may be badly chosen), then the community is owed an explanation
    of why the function and/or scope of an Internet Standard is
    being changed as part of what ought to be a fairly minor
    extension.  

    thanks,
        john