Subject: Re: [weirds] Internationalization Issues

From: Edward Lewis <[email-masked]>
Date: Thu, 1 Nov 2012 12:14:28 -0400

At 12:04 +0800 10/12/12, Ning Kong wrote:
>Any thoughts or comments on this topic are appreciated.

Having read the thread, I had a few thoughts (of course).

First, there was mention of "translation."  I think translation is 
completely out of scope.  No part of the WEIRDS WG protocol elements 
should be attempting to *convert* one language or script to another. 
What I mean is, if I look up a 133.310.259.12 I get some information 
in Japanese and I get some information in English.  I do not expect 
the Japanese information to be translated into English by either the 
server or client of the protocol.  The fact that there is English 
information in addition is external (out-of-band) to the protocol - 
it's just other data carried to the WEIRDS WG protocol.

For the most part, conveying the A-label and U-label for domain names 
(that includes name servers) and sticking to standards for Postal 
Codes* (I am only aware of the standards there through stories from 
others), most of the critical information will be covered.  Yes, 
remarks are not covered but I am not sure that they are all that 
important in the use cases I imagine.  What is important would be the 
names inside contacts.  I.e., it's really helpful that I see the 
pinyin for Ning's name. ;)

I doubt that this protocol development work can drive what data a 
registry collects, in a sense this protocol is the tail of the dog. 
What should be provided is a way for the protocol to indicate as much 
about the language and encoding used when the information is conveyed.

Note - I'm avoiding talking about language tags, etc., and what is 
"displayed" at a client because I think we first have to consider the 
problem to be solved.  At times in the development of IDN, the 
problem got more complex because "translation" is a more general 
problem than just representing a script in a DNS label.

Another note - in an earlier reply to Ning I expressed the problem I 
have with every trying to solve the issue of internationalization in 
a general sense just based on the signs seen on Beijing roadways. 
E.g., a sign with the Han characters for "GongDaQiao" and below that 
"GONGDA BRIDGE".  The way the sign is rendered mixes scripts, I would 
have expected GONGDAQIAO or a something like "Polytechnic University 
Bridge" to be rendered in letters.  The "natural world"'s mixing of 
scripts - just between Han and pinyin - is tough to crystalize into a 
computer protocol.  So - avoid translation in the data access 
protocol!

* - I've sent postcards internationally that only had a street name, 
city, state, country in letters, in addition to digits for zip code 
and house number.  The use case I have in mind is a card from Germany 
sent to Chinese-speaking friends living in the US.  The address had 
to be in "ASCII" so that the German mail handling system could hand 
it off to the US system.  From what I've been told, French is also an 
official postal address language.
-- 
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Edward Lewis
NeuStar                    You can leave a voice message at +1-571-434-5468

2012...time to reuse those 1984 calendars!

---

From: SM <[email-masked]>
Date: Thu, 01 Nov 2012 10:45:26 -0700

Hi Ed,
At 09:14 01-11-2012, Edward Lewis wrote:
>* - I've sent postcards internationally that 
>only had a street name, city, state, country in 
>letters, in addition to digits for zip code and 
>house number.  The use case I have in mind is a 
>card from Germany sent to Chinese-speaking 
>friends living in the US.  The address had to be 
>in "ASCII" so that the German mail handling 
>system could hand it off to the US system.  From 
>what I've been told, French is also an official postal address language.

People might consider Whois as important as it is 
a valuable source of information for DMCA 
notices. :-)  Such notices are generally sent by 
email as it is the cheapest alternative for 
businesses which rely on this critical property 
available through Whois.  I don't know how 
important postal addresses are.  Anyway, it's 
easier to send a letter to .com and .org to seize 
a domain name.  For number resources, it is easier to send a letter to the RIR.

Domain names or email addresses is not a 
significant internationalization issue as there 
are existing specifications for that.  The text 
quoted above highlights the internationalization 
issue when it comes to postal 
addresses.  Currently, that information is 
unstructured.  As an example, here's what I get for jprs.jp:

Domain Information: [B%I%a%$%s>pJs]
[Domain Name]                   JPRS.JP

