Of course. But you do that by joining the IDN list and participating in the
discussion there, not by holding a separate discussion elsewhere. I hope
most
of the people interested in this topic have already done this; I certainly
have.
Indeed, but I am already on as many of these lists as I can handle :-( .
Then I suggest you consider your priorities.
This would be reasonable if there was consensus on the basic approach to the
problem and all that was being argued were the details. But there isn't
(quite)
a consensus yet, so it is impossible to be sure what the eventual solution
is
going to look like. And while I think it highly unlikely, it is possible
that
the eventual solution will be done as another layer and email addresses at
the
RFC2821/RFC2822 level won't change at all. There certainly is a proposal on
the
table with this characteristic.
Hmmm! It looks as though I will have to wait until the dust settles a
little. I am assuming that it will finally take the form of some encoding
into ASCII that will satisfy the present addr-spec syntax. But my concerns
are:
I suspect you're right, but it is nevertheless premature to move any
distance down this path.
1. There are too many encoding schemes around already; one hopes that
they will come up with something identical to, or readily adaptable from,
one of the existing ones.
Very unlikely, since the constraints on this particular encoding problem
are quite different from the constraints that have produced other
encodings.
2. That there should only be ONE way to encode a given domain name (or
local-part, for that matter). Or, if there is more than one, that
transports should be forbidden to reencode them en route. My concern here
is that an address may have been included within something that has been
digitally signed, and the signature may get broken. This is likely to be a
serious issue in the case of News.
It is safe to assume that there will be a single canonical form and you
certainly will be required to use it. The DNS isn't going to do
canonicalization for you. So this is not a concern in regards to IDN.
However, a single encoding is not sufficient. Regardless of the encoding
chosen, people will send stuff that's incorrectly encoded and people will want
to fix it up. And forbidding canonicalization midstream has been tried in the
past, and in practice has proven to be a complete waste of time. You can write
as many standards as you like and bellow about this all you want, but when a
vendor is faced with the alternative of propogating something that's broken and
which results in a downstream failure and fixing that something so it works,
the choice the vendor will make is the latter. Customers demand solutions and
don't care about standards violations, and if they cannot get satisfaction from
one vendor who behaves in a purist way they will switch to another that
doesn't.
This is why RFC2822 took the approach it does. Don't expect anything different
to arise as a result of the IDN work.
3. That they are also concerned about these same things.
They are.
See my concern #1. They should produce something that covers BOTH sides at
the same time.
Given that the constraints on the RHS are far more stringent, this is already
covered. And again, there are plenty of people involved in the iDN effort who
are well aware of the need to extend their result to email addresses, so any
issue that does arise should be dealt with.
Ned