Subject: Re: [iDNS] Re: draft-jseng-utf5-00.txt

From: Terry Lambert <[email-masked]>
Date: Mon, 02 Aug 1999 11:53:47 -0700

James Seng wrote:
> 
> Terry Lambert wrote:
> > The multiple registrations issue is really a non-starter
> > for me, since I could argue that Hirugana registrations
> > of Kanji registrations must be made, even in the Unicode
> > case.  I think a fiat that you must use Kanji, or that
> > Kanji and Hirugana machines of the same name are in fact
> > definitionally different names, is fine.
> 
> that is true. but *why* make it more complicated. with RFC2047
> domain names, you not only need to duplicate it for hiragana
> and kanji, multiple this by the number of locale encodings,
> then multiple it by Base64, quoted-printable and UUencoded.
> 
> so to get one domain name in RFC2047 in Chinese, i have to
> register and managed 2 (simp+trad) x 3 (locale encodings) x 3
> 18 zone files. cool, now lets do the sub-delegation of my zone
> erm.., another permuation of 18x. by the 2nd level, it has
> become ridicilous! some languages have more than 10 locale
> encodings and good luck to those.

OK, here's my rationale:

1)	Your requirement for multiple registrations in
	support of a unification via Unicode (or some
	other mechanism) is a strawman.

	The reason this is true is because this particular
	problem is wholly artificial, since it can be
	trivially resolved by an appeal to locale-based
	administrative fiat.  That is, I, as Japan, can
	demand that all registrations of Japanese host
	names registered under .jp take place in ISO-2022-JP.
	Similarly, I as China, can demand that they take
	place in GB-5.

	I think there is a correct argument for Unicode
	as a means of code space unification, based on the
	shared TLD's, and the desire to have physical
	distance between your primary and secondary
	name servers; maybe sufficient distance that you
	place them in different countries.

	For zone transfers between primary and secondary
	name servers, I believe there is a need for a
	codespace unification.

	Discussions about multiple registration requirements
	being the reason for unification are bogus; they
	serve only to detract from your other arguments.

2)	I point at RFC 2047 specifically because of where
	you say the problem space lies: mail headers,
	specifically the restricted alphabet of RFC 821
	(RFC 822 has no such restriction, and the RFC 1034
	restrictions are an artifact of implementation, as
	later RFC's clarify).

	There are no such restrictions on the host names
	themselves; merely on the alphabet available in
	which to express maildrop names.

	If we are talking about satisfying RFC 821 rules
	about maildrop naming, then RFC 2047 is appropriate
	technology.

	The suggestion that one must both "B" and "Q"
	encode domains is inapropriate.  Specifically,
	if we are to try to accommodate legacy systems
	(such as ignorant MUA's or resolvers), then we
	_must_ use "Q" encoding.  Specifically, Base64
	encoding is vulnerable to distortion via case
	folding, whereas you can over-encode characters
	which would be hit by the case folding to protect
	them, using quoted-printable.

	Note:	Since this transformation is suggested
		to be accomplished by a resolver
		supporting legacy applications, there
		is never a situation when the data
		actually encoded in the DNS itself
		should be other than raw, binary data
		in some unified codeset space.

3)	You continue to argue that the email address, and
	in particular, the portion to the left of the "@"
	(at sign), need to somehow be localizable.

	With respect, this is an issue best addressed by
	(and within) the DRUMS working group.

	This issue is not a strawman, per se, but it's
	irrelevent to iDNS, and likewise clouds your
	arguments.

4)	There is already a supported mechanism for putting
	a localized name out as a moniker for an email
	address.

	While I agree that we should be pursuing an iDNS,
	it is a very small distance to travel to say that
	your domain name, or actual email address, being
	limited to a restricted alphabet, is really the
	hardship you make it out to be.  One could make
	the same argument about the use of Arabic numbers
	in IP address tuples.  At some point, domain names
	become abstractions.  It doesn't matter that I
	use an "English" domain name:

	    <A HREF="http://www.example.com/">Example</A>

	So long as the tag "Example" is in the correct
	character set and language.  Likewise, your email
	address is largely irrelevnt:

	    <a href="mailto:?to=[email-masked]">
	    Joe User
	    </a>

	This significantly weakens the supposed need for
	an encoding mechanism that allows you to put email
	addresses themselves into the local language, and
	reduces it to a problem of businees cards and
	advertising media.

> RFC2045-7 are not meant for data processing, and they *never*
> are. no one use MIME for data processing. it is a design as
> a way to encode data content.

It's a method of tunneling data in a non US-ASCII character
set through a transport that has a restricted alphabet.

It seems to me that this does exactly what you are wanting
in order to protect legacy programs, like MUA's.

As a direct side benefit, the use of RFC 2047 encoding
means that RFC 2047 aware MUA's will even do more than
you are asking for: they will, in fact, render the
text in the correct character set, ensuring the intended
visual appearance.

Note: the DNS itself would _not_ store these values encoded,
it would store raw binary data (or should).  The encoding
could be done on the way in (and out) of the resolver code,
which is an intermediation between legacy systems and the
fully international iDNS.

> > Plain old vanilla RFC 821 is very clear:
> 
> i think these are from RFC1034. but lets go on...

RFC 821, Section 4.1.2, page 30...