[BEPO?<TL>]                      B3t<02q<RF|K\%l%8%9%H%j%5!<%S%9
[Registrant]                    Japan Registry Services Co.,Ltd.

[Name Server]                   ns1.jprs.jp
[Name Server]                   ns2.jprs.jp
[Name Server]                   ns3.jprs.jp
[Signing Key]                   4864 8 2 (
                                 E6C5E9C953D720CB378A089DBBBCB982
                                 B524954C2DDCD22FA115913A0055982B )
[Signing Key]                   4864 8 1 (
                                 C2DDE450F3042E78CC9A2E49F3978CD9
                                 497C3011 )

[BEPO?G/7nF|]                    2001/02/02
[BM-8z4|8B]                      2013/02/28
[B>uBV]                          Active
[B:G=*99?7]                      2012/03/01 01:05:01 (JST)

Contact Information: [B8x3+O"MmAk8}]
[BL>A0]                          B3t<02q<RF|K\%l%8%9%H%j%5!<%S%9
[Name]                          Japan Registry Services Co.,Ltd.
[Email]                         [email-masked]
[Web Page]
[BM9JXHV9f]                      101-0065
[B=;=j]                          BEl5~ET@iBeED6h@>?@ED;0CzL\8BHV1B9f
                                 B@iBeED%U%!!<%9%H%S%kEl4[ 13F
[Postal Address]                Chiyoda First Bldg. East 13F,
                                 3-8-1 Nishi-Kanda Chiyoda-ku,
                                 Tokyo 101-0065, JAPAN
[BEEOCHV9f]                      03-5215-8451
[FAXBHV9f]                       03-5215-8452

and for denic.de:

Domain: denic.de
Nserver: ns1.denic.de 2001:608:6:6:0:0:0:11 81.91.170.1
Nserver: ns2.denic.de 193.171.255.36
Nserver: ns3.denic.de 87.233.175.19
Status: connect
Changed: 2010-06-18T09:06:50+02:00

[Tech-C]
Type: PERSON
Name: Business Services
Organisation: DENIC eG
Address: Kaiserstraße 75-77
PostalCode: 60329
City: Frankfurt
CountryCode: DE
Phone: +49 69 27235 272
Fax: +49 69 27235 234
Email: [email-masked]
Remarks: Information:http://www.denic.de
Changed: 2010-12-15T12:00:30+01:00

[Zone-C]
Type: PERSON
Name: Business Services
Organisation: DENIC eG
Address: Kaiserstraße 75-77
PostalCode: 60329
City: Frankfurt
CountryCode: DE
Phone: +49 69 27235 272
Fax: +49 69 27235 234
Email: [email-masked]
Remarks: Information:http://www.denic.de
Changed: 2010-12-15T12:00:30+01:00

and for cnnic.cn:

Domain Name: cnnic.cn
ROID: 20030310s10001s00012956-cn
Domain Status: serverDeleteProhibited
Domain Status: serverUpdateProhibited
Domain Status: serverTransferProhibited
Registrant ID: s1255673574881
Registrant: ä¸­å
egistrant Contact Email: [email-masked]
Sponsoring Registrar: åŒ—äº¬ä¸­ç§‘ä¸‰æ–¹ç½‘ç»æŠ€æ¯æ‰é™å
¬å¸
Name Server: a.cnnic.cn
Name Server: b.cnnic.cn
Name Server: c.cnnic.cn
Name Server: d.cnnic.cn
Name Server: e.cnnic.cn
Registration Date: 2003-03-10 19:06:34
Expiration Date: 2018-03-10 19:06:34
DNSSEC: unsigned

It was mentioned that [1]:

   "There is a possibility some element has data by multiple languages (such
    as Japanese and English) and the other element has data by a single
    language (such as Japanese)."

If the Whois output (see above) was rendered in 
ASCII there would be loss of information.  It is 
going to be complicated to solve the postcard 
problem.  Getting into translation [2] might 
create other issues.  It might help if people 
commented on what they mean by "internationalization".

Regards,
-sm

1. http://www.ietf.org/mail-archive/web/weirds/current/msg01769.html
2. http://www.ietf.org/mail-archive/web/weirds/current/msg01810.html

---

From: "Hollenbeck, Scott" <[email-masked]>
Date: Thu, 1 Nov 2012 17:56:39 +0000

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On
> Behalf Of SM
> Sent: Thursday, November 01, 2012 1:45 PM
> To: Edward Lewis
> Cc: [email-masked]
> Subject: Re: [weirds] Internationalization Issues
> 
> Anyway, it's easier to send a letter to .com and .org to seize a domain name.

This is off-topic, but it takes much more than a letter to take down a .com domain.

Scott

---

From: Edward Lewis <[email-masked]>
Date: Thu, 1 Nov 2012 14:57:32 -0400

I think one my points was too subtle.

At 10:45 -0700 11/1/12, SM wrote:

Looking at these two introductory statements:

>Such notices are generally sent by email as it is the cheapest alternative
>for businesses which rely on this critical property available through Whois.

>Domain names or email addresses is not a significant internationalization
>issue as there are existing specifications for that.

If the implication is that while we have email and DNS standards for 
this but we lack postal standards, I'd point to the Universal Postal 
Union.  Wikipedia has more information about them that I can give 
you.  From what I've seen, I'd say they have already established 
postal standards for addressing that would fit the use case you 
mention.

Perhaps the current state of the way WhoIs displays addresses could 
be described as "a mess" there are already standards defined. 
Registries ought to be collecting addresses in such a way to conform 
with what ever applicable standards exist.  That "ought to" is not a 
responsibility of the WEIRDS WG, the protocol under development is 
not the place to make registries be compliant.  The protocol ought to 
be able to assume that addresses be able to be represented in an 
already defined standard format.

The point is - email, domain name, and postal addresses already have 
internationalized forms and that covers most of what we need to 
provide.  Remarks, no, that is not covered.  Remarks and what ever 
else not covered, I would bet, is not enough to require that the 
protocol under discussion here include any translation function. 
GIGO is probably all that is needed, relying on existing standards 
and collection/retention practices.

The latter - I can't say "for sure."  There might be a compelling 
reason to weave translation into this protocol, but I really doubt it.

---

From: SM <[email-masked]>
Date: Thu, 01 Nov 2012 13:02:30 -0700

Hi Ed,
At 11:57 01-11-2012, Edward Lewis wrote:
>postal standards for addressing that would fit the use case you mention.

I read the Universal Postal Union practices.  For example, let's say 
that one of the postal addresses should be written in English.  I 
don't know whether someone outside this working group will not like 
that.  The postcard example is somewhat straight-forward.  There is 
an origin; there is a destination.  In the case of Whois there isn't 
one destination.  This is where language negotiation comes in.  The 
protocol can do that.  You still need the data in that language.

>Registries ought to be collecting addresses in

Yes.

>  such a way to conform with what ever applicable standards 
> exist.  That "ought to" is not a responsibility of the WEIRDS WG, 
> the protocol under development is not the place to make registries 
> be compliant.  The protocol ought to be able to assume that 
> addresses be able to be represented in an already defined standard format.

I cannot tell registries what to do. :-)  I am trying to look at this 
differently.  The question I would ask is: tell "us" how you want to 
do it.  It might then be clearer to identify what the protocol should 
do instead of designing a protocol with its set of constraints.

