Subject: Re: [idn] proposed i18n naming rules

From: liana Ye <[email-masked]>
Date: Thu, 22 Nov 2001 00:33:38 -0600

On Wed, 21 Nov 2001 19:35:42 -0500 "ben" <[email-masked]> writes:
> Hi Liana,
> 
> From: "liana Ye" <[email-masked]>
> > as a key element to flag a label.  So, if such an
> > flag appears within a label, then one label becomes
> > two labels, ie.  <zhongguo>.com becomes
> > <zhong>.<guo>.com,  we have trouble.
> >
> > When we deal with TC/SC for a IDN label, the punctuations
> > have to be excluded.  But about circled characters,
> 
> Can you explain why you say, "we have trouble"?  Is there a need for
> the "Chinese full stop" to serve another purpose other then to act 
> as
> a label seperator?
> 

If what you only assume it a label seperator, then it can be treated
before [nameprep], as part of input buffer/user interface process,
then it has no need to be mixed with TC/SC insensitizing, or Latin
case folding.  So do all other forms of label seperators, (though % or 
$ is not usally label a seperator), may be treated in the same way as
"Chinese full stop" , thus they also excluded from [nameprep]. 
 
Liana

---

From: "ben" <[email-masked]>
Date: Thu, 22 Nov 2001 12:20:04 -0500

Hi Liana,

> "Chinese full stop" , thus they also excluded from [nameprep].

It was first brought up by Eric H in this thread who said, " U+002E
(FULL STOP) is ONLY valid for use as a separator when the IHI is
written out".  I thought it will be a good time to draw the same
attention to the "Chinese Full Stop" for this WG to consider.  (To
clarify, I am most definitely *not* pushing for it to become legal
data.)

Thanks,
Ben

---

From: "Eric A. Hall" <[email-masked]>
Date: Thu, 22 Nov 2001 11:45:58 -0600

ben wrote:

> attention to the "Chinese Full Stop" for this WG to consider.

DNS doesn't store the separator. The only place the separator appears is
in domain names that are written-out and stored in data streams. And since
the separators are not encapsulated in the labels (they are separators not
data), they are not subject to encoding, and therefore would always appear
between encoded labels (including ACE labels). So really you are asking
about domain names as they appear in protocol and/or application data. You
would have to update every protocol and application that processes domain
names in order for Chinese Full Stop to be usable as a label separator
everywhere that a domain name was encoded or encapsulated.

-- 
Eric A. Hall                                        http://www.ehsco.com/
Internet Core Protocols          http://www.oreilly.com/catalog/coreprot/

---

From: "ben" <[email-masked]>
Date: Thu, 22 Nov 2001 14:31:21 -0500

Hi Eric,

From: "Eric A. Hall" <[email-masked]>
> everywhere that a domain name was encoded or encapsulated.

If it is not possible to update all the protocol and application, then
how about just mapping the Chinese Full Stop to the English Full Stop
(as suggested by the authors of TSCONV-03.txt).  Would that be a
simpler solution (atleast for now)?

Thanks,
Ben

---

From: "Eric A. Hall" <[email-masked]>
Date: Thu, 22 Nov 2001 13:53:44 -0600

> simpler solution (atleast for now)?

Such a mapping would only apply to encoding sequences and would therefore
be limited to the label contents. It would not apply to the separator.

I think that the best hope for this is to figure out a way to handle it as
part of a localization service.

---

From: "James Seng/Personal" <[email-masked]>
Date: Fri, 23 Nov 2001 05:17:16 +0800

What we need to do is defined U+3002 as a DNS label seperator
*inadditional* to U+002E. We should also consider U+FF2E to be
consistent.

-James Seng

---

From: "ben" <[email-masked]>
Date: Thu, 22 Nov 2001 16:32:15 -0500

Hi Eric,

> be limited to the label contents. It would not apply to the
separator.

Currently, this certainly is the case.  However, lets see if this WG
(after reading the draft) can accomodate such a mapping.  If yes,
users of CDNs will be so grateful and happy.    ;-)

Thanks,
Ben

---

From: [email-masked]
Date: Fri, 23 Nov 2001 09:16:15 +1100

