Subject: [weirds] Proposal for internationalization question

From: "Murray S. Kucherawy" <[email-masked]>
Date: Mon, 5 Nov 2012 23:21:28 -0500

I'd like to continue the internationalization discussion started during the
meeting today.

It's our read that the people talking on the topic were warm to the idea
that the query syntax would not include a provision for requesting a
response in a specific language, and the servers would provide the answers
in whatever language(s) they have; the client will make use of that reply
in whatever way it sees fit.

Is there any specific objection to that approach for this work?  (And have
I captured the proposal properly?)

-MSK

---

From: SM <[email-masked]>
Date: Mon, 05 Nov 2012 22:38:04 -0800

At 20:21 05-11-2012, Murray S. Kucherawy wrote:
>I'd like to continue the internationalization discussion started 
>during the meeting today.
>
>It's our read that the people talking on the topic were warm to the 
>idea that the query syntax would not include a provision for 
>requesting a response in a specific language, and the servers would 
>provide the answers in whatever language(s) they have; the client 
>will make use of that reply in whatever way it sees fit.

Ok.

Does the above mean no RFC 2119 key words for the request or the response?

Regards,
-sm

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Tue, 6 Nov 2012 07:30:03 -0500

Hi SM,

I believe it means there's no normative language in terms of the query,
because language selection is simply not part of the query.  The response
I'm less sure about because I'm not an i18n expert and don't know what
would be appropriate; if the language of a returned object needs to be
explicit, then SHOULD or MUST seems reasonable, otherwise a MAY (explicit
or implied) would be fine.  I leave that to the editors and the WG to sort
out.

-MSK

On Tue, Nov 6, 2012 at 1:38 AM, SM <[email-masked]> wrote:

>> I'd like to continue the internationalization discussion started during
>> the meeting today.
>>
> ______________________________**_________________
> weirds mailing list
> [email-masked]
> https://www.ietf.org/mailman/**listinfo/weirds<https://www.ietf.org/mailman/listinfo/weirds>
>

---

From: "Hollenbeck, Scott" <[email-masked]>
Date: Tue, 6 Nov 2012 12:45:20 +0000

I support this approach.

Scott

From: [email-masked] [mailto:[email-masked]] On Behalf Of Murray S. Kucherawy
Sent: Monday, November 05, 2012 11:21 PM
To: [email-masked]
Subject: [weirds] Proposal for internationalization question

I'd like to continue the internationalization discussion started during the meeting today.

It's our read that the people talking on the topic were warm to the idea that the query syntax would not include a provision for requesting a response in a specific language, and the servers would provide the answers in whatever language(s) they have; the client will make use of that reply in whatever way it sees fit.

Is there any specific objection to that approach for this work?  (And have I captured the proposal properly?)

-MSK

---

From: Edward Lewis <[email-masked]>
Date: Tue, 6 Nov 2012 09:28:20 -0500

At 23:21 -0500 11/5/12, Murray S. Kucherawy wrote:
I'd like to continue the internationalization discussion started 
during the meeting today.

Is there any specific objection to that approach for this work?  (And 
have I captured the proposal properly?)

I agree with this.  The query should not have the option to select 
the language/script/whatever it wants.  The response should include 
whatever is available.

 From a protocol engineering perspective, this eliminates the need to 
consider various error states - such as the query asking for blah and 
the server doesn't have blah - despite otherwise having a match for 
the queried object.  Fewer possible error states is just good.

 From a data reality perspective, negotiating for a specific language 
is over engineering.  In the physical world, contact information is 
often exchanged via business cards.  These cards have two sides (I've 
never seen a business card with more ;)).  One side has a "native" 
version, the other side is either blank or has a "lettered" side. 
That seems to be sufficient, the point here, while it is possible to 
get all complicated and everything - the problem to solve is so 
constrained we just need a simple solution.

A client if free to suppress any entries it feels can't be displayed 
or are undesirable, but at least then the client can make that 
determination.