>provide.  Remarks, no, that is not

Steve Sheng mentioned the following [1]:

  "- Registrant Name: Local language with language-script tags
    (e.g. Using tags as defined by RFC 5646)
   - Registrant contact information: local language with language-script
     tags

   One issues that is in active discussion within ICANN is in the case a
   registrant submit information in his/her local language/script, whether
   there should a requirement to translate and transliterate (into latin)
   this information. The policy community is starting a policy development
   process on that."

There isn't a mention of a standard for postal addresses.  The 
language issue is mentioned.  I prefer to look at this from a 
different angle (I commented on that above).

Regards,
-sm

1. http://www.ietf.org/mail-archive/web/weirds/current/msg01763.html

---

From: Edward Lewis <[email-masked]>
Date: Thu, 1 Nov 2012 16:36:28 -0400

At 13:02 -0700 11/1/12, SM wrote:

>differently.  The question I would ask is: tell "us" how you want to do it.

It's clear that the protocol will not drive what registries do (or 
have been doing).  However, the protocol does not need to parrot 
exactly what is in the registries' internal databases.

The protocol design would be wise to look to existing standards from 
relevant experts and build around that.  Acquiescence to the mess 
that appears now will only perpetuate the problem we have now with 
freeform WhoIs.

If the protocol has a strict standard to implement, the implementers 
of the code that reads the registry database will have to do some 
conversion - stopping short of translation.  I do know that if a 
relevant standard becomes required on a registry implementation, the 
registry will re-tool and comply.

