Hi Scott et al.,
sorry for proposing the following so late in the discussion. Due to
other duties, my visits to the list were less frequent in the recent
time. Looking at the two options - update of RFC 5733 or an extension -,
I probably would tend to the first option, but I understand the problems
with it.
What I regard as suboptimal in respect to the proposed EPP extension [1]
is the big effort for the little issue (RFC-wise and
implementation-wise), and also using this dummy placeholder [EAI-DUMMY]
in the original <email> XML element (while I know that this has been
done before). For a non-supporting registrar the latter is probably
similarly confusing as an updated RFC 5733. Well, you could argue that
the registry can distinguish supporting and non-supporting clients upon
extensions specified at the login and behave differently. And here comes
my proposal:
As the original email XML element could transport the internationalized
e-mail address XML schema-wise, as mentioned before, why not reduce the
whole extension to a single extension URI without any real EPP extension
in the <extension> section? No schema, no extra data. The presence in
the login would simply indicate: "yes, I can deal with internationalized
e-mail addresses in the <email> element in the contact object", like a
flag. Well, I know that would be a novel way of using extensions, but it
would reduce the implementation effort a lot on the other hand.
Regards,
Klaus
[1] https://tools.ietf.org/html/draft-belyavskiy-epp-eai-01
_______________________________________________
regext mailing list
regext@ietf.org
https://www.ietf.org/mailman/listinfo/regext