PS - at the mic, someone suggested looking at vcard...I think that is 
a good lead.
-- 
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Edward Lewis             
NeuStar                    You can leave a voice message at +1-571-434-5468

2012...time to reuse those 1984 calendars!

---

From: Arturo Servin <[email-masked]>
Date: Tue, 6 Nov 2012 09:42:18 -0500

I think you have captured the proposal. I have no objection following this path.

Regards,
as

Sent from my mobile device
(please excuse typoss and brevit.)

On 5 Nov 2012, at 23:21, "Murray S. Kucherawy" <[email-masked]> wrote:

> _______________________________________________
> weirds mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/weirds

---

From: Marc Blanchet <[email-masked]>
Date: Tue, 6 Nov 2012 09:46:01 -0500

> It's our read that the people talking on the topic were warm to the idea that the query syntax would not include a provision for requesting a response in a specific language, and the servers would…

I would add that the response should be (optionally) tagged if that information is available in the registry.

Marc.

---

From: "Carlos M. martinez" <[email-masked]>
Date: Tue, 06 Nov 2012 09:48:41 -0500

+1

---

From: Marc Blanchet <[email-masked]>
Date: Tue, 6 Nov 2012 09:49:32 -0500

Le 2012-11-06 à 09:28, Edward Lewis a écrit :

> PS - at the mic, someone

Simon Perreault

> suggested looking at vcard...I think that is a good lead.

for references:
RFC6350 vCard Format Specification.
RFC6351 xCard: vCard XML Representation

  "A JavaScript Object Notation (JSON) Representation for vCard",
  Raghurama Bhat, Peter Saint-Andre, 6-Jun-12,
  <draft-bhat-vcarddav-json-00.txt>

Regards, Marc.

---

From: "John Levine" <[email-masked]>
Date: 6 Nov 2012 15:12:24 -0000

>> Does the above mean no RFC 2119 key words for the request or the response?

I think the intent is that the server SHOULD return the response in
all languages it has available, and MUST tag each version with the
correct language.  This specifically does not mean that any server is
required to support any particular language, but every server MUST
support at least one language so it's able to return any results at all.

Maybe I meant language+script where I said language above.

The reason the SHOULD is not a MUST is because there might be
situations where the server could use other clues to trim the set of
languages it returns.

I agree this gets us out of Klensin's rathole where there are
potentially infinite numbers of languages one might ask for.  In
practice, it's hard to envision servers usefully returning more than
three or four versions, e.g., central Asian languages that have been
written in Arabic, Cyrillic, and Roman scripts. In most cases there'd
be only one or two.

R's,
John

---

From: Peter Koch <[email-masked]>
Date: Tue, 6 Nov 2012 16:56:11 +0100

> I captured the proposal properly?)

I believe you missed the part where it was demonstrated that the notion
of language is particularly useless in the context of names. Let us try
to avoid this by agreeing that an object might have multiple representations
that are "tagged" and that the consensus in the room was that for this
tagging there would be no server side selection/filtering but rather
the client MUST be prepared to receive multiple instances (representations)
of the same object which MUST be tagged if there is more than one
and MAY be tagged if it is a single one.  Any further processing is
up to the client and may be a user interface issue that escapes protocol
standardization.

Translation of syntax elements like record/field names ought to be out of scope
as should be the 'translation' of names (Peter->Pierre->Pedro->Pjotr)
or other elements (street->straat->straße).
The level of equivalence between two or more representations of an object the
protocol should be agnostic about since this is a matter of policy the
respective repository/registry will be operated under.

-Peter

---

From: SM <[email-masked]>
Date: Tue, 06 Nov 2012 09:01:57 -0800

>Maybe I meant language+script where I said language above.

The problem is getting into a definition of language.  I would have 
asked the question: what do you mean by language?  After yesterday's 
WG session I prefer not to ask that question.

>situations where the server could use other clues to trim the set of