>There isn't a mention of a standard for postal addresses.  The language
>issue is mentioned.  I prefer to look at this from a different angle
>(I commented on that above).

Whether the quoted passage was from an ICANN document or discussion 
or just appeared in a message purporting this, the IETF isn't 
beholden to that requirement.  The IETF listens to requirements (even 
from ICANN) but that doesn't mean we have to settle for what is 
decided elsewhere.  I sound like I'm advocating that we ignore ICANN 
but I do not intend to, just stating that the IETF is independent.

As part of the independence, we need to see if what we produce is 
technically sound.  In the policy sphere there are many interests 
that push for a compromise, and that is fine.  But in the technical 
sphere what rules is whether a design point is solid - will the 
solution scale, will the solution be nimble, etc.  This is where I 
get the "look at the UPU standards" as a recommendation.

No matter what information the registries do collect, no matter what 
the regulator (ICANN or not) requires, if the addresses are going to 
matter when sending postal mail, internationally, then what is 
marshalled in the WEIRDS WG protocol has to be a super-set of the 
information needed to address an envelope.

The thread topic is internationalization.  The long plank I've been 
walking on is to assume that a registry will want to supply an 
address in what ever "colloquial" form them want as well as a form 
compatible with international mailing.  And that would be the basis 
for a requirement for the WEIRDS WG protocol.  That the protocol 
allow for the marshalling of an address in registry-specific string 
and/or in an international form.

The reason for this - I am thinking of how to simplify the 
implementation of the client.  I don't want to see clients need to 
have huge case statements (if it is from "US.", I display this way, 
if it is from "XN--P1AI." I do it that way and so on).  My desire is 
to constrain the protocol to what is needed, so as to avoid the 
"mess" we have now.

---

Here's some background on my angst here.  I was investigating a case 
of cache poisoning not too long ago.  (Yes, cache poisoning, but it 
wasn't an attack.)  During the investigation I came across two domain 
names. The two names were registered in a place far, far away, and 
with a street address that was hard for me to grok.  I did notice 
though that the cellphone number of the two domain names was the 
same, so I could conclude there was a relationship between the two 
domain names.  How that related to the cache poisoning isn't 
important, the problem where was trying to determine if two 
registrations were from the same person/entity/organization or 
possible a pair of antagonists working in close proximity.

Had there been a "standard way" to present the addresses, I might 
have seen the relationship sooner.  As I mentioned it wasn't until my 
eyes slipped down to the telephone numbers that I could uncover a 
clue.  Would a standard have helped?  I bet it would, perhaps not, 
but I bet it would.

---

From: Byron Ellacott <[email-masked]>
Date: Fri, 2 Nov 2012 11:07:52 +1000

On 02/11/2012, at 6:36 AM, Edward Lewis <[email-masked]> wrote:

> It's clear that the protocol will not drive what registries do (or have been doing).  However, the protocol does not need to parrot exactly what is in the registries' internal databases.

The WG is neither chartered nor able to fix problems with the contents of registries.  If the protocol cannot carry existing information, it will carry none at all.  I sympathise with your use case for more useful address information, but the right venue to try to force registries to get better data is ICANN (or the RIR processes), not the IETF.  I do recognise the difficulty of that task - which is why I don't think we should attempt to force the unenforceable via a protocol decision.

The questions about i18n that I see before the WG are:

1) Can the protocol carry information in more than one language or script?

2) Should there be a mechanism for indicating to the client what language or script is in use, and at what granularity?