> > only domains.  Maildrops are not persons.  Locale specific
> 
> IMHO, maildrops are person. [email-masked] my email address.
> and it means as much to me as James Seng. I have a chinese name
> and i would like to have a chinese email address. Consider someone,
> say from rural China area, who has *never* study English,
> [email-masked] is totally unintelligent to him but i am quite
> sure an email like ²ø®¶§»@¹q¶l.¤½¥q.·s¥[©Y is reasonable to him.
> You may not understand this gibberish, but i am sure he can.
> this is the social reason why we are promoting I18N in DNS and
> the next step, is of cos Email. My Email address means a lot to
> you. To put it frankly, I dont really care if my Chinese Email
> doesnt makes sense to anyone in the English world. For them, I
> always have my English email address. But I *want* to have my
> Chinese Email to communicate with my fellow Chinese. And I am
> sure there are a lot of people who feel strongly about their own
> language to want this to happen.

	<a href="mailto:²ø®¶§» <[email-masked]>">
	²ø®¶§»@¹q¶l.¤½¥q.·s¥[©Y
	</a>

What we are talking about here is business cards, advertising
media, and legacy applications.  This is a convenience for
humans, and, as such, is of dubious value (see below).

> Do not deny us the right to communicate in our own language for
> the convience of yourself or because you cannot understand it.

This is a bogus argument, based on the assuption that the
email address is going to be exposed in its raw form.  If
this were to happen, what you would see would not be:

	²ø®¶§»@¹q¶l.¤½¥q.·s¥[©Y

But instead something like (pseduo-transformed):

	[email-masked]

...a UTF-5 encoded representation of the email address, in
the same US-ASCII subset that you are trying to overcome.

> > > > It is not being updated to be cognizant of UTF-* or
> > > > Unicode -- nor should it be.  That is the job of MIME.
> > >
> > > And MIME is unfortunately insufficient to provide a complete
> > > I18N solution. I10N yes, but not I18N where you want a unified
> > > code.
> >
> > I think if we are talking about a short term soloution, then
> > L10N is sufficient, for the short term.
> 
> What makes you think so? I would like to see an working
> implementation of l10n DNS or at least a proposal.

Because, if you are going to do something long-term, then
any stop-gap you come up with will be with us forever.

If the stop-gap doesn't lead naturally into the correct long
term soloution, then it's the wrong stop-gap.  Any stop-gap
that doesn't dictate a raw, unencoded back end, where legacy
applications are "protected" by encoding (perhaps UTF-5;
perhaps not) done at the resolver, is probably not going to
be successful.

> In case you wonder, we went thru at least 6 prototypes
> of iDNS before we come up with this proposal, including
> the one using RFC2047 domain names.

I appreciate the effort you have invested so far.

> > Can we seperate the UTF-5 discussion from the DNS I18N
> > discussion?
> 
> This is fine with me. We only bring up I18N DNS and EMail
> because I was asked to justify for Yet-another-UTF. So,
> is there anything suggestions you have for UTF-5?

Some suggestions, then.

1)	In the abstract, remove the sentence:

	"Example of such systems are the domain name
	 system and email addresses."

	I believe that putting the encoded data into the
	DNS itself, rather than making the transformation
	at the resolver from a pure binary back end, is a
	very bad thing.  The DNS data itself should be in
	whatever unified code set, going forward.

2)	In the fourth paragraph of section 2, an attempt
	is made to disclaim dependence on a particular
	character set.  I believe that the wording
	should be strengthened to something similar to
	the wording specifically calling out [US-ASCII]
	in section 1 of [UTF8].

3)	The table in section 2.1 uses the leading bit
	for initial but not subsequent values.  This
	means that there are encoding restart issues
	that [UTF8] does not suffer from.

	I believe the encoding should be made less
	vulnerable to this problem, through a different
	sequence of introduction bits.

4)	In 2.5, there is a discussion of auto-detection.
	This discussion should be removed.

	The purpose of this encoding is to ensure that
	legacy systems can interoperate with international
	data elements.

	If it is algorithmically possible to detect data
	thus encoded, then this goal has failed to be met.

	Note:	One method that occurs to me is to modify
		the alphabet; specifically, to remove all
		vowels.  This would be much less error
		prone, if you _must_, for some reason,
		attempt auto-detection. of data format.

5)	In section 4, remove item "a", unless you specifically
	restrict yourself to discussing possible resolver
	behaviour on a legacy system.

	Suggesting that other than binary data should be stored
	in the iDNS is a blind alley which can trap us with
	bulky data and fixed internal encodings forever.

	I do not believe that UTF-5 should be applied to
	the data actually stored in the iDNS, except as a
	transform when externalizing that data to a legacy
	application.

6)	In section 4, item "b", remove the sentence:

	"SMTP mailbox have a very strict check [RFC822]
	 dues to many potential security risks when using
	 symbols or special characters in mailbox."

	This is a legacy data issue, not a security issue.

7)	Reword the remainder of paragraph 1 of 4 "b".

	I believe the emphasis on the idea that localization
	of email addresses themselves in support of legacy
	systems to be counter productive.

	Specifically, I believe that said systems are more
	likely to suffer from buffer overrun issues.  Further,
	it is not correct to suggest UTF-5 as a "fix" for
	issues better address by DRUMS.

8)	I believe that you should remove paragraph 2 of
	4 "b".

9)	Paragraph 3 of 4 "b" deserves to be its own point.

10)	Remove the reference to "morse code".  Most of the
	people in this forum appear to find it extravagant.

	Suggested replacement examples:

	o	Caption Vision (closed captioning)
	o	Teletype
	o	Telephony
	o	Teletext

-- Terry Lambert
-- Whistle Communications, Inc.
-- [email-masked]
-------------------------------------------------------------------
This is formal notice under California Assembly Bill 1629, enacted
9/26/98 that any UCE sent to my email address will be billed $50
per incident to the legally allowed maximum of $25,000.