Hi,
I suggested some wording changes several months ago (new wording in
sections 3 and 6.2). It took me several tries to put together that wording,
and I quite like it: I think the database check requirement takes care of
John's worries in a practical way.
Arnt
I fail at writing anything involving alternate addresses. My
problem is that I think that if someone wants to use EAI and is
required to supply an ASCII alternative, then there's a decent
chance that they'll forward the ASCII alternative to their EAI
address.
Which implies that if you can't send email to an EAI address,
want to communicate with the registrant and do it by sending
mail to an ASCII forwarding address, communication will break
down as soon as the registrant replies. That's feeble
compatibility. A compatiblity feature should provide more than
that, or else it should IMO be dumped.
I see four options, and three of them are poor.
1. "EAI users MUST supply an ASCII address and MUST prefer
ASCII when replying to mail" — unrealistic.
2. "Anyone who wants to send mail to a registrant MUST be able
to receive a reply from an EAI address" — well, if they can
receive, why not send?
3. "Anyone who sends mail to an ASCII alternate MUST be aware
that a reply may not be possible through no fault of the
registrant" — what sort of communication does that enable?
4. "Anyone who wants to send email to a registrant MUST be able
to send mail to EAI addresses"
The last is IMO the only workable option. EAI not that hard.
All the top MTAs support that in their latest version. Postfix
and Exim, Halon and Momentum, O365 and Gmail.
So that's what I suggest.
c>
There is a risk that database layers might inadvertently change
the address and make it undeliverable. That shouldn't happen,
but RFC 8264 hadn't been published yet when e.g. the Oracle
RDBMS was written, so I can see why one might worry about that.
Therefore, I suggest the following new wording for the
transform commands, perhaps at the start of section 6.2:
- snip -
There is some concern that arbitrary user-supplied UTF-8
strings might not be preserved in the registry's database.
Therefore, when the the server stores an EAI address as part of
processing a mutating command such as <create>, it MUST read the
address from the database (in the same way as when processing
<info>), compare the address read with that supplied in the
command using byte-by-byte comparison, and return an error if
there was any discrepancy.
A future revision of this specification is expected to relax
this requirement.
- snip -
Which error should it return? I'm not sure and I don't care.
_______________________________________________
regext mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/regext