3) Should there be a mechanism for allowing the client to indicate preferred languages for the response?

I don't think there are any useful questions about what should happen to the data.  If a registry only has data in one language, that's the language it's going to send that data in, no matter what the client asks for, or what the protocol specification dictates.

#1 is trivial - the de facto character encoding for RDAP responses is UTF-8, which can encode a pretty broad range of things, and servers may signal an alternative character set if they prefer.

For #2, there is the HTTP header, which is meta-data and semantically indicates the best language for consumption of the data, rather than the language the data is necessarily in, or there is a language tag in the response, either for the entire response, or parts thereof, and I don't think I've seen any other suggestions.

For #3, there is the HTTP request and response headers, again semantically subtle, and URI query parts.

I will put up a strawman and suggest that the using-http draft adopts something along these lines:

--- snip ---
4.2.1  Indication of preferred language

A client MAY include a query parameter to indicate preferred language for responses.  A server MAY choose to take that into consideration when preparing a response.  The format of the language query parameter is:

	lang=<RFC 5646 language tag>
--- snip ---

And that the json-response draft adopts something along these lines:

--- snip ---
3.  Common Data Types
…
    lang:  An RFC 5646 language tag indicating the primary language of the object
…
--- snip ---

With the "lang" attribute added to each object type defined.

Thoughts?

  Byron

---

From: Andy Newton <[email-masked]>
Date: Fri, 2 Nov 2012 10:30:28 +0000

On 11/1/12 9:07 PM, "Byron Ellacott" <[email-masked]> wrote:

>> It's clear that the protocol will not drive what registries do (or have
>>been doing).  However, the protocol does not need to parrot exactly what
>>is in the registries' internal databases.
>
>The WG is neither chartered nor able to fix problems with the contents of
>registries.  If the protocol cannot carry existing information, it will
>carry none at all.  I sympathise with your use case for more useful
>address information, but the right venue to try to force registries to
>get better data is ICANN (or the RIR processes), not the IETF.  I do
>recognise the difficulty of that task - which is why I don't think we
>should attempt to force the unenforceable via a protocol decision.

I am in 100% agreement here. Registries already have content and they will
only be able to give that content out in the form they have it. Forcing
registries down a data clean-up effort or through some data transformation
effort seems like a non-starter.

>2) Should there be a mechanism for indicating to the client what language
>or script is in use, and at what granularity?
>

I agree with this.

>
>I don't think there are any useful questions about what should happen to
>the data.  If a registry only has data in one language, that's the
>language it's going to send that data in, no matter what the client asks
>for, or what the protocol specification dictates.
>
>#1 is trivial - the de facto character encoding for RDAP responses is
>UTF-8, which can encode a pretty broad range of things, and servers may
>signal an alternative character set if they prefer.
>
>For #2, there is the HTTP header, which is meta-data and semantically
>indicates the best language for consumption of the data, rather than the
>language the data is necessarily in, or there is a language tag in the
>response, either for the entire response, or parts thereof, and I don't
>think I've seen any other suggestions.
>
>For #3, there is the HTTP request and response headers, again
>semantically subtle, and URI query parts.
>
>A client MAY include a query parameter to indicate preferred language for
>responses.  A server MAY choose to take that into consideration when
>preparing a response.  The format of the language query parameter is:
>

I don't think we should be using query parameters where there is already
an HTTP header for the purpose. Other than that, I like this.

>Š
>Š

Again, 100% agreement.

-andy

---

From: Edward Lewis <[email-masked]>
Date: Fri, 2 Nov 2012 09:13:51 -0400

>effort seems like a non-starter.

My point still hasn't been made.

Developing the server for a registry won't cause the registry to 
reform it's data collection activities.  But the server doesn't have 
to be GIGO with regards to what's in the database.

>>	lang=<RFC 5646 language tag>

In DNSSEC we have a similar problem, instead of human language though 
it was cryptographic algorithm and hash.  Nowadays the problem has 
largely disappeared because most zones are signed with just one 
algorithm but when designing the protocol we imagined a zone might be 
signed with a collection of algorithms and the client could pick and 
choose which to use.  In DNSSEC we had to avoid any sort of 
negotiation.