I'll comment below.

>written in Arabic, Cyrillic, and Roman scripts. In most cases there'd

Yes.

>up to the client and may be a user interface issue that escapes protocol

I prefer this approach.  In the above "we" moved from language to 
representations.  There should be some text about that so that the 
second "MUST" can be understood.  The difference between this 
approach compared to the one suggested by John Levine is that there 
isn't any server-side filtering.

In my view the problem is not being solved.  I doubt that the problem 
can be solved within a realistic time frame (see John Levine's 
comment above).  I don't think that the requirement resolves the 
concern of the director of the ICANN Board about law enforcement 
agencies and trademarks.  However, if that concern is important to 
the ICANN Board, law enforcement agencies or trademark vendors, they 
have the opportunity, in my humble opinion, to discuss the matter on 
this mailing list.

Regards,
-sm

---

From: Francisco Obispo <[email-masked]>
Date: Tue, 6 Nov 2012 09:09:04 -0800

On Nov 6, 2012, at 4:30 AM, Murray S. Kucherawy <[email-masked]> wrote:

> Hi SM,
> 
> I believe it means there's no normative language in terms of the query, because language selection is simply not part of the query.

And not part of the data repository either.

>  The response I'm less sure about because I'm not an i18n expert and don't know what would be appropriate; if the language of a returned object needs to be explicit, then SHOULD or MUST seems reasonable, otherwise a MAY (explicit or implied) would be fine.  I leave that to the editors and the WG to sort out.

International + Localized information should fulfill most EPP registries. Having an explicit language associated to the response object is either going to force registries to return non-accurate data, or run into a very complex validation problem down the line.

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

---

From: SM <[email-masked]>
Date: Tue, 06 Nov 2012 09:50:17 -0800

Hi Francisco,
At 09:09 06-11-2012, Francisco Obispo wrote:
>International + Localized information should fulfill most EPP 
>registries. Having an explicit language associated to the response 
>object is either going to force registries to return non-accurate 
>data, or run into a very complex validation problem down the line.

Yes.

Here's the alternative as I see it.  If I send you a UTF-8 text 
without any hint you'll have to go and figure out what to do with 
it.  If I understood what you said about, the following would be an issue:

   "multiple instances (representations) of the same object which MUST
    be tagged if there is more than one and MAY be tagged if it is a
    single one." [1]

There is a "MAY" in there which removes the explicit language 
association.  The problem would be the "more than one" case.  I don't 
see any other way out of that.

Regards,
-sm

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

---

From: Francisco Obispo <[email-masked]>
Date: Tue, 6 Nov 2012 09:59:30 -0800

On Nov 6, 2012, at 9:50 AM, SM <[email-masked]> wrote:

> Here's the alternative as I see it.  If I send you a UTF-8 text without any hint you'll have to go and figure out what to do with it.  If I understood what you said about, the following would be an issue:
> 
> There is a "MAY" in there which removes the explicit language association.  The problem would be the "more than one" case.  I don't see any other way out of that.
> 

Yes, I believe this will be an issue, now, what difference does it make if the information is in one language or another? (in terms of user experience), In our registry system we mandate an 'international' version of the contact, and we allow an optional localized version. We don't collect any language tag to describe the data because EPP lacks the ability to do so.

So in our case, we will always have a us-ascii version of it and an optional localized (utf-8).

In a whois system response in a system that is UTF-8 aware, we should respond with as much information as possible, not limit it because we're missing a language tag, or a specific field, in this case the more information the better.

So to solve the problem I would suggest making the "MUST" a "MAY" as well, or simply stating multiple "localized" versions.

Francisco

Francisco Obispo

---

From: Andrew Sullivan <[email-masked]>
Date: Tue, 6 Nov 2012 13:19:32 -0500

Dear colleagues,

> in whatever way it sees fit.