> everywhere that a domain name was encoded or encapsulated.

	DNS doesn't store the seperator but it can and does store periods
	in labels.

	e.g.
		mark\.andrews.isc.org
		
	which is 4 labels (including the root) when encoded on the wire.

		"mark.andrews"
		"isc"
		"org"
		"."
	
	Just because it is not used in labels in *hostnames* is no reason
	not to consider it.

	If you are going to drop characters in IHNs you have to also drop
	the in IDNs.  If you are going to map characters in IHNs you have
	to map the in IDNs.  If you map several characters to periods
	that then become seperators you have to map the same characters
	to periods that appear in labels.

	Mark
--
Mark Andrews, Internet Software Consortium
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: [email-masked]

---

From: "Eric A. Hall" <[email-masked]>
Date: Thu, 22 Nov 2001 16:57:20 -0600

> DNS doesn't store the seperator but it can and does store periods

Yeah, but he's asking about the separator in particular.

---

From: [email-masked]
Date: Fri, 23 Nov 2001 10:26:31 +1100

> Yeah, but he's asking about the separator in particular.

	What do you think the period in the mailbox form of my email
	address is?  The answer (what ever it turns out to be) is
	independent of whether it is mapped to a period or used to
	seperate labels.

	In other words should "[email-masked]" with all the
	period turned into Chinese Full Stops match "[email-masked]"
	where the periods are periods (U+002E).  I don't know the answer
	to that but I do know that both should map or neither should map.

	Mark

---

From: David Hopwood <[email-masked]>
Date: Thu, 22 Nov 2001 23:42:36 +0000

-----BEGIN PGP SIGNED MESSAGE-----

James Seng/Personal wrote:
> *in addition* to U+002E. We should also consider U+FF2E to be
> consistent.

You mean U+FF0E (also U+FF61 if we map other halfwidth characters).

There are two questions here:
 - whether U+3002 and U+FF0E should be allowed as a separator in
   application layer encodings of a domain name (no, absolutely not)
 - whether user input processes should be allowed or encouraged to map
   U+3002 and U+FF0E to U+002E before encoding them (yes, and nameprep
   already says that).

- -- 
David Hopwood <[email-masked]>

Home page & PGP public key: http://www.users.zetnet.co.uk/hopwood/
RSA 2048-bit; fingerprint 71 8E A6 23 0E D3 4C E5  0F 69 8C D4 FA 66 15 01
Nothing in this message is intended to be legally binding. If I revoke a
public key but refuse to specify why, it is because the private key has been
seized under the Regulation of Investigatory Powers Act; see www.fipr.org/rip

---

From: "James Seng/Personal" <[email-masked]>
Date: Fri, 23 Nov 2001 08:18:04 +0800

Yes, I meant U+002E, U+3002, U+FF0E and also U+FF61 (I missed that..:-)
should be considered to be defined as label separator.

Altho Nameprep has mention U+3002 (by prohibiting it), there is
inconsistency. e.g consider U+FF0E would actually normalized to U+002E
but U+3002 is prohibited.

And as Mark Andrew said, we should probably not prohibit the use of
these seperator in labels. It is up to the applications to determine to
detect the separator. Therefore, what we need to do is to actually
specific the lists of possible separator.

-James Seng

---

From: David Hopwood <[email-masked]>
Date: Fri, 23 Nov 2001 00:39:46 +0000

-----BEGIN PGP SIGNED MESSAGE-----

> but U+3002 is prohibited.

U+FF0E is prohibited by nameprep-05, somewhat indirectly (it is
normalised by NFKC to U+002E, which is prohibited).

To be consistent, I suggest the following:
 - remove the prohibition step from nameprep,
 - map U+3002 to U+002E in the mapping step (this means that like
   U+FF0E, it can be used in a mailbox local part),
 - say that U+3002 and U+FF0E (and U+FF61 iff we map halfwidth characters)
   SHOULD be treated as a label separator when names are input, but
   MUST NOT be used to encode a label separator for transmission or
   storage,
 - define a syntax for international host strings (IHIs in the
   IDNS terminology) partly based on the current nameprep prohibitions.

- --

---

From: "Eric A. Hall" <[email-masked]>
Date: Thu, 22 Nov 2001 19:29:05 -0600

[email-masked] wrote:

> What do you think the period in the mailbox form of my email address is?

When it is stored in DNS as a label, it is data, not a separator.

> In other words should "[email-masked]" with all the period turned
> into Chinese Full Stops match "[email-masked]" where the periods
> are periods (U+002E).

Urgh. That particular question is for the email people to answer.

When it is stored in DNS, it will be treated however nameprep says to
treat it.

Hopefully they will be compatible.