To date DNS has punted the solution, primarily because the operators 
have eliminated the problem (by signing with just one algorithm, 
eliminating choice).  There is a proposal to allow clients to specify 
what algorithm to use, but that is a proposal that is going nowhere 
because it causes as many problems as it solves.

Ultimately what I'm saying is:

Don't try to reinterpret (such as translate) data in the protocol.
Limit the amount of negotiation for the content (like, no round trips for that)
Make sure there's a conduit for an established international address format

This effort won't force registries to come to a common collection 
method, but the protocol can restrict the ways in which data is 
carried.  "Liberal in what you accept, conservative in what you send" 
applies here.

---

From: "John Levine" <[email-masked]>
Date: 2 Nov 2012 15:28:51 -0000

>Make sure there's a conduit for an established international address format

HTTP already has the Accept-Language request header, and
Content-Language entity header.  Are those adequte for what WEIRDS
needs?  If not, why not?

---

From: Edward Lewis <[email-masked]>
Date: Fri, 2 Nov 2012 11:42:00 -0400

>Content-Language entity header.  Are those adequte for what WEIRDS

I don't know.  And here is why I don't know.

I have seen this problem pop up which would make me say no.  (Perhaps 
this doesn't apply.)  In DNS there is the TXT record which is widely 
assumed to hold a string.  In some software developments, allocating 
a String type will call into play UTF encoding libraries, etc.  When 
a customer inadvertently inserts a non-printable (in ASCII) character 
in the TXT record, extra processing is done deep in the software 
stack and, well, chaos ensues.

The question is whether that functionality of the assume solution 
tool is beneficial to the problem to be solved or not.  It could be 
that the features of the tool are overkill for the problem to be 
solved.  (Low probability, but that's where my doubt would lie.)
-- 
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Edward Lewis
NeuStar                    You can leave a voice message at +1-571-434-5468

---

From: "John R Levine" <[email-masked]>
Date: 2 Nov 2012 12:29:20 -0400

> ... In some software developments, allocating a String type will 
> call into play UTF encoding libraries, etc.  When a customer inadvertently 
> inserts a non-printable (in ASCII) character in the TXT record, extra 
> processing is done deep in the software stack and, well, chaos ensues. ...

The DNS suffers from a design environment where the only language was 
English, and the only code was ASCII, so all I18N had to be shoehorned in 
later via a mountain of kludges.

The web is a decade newer, and it probably also helps that it was designed 
in Switzerland, where people routinely use two or three languages every 
day, and in the 1990s there were way too many extended ASCII variants. 
So every web request specifically says what languages and codes it can 
handle, and every web resposne says what language it's in and what code it 
uses.  This really works; set your browser's preferred language to French 
or German, and a lot of web pages will look different when you visit them.

We don't need the web's full flexible language glory, so we can specify a 
subset to use.  In particular, I see no reason for WEIRDS to use any code 
other than UTF-8, keeping in mind that ASCII is a proper subset of UTF-8. 
The language negotiation works well and I see no point to trying to invent 
something else.

For stuff like postal address formats, the best we can do it point people 
at external standards and encourage them to use those formats.  If they 
don't, I expect most of us would be willing to take our chances with 
whatever formats the registries and registrars can provide.

Regards,
John Levine, [email-masked], Taughannock Networks, Trumansburg NY
"I dropped the toothpaste", said Tom, crestfallenly.

---

From: Francisco Obispo <[email-masked]>
Date: Sat, 3 Nov 2012 20:30:08 -0700

Hi All,

DNS doesn't care about languages, it only cares about labels which are composed of bytes. the problem is with client libraries, and how to collect the user input into the proper byte representation.

The IDN implementation is there to normalize how the data is marshaled into the DNS.

Regards,

On Nov 2, 2012, at 9:29 AM, John R Levine <[email-masked]> wrote:

> The DNS suffers from a design environment where the only language was English, and the only code was ASCII, so all I18N had to be shoehorned in later via a mountain of kludges.

Francisco Obispo 
Director of Applications and Services - ISC
email: [email-masked]
Phone: +1 650 423 1374 || INOC-DBA *3557* NOC
PGP KeyID = B38DB1BE

---

From: Francisco Obispo <[email-masked]>
Date: Sat, 3 Nov 2012 20:39:16 -0700

This is why I think it's prudent to have WEIRDS match the capabilities of EPP and its extension mechanisms.

We are not going to be able to solve registry data problems, we just need to focus on registry data representation to serve the purpose of a modern whois suitable for consumption of both machines and human beings.

Registries (at least name registries using EPP), collect data in "international" format, that is, with US-ASCII only and in "localized" form using UTF-8. There is no point on having a way to query in a particular language because we are limited to what the registry has, so at most, we should be able to specify the response in 'international' form or in 'localized' form if available, and at most, we just just turn on the UTF-8 encoding to make sure that whatever is parsing it, encodes it into the proper format.

It makes no difference if we provide a label saying 'this is in spanish' or 'this is in french', at the end, the data will have to be consumed equally.

Regards

Francisco Obispo

---

From: Edward Lewis <[email-masked]>
Date: Sun, 4 Nov 2012 15:47:05 -0500

At 12:29 -0400 11/2/12, John R Levine wrote:
>For stuff like postal address formats, ...

When a thread begins to spin it's wheels, it's good to go back to the 
originating question.

Ning's original question was whether section 12 of 
http://tools.ietf.org/html/draft-ietf-weirds-using-http-00 is 
sufficient or should the text in section 7 of 
http://tools.ietf.org/html/draft-ietf-weirds-using-http-00 be brought 
back and augmented.

I think section 12 of the newer document should say more.  I do 
prefer extending what is in section 7 of the older text.

It's hard to say if (much) more text is needed.  Besides A and 
U-labels and IRI to URI, there should be something that talks about 
the other data (contract address, names, phone numbers) just to be 
clear on what is and what isn't considered.

The text really ought to discourage any translation or other 
manipulation within elements of the protocol.  And whether 
negotiation for language is a good idea or to be discouraged.
-- 
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Edward Lewis
NeuStar                    You can leave a voice message at +1-571-434-5468

---

From: "Ning Kong" <[email-masked]>
Date: Mon, 5 Nov 2012 15:12:55 +0800

Hi Edward,

> When a thread begins to spin it's wheels, it's good to go back to the
Thanks, Edward.

> http://tools.ietf.org/html/draft-ietf-weirds-using-http-00 is sufficient
or
> should the text in section 7 of
> http://tools.ietf.org/html/draft-ietf-weirds-using-http-00 be brought back
and
> augmented.
The second link should be
http://tools.ietf.org/html/draft-sheng-weirds-icann-rws-dnrd-01

> The text really ought to discourage any translation or other manipulation
> within elements of the protocol.  And whether negotiation for language is
a
> good idea or to be discouraged.
I'm also curious whether negotiation for character code is a good idea or to
be discouraged. This requirement was raised by Kentaro Mori [1].

[1] http://www.ietf.org/mail-archive/web/weirds/current/msg01769.html

Cheers,
Ning

---

From: "Linlin Zhou" <[email-masked]>
Date: Mon, 5 Nov 2012 15:42:23 +0800

Hi Byron,

I have a question. Why is it necessary to add lang attribute to each object?
IMHO, an attribute to a response record is enough. Could you elaborate it?
Thanks.

Linlin
> From: [email-masked] [mailto:[email-masked]] On Behalf
Of
> Byron Ellacott
> Sent: Friday, November 02, 2012 9:08 AM
> To: Edward Lewis
> Cc: [email-masked]
been doing).
> However, the protocol does not need to parrot exactly what is in the
registries'
> internal databases.
carry none at
> all.  I sympathise with your use case for more useful address information,
but
> the right venue to try to force registries to get better data is ICANN (or
the RIR
> processes), not the IETF.  I do recognise the difficulty of that task -
which is why I
> don't think we should attempt to force the unenforceable via a protocol
decision.
or
> script is in use, and at what granularity?
> 
> 3) Should there be a mechanism for allowing the client to indicate
preferred
> languages for the response?
> 
the
> data.  If a registry only has data in one language, that's the language
it's going to
> send that data in, no matter what the client asks for, or what the
protocol
> specification dictates.
UTF-8, which
> can encode a pretty broad range of things, and servers may signal an
alternative
> character set if they prefer.
> 
indicates
> the best language for consumption of the data, rather than the language
the data
> is necessarily in, or there is a language tag in the response, either for
the entire
> response, or parts thereof, and I don't think I've seen any other
suggestions.
> I will put up a strawman and suggest that the using-http draft adopts
something
> along these lines:
> .
>     lang:  An RFC 5646 language tag indicating the primary language of the
> object .
> --- snip ---
>