I'm fine with this approach, but I think that if the server has any
information about the language, script, or whatnot, it SHOULD use
language tags as defined by RFC 5646.  This nicely gets us both
"language" and "script" (and actually, a bunch of other stuff too, if
someone is foolish enough to use that).

These language tags provide a way for a client to do useful things
with the output.  If there is not such tag, then if a client wants to
do something useful, it has to guess, and that's a bad idea.  

It seems to me that we might want both the ability to place one tag on
the entire response, and also a tag on various parts.  This way, if a
repository only ever has one language and script it can just say that
once in a response; but at the same time a repository that has
different kinds of stuff in the same response can identify each part
accordingly.

Best,

A

-- 
Andrew Sullivan
[email-masked]

---

From: SM <[email-masked]>
Date: Tue, 06 Nov 2012 10:45:19 -0800

Hi Francisco,
At 09:59 06-11-2012, Francisco Obispo wrote:
>Yes, I believe this will be an issue, now, what difference does it 
>make if the information is in one language or another? (in terms of 
>user experience), In our registry system we mandate an 
>'international' version of the contact, and we allow an optional 
>localized version. We don't collect any language tag to describe the 
>data because EPP lacks the ability to do so.

Ok.  Although it has been mentioned that EPP is out of scope it's 
unlikely that the discussion will go far if that part is ignored.

>In a whois system response in a system that is UTF-8 aware, we 
>should respond with as much information as possible, not limit it 
>because we're missing a language tag, or a specific field, in this 
>case the more information the better.
>
>So to solve the problem I would suggest making the "MUST" a "MAY" as 
>well, or simply stating multiple "localized" versions.

How about changing the first MUST to a SHOULD?  The above should be 
possible with that.  You might run into problems outside the working 
group as people have their own interpretation of a "SHOULD".  If a 
"MAY" is used the working group is not encouraging future behavior.

Regards,
-sm

---

From: Francisco Obispo <[email-masked]>
Date: Tue, 6 Nov 2012 10:48:49 -0800

+1

On Nov 6, 2012, at 10:45 AM, SM <[email-masked]> wrote:

> How about changing the first MUST to a SHOULD?  The above should be possible with that.  You might run into problems outside the working group as people have their own interpretation of a "SHOULD".  If a "MAY" is used the working group is not encouraging future behavior.

Francisco Obispo

---

From: Peter Koch <[email-masked]>
Date: Tue, 6 Nov 2012 19:59:53 +0100

> group as people have their own interpretation of a "SHOULD".  If a 

I doubt this makes sense because it would leave the client confused.

-Peter

---

From: Frederico A C Neves <[email-masked]>
Date: Tue, 6 Nov 2012 17:21:01 -0200

Murray,

> I captured the proposal properly?)

I support this approach with the added comments from Peter's and
Andrew's messages. <[email-masked]>
<[email-masked]>

> -MSK

Fred

---

From: Andrew Sullivan <[email-masked]>
Date: Tue, 6 Nov 2012 14:22:19 -0500

> "MAY" is used the working group is not encouraging future behavior.

If we say "MUST", someone who doesn't have a tag can always use
"und":

Type: language
Subtag: und
Description: Undetermined
Added: 2005-10-16
Scope: special

Alternatively, we could specify explicitly that any untagged data
implicitly uses the und languge subtag, and proceed that way.  But I
do think that we need to make it possible for a server to provide data
that a client can use in this or that way, and without a language tag
that is difficult in some circumstances.

A

-- 
Andrew Sullivan
[email-masked]

---

From: Jim Galvin <[email-masked]>
Date: Tue, 06 Nov 2012 16:24:13 -0500

I very much support this approach.

I also agree with others in this thread who have pointed out that the 
response, however, should be tagged appropriately.  This may or may not 
imply that the data itself, in its actual repository, is tagged.  But 
the data in the response needs to be tagged, which includes deciding 
there's an implicit default tag.

Tagging should be granular enough such that it can be applied to 
individual elements, for some appropriate definition of element.

Jim

