Subject: Re: [regext] Use of Internationalized Email Addresses in EPP protocol: placeholder value

From: "Gould, James" <[email-masked]>
Date: Mon, 2 Aug 2021 18:22:34 +0000

Patrick,

We had a discussion in the WG related to the options for adding EAI support to EPP, and the end result was a functional extension with signaling via the greeting and login services and a definition of the functional behavior.  I do agree that the use of placeholder text is not a preferred approach in general, but there are times that it's the simplest and least impactful.  As long as we can define the expected  functional behavior, we're looking at the options to support a mix of EAI-support by the client and the server.  You can reply to my reply to Thomas Corte with your thoughts on how best to handle it.    

Thanks, 

-- 
 
JG

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

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

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

On 8/2/21, 1:02 PM, "regext on behalf of Patrick Mevzek" <[email-masked] on behalf of [email-masked]> wrote:

    On Mon, Aug 2, 2021, at 08:50, Gould, James wrote:
    > I believe the use of a predefined placeholder value is the best 
    > approach to handle this transition corner case in the protocol, but I 
    > would like to hear viable alternates from the working group to 
    > incorporate into the draft.

    I think I agree with Marco and Ulrich, I was already not happy by us allowing
    to use a placeholder value in login-security extension, and for the exact same reason
    I am not in favor of using another placeholder like that, no matter what it is or where it is.

    Why and what seems better to me?

    We use XML, we use XML namespaces and we version them even. What gain do we
    have with that if we don't leverage it?
    Placeholders are just a symptom of the fact that the current schema are not aligned
    with our current needs. This is "normal", EPP is old now, it has to change to adapt
    to current real life. Being blocked in old schemas is just technical debt, that we
    try to "encapsulate" by now putting "dummy" (another term for placeholder) values
    in places where the schema does not fit our needs. This lowers the value of using
    a schema in the first place.

    Yes, introducing contact-2.0 will be a huge task, but it is to me far better and
    fool-proof than using placeholders. We postpone that more and more but we just
    delay the inevitable (which could happen to be as well someone deciding to just
    redo EPP basically under some current in fashion technologies, aka JSON,
    which goal or side effect is exactly to get rid of all schemas and specifications)
    or just continue to fuel the fragmentation with many extensions
    working around deficiencies or missing pieces that should be in "core" schemas.

    Yes, a change like that won't be easy or immediate. Yet, at the same time,
    we currently allow to have, to my count, *18* XML namespace versions of the
    fee EPP extension (including the final 1.0 one which is far from being the most
    used one currently), and again to my count necessarily not exhaustive at least
    7 of them are actively used by registries.
    Major pains for registrars obviously, yet it shows things work when leveraging
    the XML schema versioning, and if we don't then we just enshrine a situation
    with as many EPP as they are registries, each one using their own specific extensions,
    which makes "core" EPP basically unusable anywhere as is.

    Like in all other cases, I think it could help guide the discussion, if registries
    and registrars would come forward telling they are interested to implement this
    discussed extension or if they do not, why? That would allow to make sure the
    extension is designed to cover as many similar cases as possible, to lower
    risks of fragmentation.

    Also all of this is obviously related to Universal Acceptance, and at least in gTLD
    world, ICANN has a specific team/workgroup on that subject.

    -- 
      Patrick Mevzek
      [email-masked]

    _______________________________________________
    regext mailing list
    [email-masked]
    https://secure-web.cisco.com/1tMBalr9tX3JkHKwstKAAu0fCjd-THnSXtcfVgtZhw9BtM_sn61tCcqc1j68N9Nyk11VbCYgBD_dIVCUV_S8rvADNFtb03CpBayZ2kxDDGXHgEI3X00CA_APe6J9H_c8_LL0k4IVjmWGFgbQkv2y9wePBasLMqDSA3ZKuqT1P9nzMck0yqpLRYNMAadknHdE6pz6UGcBqppK95mTYewQPuMpn07iZen6w9jx5NbZVqGsoVy-zSoijcgCwreHtUiSJ/https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fregext

---

From: "Patrick Mevzek" <[email-masked]>
Date: Mon, 02 Aug 2021 13:32:18 -0500

On Mon, Aug 2, 2021, at 13:22, Gould, James wrote:
> You can reply to my reply to 
> Thomas Corte with your thoughts on how best to handle it.    

As stated, I am personally not seeing using a placeholder to be a good direction,
so I can not really help in that way and I would prefer the WG to concentrate
on alternate directions, as difficult as they might be. Just a personal view.

Also, I am still curious to roughly know which registries have interest to 
deploy this extension as it is currently. I think this should help defining if this
would be "Standards Track" or "Informational".
Without any clear signal we would have just to infer things based on who interacts
on the subject and opinions expressed. And right now I don't see a clear signal
on going ahead with placeholders, the discussion seems pretty mixed on the issue.

-- 
  Patrick Mevzek
  [email-masked]