---

From: "Linlin Zhou" <[email-masked]>
Date: Mon, 5 Nov 2012 16:24:47 +0800

Of
> Edward Lewis
> Sent: Friday, November 02, 2012 9:14 PM
> To: Andy Newton
> Cc: [email-masked]
...
> This effort won't force registries to come to a common collection method,
but
> the protocol can restrict the ways in which data is carried.  "Liberal in
what you
> accept, conservative in what you send"
> applies here.

Object inventory did some data collection work. Maybe we can find some
useful representation ways or results based on these data.

Regards,
Linlin

---

From: Andrew Sullivan <[email-masked]>
Date: Mon, 5 Nov 2012 16:31:45 -0500

Dear colleagues,

On Sun, Nov 04, 2012 at 03:47:05PM -0500, Edward Lewis wrote:

> I think section 12 of the newer document should say more.

> It's hard to say if (much) more text is needed.

One thing that I think _is_ needed is a rule about normalization form.

Simply saying "Use UTF-8" is inadequate for some of the data, because
two encodings of the same normalized string might not match binary.
U-labels and A-labels hide this for us, because U-labels are already
required to be in NFC.

So, I would like the text at least to say that any input or output
MUST use Normalization Form $N.

There is a legitimate question about what $N ought to be.  It could be
that we need more than one form: perhaps input is different from
output.  NFKC loses information in a round trip, but maximizes
matching. What would be nice is to do NFKC for input to maximize the
chances of a match, and NFC in return transmission to maximize the
chances that data is never lost.