-- On November 5, 2012 11:21:28 PM -0500 "Murray S. Kucherawy" 
<[email-masked]> wrote regarding [weirds] Proposal for 
internationalization question --

> Is there any specific objection to that approach for this work? 
> (And have I captured the proposal properly?)
>
> -MSK

---

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

>individual elements, for some appropriate definition of element.

Can you give some examples where it would be useful to have a single
response with some elements in one language and some in another?

Also, if you agree that the server should return responses in whatever
languages it has, if a server has 16 fields, each of which has
versions in two languages (imagine all of the fields of a group of
names and addresses), does that mean the server should return 65,536
responses?  Assuming that's not what you had in mind, how many
responses should it return?

R's,
John

---

From: Francisco Obispo <[email-masked]>
Date: Tue, 6 Nov 2012 13:54:30 -0800

If someone went through the trouble of filling out this information, the least the registry can do is to offer that information ;-)

I don't think that will be the case though, I'm actually reluctant to bring EPP to the discussion again, but it is our input protocol, and as it is written, it only allows one "international" and one of type "loc", so even though we want to decouple the two protocols because not all registries use EPP, I think it's not feasible to ask more than what EPP can currently offer because implementing it would not be straightforward, but even if that was the case, the registry will have to "validate" the languages and that by itself can be problematic.

I like the approach where we have the "undefined" language as a tag where you don't have it, remember that we've made all the fields 'optional', so this is should be compatible with that.

Francisco

Francisco Obispo

---

From: Steve Sheng <[email-masked]>
Date: Tue, 6 Nov 2012 13:58:19 -0800

Hi, 

-----Original Message-----
From: Peter Koch <[email-masked]>
Date: Tuesday, November 6, 2012 7:56 AM
To: "[email-masked]" <[email-masked]>
Subject: Re: [weirds] Proposal for internationalization question

>respective repository/registry will be operated under.

I would like to strongly support Peter's point that whether a internet
registry provides localized content is a matter of policy and out of scope
for the working group.

Several options exist for how to publish the internationalized contact
information in Whois:

Option 1: Publish No internationalized registration data (status quo, but
unlikely given today's environment)

Option 2: Publish Internationalized contact data + translation of the
internationalized contact data

Option 3: Publish Internationalized contact data + transliteration of the
internationalized contact data

Option 4: Publish Internationalized data only, no additional requirements

There are pros and cons, feasibility and cost implications for each
option, and which one to select is a matter of either local ccTLD policy
or ICANN policy. 

For generic TLDs, there is an upcoming ICANN policy effort to determine
which option to choose (see
http://gnso.icann.org/en/resolutions/#20121017-5), and we welcome anyone
interested to participate.

The implication for protocol I see is if policy end up choosing 2 - 4, the
internationalized data needs to be tagged for end user clients to better
consume this information.

Kind regards, 
Steve

---

From: Andrew Sullivan <[email-masked]>
Date: Tue, 6 Nov 2012 17:08:36 -0500

> response with some elements in one language and some in another?

If contact data is stored in two languages and everything else is not
so taggged (perhaps only contact data has an internationalized form),
then the server would return one response with (say) the und- tag and
the portion of the response that has the other tag.

> responses should it return?

No, it returns one response with all the fields in both versions.
That's what I understood by "send everything and let the client sort
it out".

A

-- 
Andrew Sullivan
[email-masked]

---

From: Andrew Sullivan <[email-masked]>
Date: Tue, 6 Nov 2012 17:12:57 -0500

On Tue, Nov 06, 2012 at 01:54:30PM -0800, Francisco Obispo wrote:

> and as it is written, it only allows one "international" and one of
> type "loc", so even though we want to decouple the two protocols

I think it is plain that, if the internationalization and localization
concerns are real ones, that feature of EPP almost certainly needs to
be reconsidered.  We can't do anything about that here, but we can
build a protocol that can cope with a more sophisticated system.

As John Klensin was saying at the mic, one of the things we have
learned over recent years is "just use UTF-8 and you're done" is not
actually very good advice.  

Best,

A

-- 
Andrew Sullivan
[email-masked]

---

From: "John R Levine" <[email-masked]>
Date: 6 Nov 2012 17:42:09 -0500

> If someone went through the trouble of filling out this information, the 
> least the registry can do is to offer that information ;-)

Of course.  But realistically, you're going to have a name in all Japanese 
or all English, not one with even numbered fields in Japanese and odd 
numbered fields in English.

The question here is whether one language tag (possibly "und") for the 
whole response is adequate, or whether indvidual parts need separate tags. 
I strongly prefer the former.

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

---

From: Francisco Obispo <[email-masked]>
Date: Tue, 6 Nov 2012 14:46:34 -0800

I agree with you. My point is that we are going down the list of things that would be really nice to have in the output, that were never considered in the input.

If we need to reconsider the input, I'm all for that, and lets get it done.

Francisco

Francisco Obispo

---

From: Andrew Sullivan <[email-masked]>
Date: Tue, 6 Nov 2012 17:52:44 -0500

On Tue, Nov 06, 2012 at 05:42:09PM -0500, John R Levine wrote:
> The question here is whether one language tag (possibly "und") for
> the whole response is adequate, or whether indvidual parts need
> separate tags. I strongly prefer the former.

The plan that emerged in the meeting yesterday was "client can't
request stuff, server sends everything and then the client does
something sensible."  This means that, if the server has more than one
tagged dataset, you need to be able to tell which part is which kind
of thing.  Some kinds of data won't be different at all, and you don't
need that kind of response.  In a contact, for instance, in almost
every case you're not going to have different languages for the phone
number.  So there's no reason to send that twice.

A

-- 
Andrew Sullivan
[email-masked]

---

From: Peter Koch <[email-masked]>
Date: Wed, 7 Nov 2012 00:08:24 +0100

The level of detail we're approaching right now and here may already
be to deep.

> I strongly prefer the former.

"Language" is still the wrong term. Other than that, having the tags
per field rather than per object would need a use case. Also it would
allow for corner cases where there is no consistent representation
available over a full object (1st field "A" and "B", 2nd tagged "B"
and "C" and 3rd tagged "A" and "C"). The overhead of resending
common fields might be operationally negligible. So, "+.9".

-Peter

---

From: "Ning Kong" <[email-masked]>
Date: Wed, 7 Nov 2012 15:53:43 +0800

+1
It seems like that you have the similar idea as the 7.3 section of
draft-sheng-weirds-icann-rws-dnrd-01.

> I'm fine with this approach, but I think that if the server has any
information
> about the language, script, or whatnot, it SHOULD use language tags as
> defined by RFC 5646.  This nicely gets us both "language" and "script"
(and
> actually, a bunch of other stuff too, if someone is foolish enough to use
that).
> 
> These language tags provide a way for a client to do useful things with
the
> output.  If there is not such tag, then if a client wants to do something
useful,
> it has to guess, and that's a bad idea.
> 
> It seems to me that we might want both the ability to place one tag on the
> entire response, and also a tag on various parts.  This way, if a
repository
> only ever has one language and script it can just say that once in a
response;
> but at the same time a repository that has different kinds of stuff in the
same
> response can identify each part accordingly.

---

From: "Ning Kong" <[email-masked]>
Date: Wed, 7 Nov 2012 16:10:57 +0800

> I agree with you. My point is that we are going down the list of things
that
> would be really nice to have in the output, that were never considered in
the
> input.
Count me in, please.

---

From: "Linlin Zhou" <[email-masked]>
Date: Wed, 7 Nov 2012 16:38:31 +0800

> The question here is whether one language tag (possibly "und") for the
whole
> response is adequate, or whether indvidual parts need separate tags.
I support one tag for each response which is a simple solution in my
opinion. Although it may have duplicated information, such as telephone
number or fax number.
The latter one of tags for each object may cause some complexity. Until now
I have no better idea about how to structure the response format.

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

Linlin

---

From: Joseph Yee <[email-masked]>
Date: Wed, 7 Nov 2012 10:37:22 -0500

On Mon, Nov 5, 2012 at 11:21 PM, Murray S. Kucherawy
<[email-masked]> wrote:
> in whatever language(s) they have; the client will make use of that reply in
> whatever way it sees fit.
>

I support this approach.  Regarding how to tag response, one tag for
the whole response is more practical.  Tagging per line is very close
to impractical.  Most of the time, only the user (or registrant who
buys the domain name in name registry) know the exact language/script,
and I doubt that any form asks for both contact and the language
associate with it.  I don't mind (but strongly prefer not to)
"embedded" tagging, but it must be optional (and default to response's
value if absent).

I agreed with Andrew that using the tags from RFC 5646, we shouldn't
create new tags here.

Joseph

---

From: Andrew Sullivan <[email-masked]>
Date: Wed, 7 Nov 2012 11:03:59 -0500

On Wed, Nov 07, 2012 at 10:37:22AM -0500, Joseph Yee wrote:
> the whole response is more practical.  

Just to be clear, then:

The example we actually have is registries that use "two languages".
To state it more neutrally, we have some repositories that have data
that is associated with the same identifier, and that is encoded in
two different ways.  The general case is for data that is associated
with the same identifier, and is encoded in N ways.  

If the WG picks "one tag for whole response", then it is necessary to
send two responses for a single query, and to duplicate all the data
in common between those two responses.  The client (which IIRC was
often supposed to be "web browser parsing response") needs to be able
to handle these two responses in some way.  

If the WG picks "tags that apply to following data until next tag",
then it's possible to return one complete response, and then when you
get to the bits that have more than one (tagged) encoding, you just
return multiple entries of those bits, each with its relevant tag.

To me, the first if these is much easier for implementers of servers,
but may duplicate a lot of data.

The second of these reduces duplication of data, but perhaps makes the
processing more complicated.  With two encodings, the trade-off isn't
really worth it.  With more than two, we might find it is worth it.
Unfortunately, given the poor internationalization support to date, I
don't think actual whois implementations provide us any kind of
guidance about what people want.  All I know is that many, many people
have complained about internationalization here, and I'll be surprised
if every repository is forever nailed to two encodings of the data.

Best,

A

-- 
Andrew Sullivan
[email-masked]

---

From: Jim Galvin <[email-masked]>
Date: Wed, 07 Nov 2012 11:50:59 -0500

-- On November 6, 2012 9:47:10 PM +0000 John Levine <[email-masked]> 
wrote regarding Re: [weirds] Proposal for internationalization question 
--

> response with some elements in one language and some in another?

The simple example is a domain name in one "language" and the contact 
information in a different "language", including different contact 
information sets in different "languages".

> languages it has,

I agree this is an option and I agree this is where our discussions 
should start.  The client should be responsible for implementing 
whatever policy that is important to it for "filtering" the response(s).

> if a server has 16 fields, each of which has

If the WG agreed protocol action is that all matching information 
should be returned then yes, 65,536 responses should be returned. 
However, clearly as an operational principle that's just silly.  As 
engineers we should think a bit more about what is the right answer 
here.

I don't know yet if the number of responses should be limited nor what 
that number should be if it is limited.  I'm still wondering if we'll 
ever have a situation like you describe.

Jim

---

From: Andy Newton <[email-masked]>
Date: Thu, 8 Nov 2012 12:40:30 +0000

>if every repository is forever nailed to two encodings of the data.

This is where I get hosed. What do you mean by "encodings" in the above?
Isn't that totally different than a language tag? I would think that
multiple encodings (as I understand that term) would not only be
problematic but nearly impossible. While multiple language tags would be
relatively trivial.

-andy