A requirement along these lines maximizes our chances of building
something compatible with future query patterns that we might want to
support.  

Best,

A

-- 
Andrew Sullivan
[email-masked]

---

From: "John Levine" <[email-masked]>
Date: 5 Nov 2012 21:55:10 -0000

>http://tools.ietf.org/html/draft-ietf-weirds-using-http-00 be brought 

The current text looks fine to me.  There's little reason to use anything
other than UTF-8 for this work.

>clear on what is and what isn't considered.

We're better off burning those bridges as we get to them.

For the contact data, that's not just an i18n issue.  There are plenty
of non-standard ways to write addresses in the United States using
only ASCII characters.  I'm not opposed to having the data model say
something about physical address formats, but it's more than roman vs
other characters.  It's also not clear to me who if anyone in this
group understands the issue well enough to write a reasonable spec.

R's,
John

---

From: "John Levine" <[email-masked]>
Date: 5 Nov 2012 21:56:09 -0000

>MUST use Normalization Form $N.

What if it's someone's name or address and doesn't have a normalized
form?

---

From: Andrew Sullivan <[email-masked]>
Date: Mon, 5 Nov 2012 17:41:55 -0500

> What if it's someone's name or address and doesn't have a normalized

Sorry, I guess I wasn't clear enough: I mean Unicode normalization.

A

-- 
Andrew Sullivan
[email-masked]

---

From: Byron Ellacott <[email-masked]>
Date: Tue, 6 Nov 2012 09:10:46 +1000

Hi Linlin,

It isn't necessary, I think.  I put up a proposal to see who is in favour or against various attributes of it, rather than to suggest it was necessary or important to go that specific direction.

  Byron

-- 
Byron Ellacott                  email:           [email-masked]
Technical Director, APNIC       sip:        [email-masked]
http://www.apnic.net            phone:         +61 7 3858 3100
________________________________________________________________________
 * Sent by email to save paper. Print only if necessary.