Re: [weirds] Internationalization Issues

[MasaYUKI Okada <[e-mail]>]

Byron-san,

This is only my opinion.  My expectations on language support as
this time is follow line:
(There is no difference of opinion with the Kentaro-san too.)

- Specified response code at the time of inquiry

Now we are changing the response by the end of the '/e' string.

It may be sufficient to give the '/e' string to the end of the 
inquiry also the protocol under discussion(draft-ietf-weirds-rdap-query-00??)
 now.

However, anticipation of standardization, should not an adhoc approach 
like this '/e' might be good for us. 
It may be able to specify the response code when whois queried.

Thank you for the question.

-- 
Masayuki Okada
JPNIC

(2012/10/24 19:01), Kentaro Mori wrote:
> Byron-san;
> 
> (2012/10/24 14:12), Byron Ellacott wrote:
>> Thank you both for your input.  If you are intending to implement a weirds service down the line, what would be your expectations on language support in the protocol?
> 
> 'My current' expectations on language support are like follows:
> (Frankly saying, I haven't completely caught up on the context/concept
> of the protocol, so if they won't make sense for your arguments sorry
> for that, and there is a possibility that I change my mind as my
> understanding develops)
> 
> - default language (or character code) specification feature
> In a case client has no ability to specify which language it prefers,
> it would be not so good for server to return data of all language it
> supports other than to return data by default language, as I believe
> vast majority of whois.jprs.jp user won't expect to obtain data by 'both
> of Japanese and English' or 'English only' (so you would be a very rare
> user :)
> ; and I wonder this is a protocol stuff or not?
> 
> - language (or character code) tag for each element
> 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 language tag is for a set of elements,
> client will have no clue for determining which element of one language
> corresponds to which element of other language.
> 
> - character code specification feature
> In Japan, sometimes client software encounters failure in automatic
> judgment of encoding character code such as between ISO-2022-JP and
> Shift-JIS, so apparent indication of encoding by server will be welcomed.
> 
> Thanks for questioning,
> 
> Kentaro
> 
>>
>>   Byron
>>
>> On 24/10/2012, at 3:09 PM, MasaYUKI Okada <[e-mail]> wrote:
>>
>>> Byron-san,
>>>
>>> I'm Masayuki Okada at JPNIC.
>>>
>>> Our WHOIS system(whois.nic.ad.jp:43) will response English(ASCII)
>>> if '/e' is put into the character of the last of an input. 
>>>
>>> By default, it answers in Japanese(ISO-2022-JP). 
>>>
>>> About main registration records, JPNIC are collecting both Japanese 
>>> and English as an mandantory.
>>>
>>> just for reference:
>>>  - How to use JPNIC WHOIS - 
>>>   http://www.nic.ad.jp/en/db/whois/
>>>
>>> --
>>> Masayuki Okada
>>> JPNIC
>>>
>>> (2012/10/24 11:59), Kentaro Mori wrote:
>>>> Byron-san and folks,
>>>>
>>>> I'm Kentaro Mori from JPRS.
>>>> (sorry for late reply)
>>>>
>>>> For Whois, JPRS collects English data as well as native (Japanese) one
>>>> at the time registrant applies to .JP domain name registration.
>>>> Additionally, the English data doesn't cover all of Japanese data,
>>>> e.g., it is partial.
>>>> ISO-2022-JP as character-set was a normal choice when JPRS (more
>>>> correctly, JPNIC at that time) started Whois service, though we may have
>>>> alternative choice such as UTF-8 now.
>>>>
>>>> --Kentaro
>>>>
>>>> (2012/10/22 9:56), Byron Ellacott wrote:
>>>>>
>>>>> On 19/10/2012, at 9:33 PM, Andy Newton <[e-mail]> wrote:
>>>>>
>>>>>> On 10/18/12 8:40 PM, "Byron Ellacott" <[e-mail]> wrote:
>>>>>>
>>>>>>> Indicate to the end user that it's not a native language?
>>>>>>> Auto-translate?
>>>>>
>>>>> Murray has the right sense of what I meant, for both of these.
>>>>>
>>>>>>> Negotiate for native language with Accepts-Language, if indicated as
>>>>>>> possible via a Vary header?
>>>>>>
>>>>>> That's HTTP layer stuff. We're talking about embedding multiple language
>>>>>> tags in the response.
>>>>>
>>>>> Are we?  I thought draft-sheng-weirds-icann-rws-dnrd-01 sect. 7.3
>>>>> suggested a single language tag for the entire response, with "possible
>>>>> considerations" of multiple language tags.
>>>>>
>>>>> But, with this point, what I'm suggesting is that the user of a particular
>>>>> client likely has one or a few preferred languages, which they could
>>>>> potentially indicate to the server, in the event that the server has multiple
>>>>> translations.  This would be applicable for mixed language responses as
>>>>> well as single language responses, since it only indicates a client preference,
>>>>> not a strict requirement.
>>>>>
>>>>> My primary perspective on this entire subject is that whatever mechanisms
>>>>> or systems indicate language or language preference need to be optional,
>>>>> and should support reasonable use cases for current or likely future operators.
>>>>> I think there's a use case for language preference indication, as per below,
>>>>> and I think Ning is suggesting a use case for tagging the language of an
>>>>> entire response, inline in the response.  What are your (collective "your")
>>>>> thoughts on how reasonable these use cases are?
>>>>>
>>>>>>> Some RDAP services will not support multiple languages meaningfully, but
>>>>>>> there are existing whois services that provide (non-standard, varying)
>>>>>>> ways to indicate a preferred language on query, with multiple language
>>>>>>> options available for many response fields.
>>>>>>
>>>>>> Can you provide an example of one of these services so we can query it?
>>>>>> That would go a long way in helping shape this need, I would think. Are
>>>>>> there registries that collect contact data in multiple languages?
>>>>>
>>>>> $ whois -h whois.nic.ad.jp -- 'NET 113.32.19.157'
>>>>> $ whois -h whois.nic.ad.jp -- 'NET 113.32.19.157 /e'
>>>>>
>>>>> $ whois -h whois.jprs.jp -- 'jprs.jp'
>>>>> $ whois -h whois.jprs.jp -- 'jprs.jp /e'
>>>>>
>>>>> The data labels are sometimes translated, sometimes not.  In the native
>>>>> language responses, there's often an English translation.  JPRS includes
>>>>> an English help/info block even for the native language response.  I don't
>>>>> know for sure if they collect the information in multiple languages, though
>>>>> I think they do - any JPRS or JPNIC operators on the list to confirm?
>>>>> Character set is ISO-2022-JP.
>>>>>
>>>>> I don't know if there are other services with such a switch mechanism,
>>>>> either - we're all aware of how hard it is to find out what's actually done
>>>>> out there on port 43 :-) - but for another comparison whois.kisa.kr returns
>>>>> both native and english output, at least for "kisa.kr".  Character set is
>>>>> EUC-KR.
>>>>>
>>>>>  Byron
>>>>>
>>>>>
>>>>>
>>>>> _______________________________________________
>>>>> weirds mailing list
>>>>> [e-mail]
>>>>> https://www.ietf.org/mailman/listinfo/weirds
>>>>>
>>>>
>>>>
>>>>
>>>> _______________________________________________
>>>> weirds mailing list
>>>> [e-mail]
>>>> https://www.ietf.org/mailman/listinfo/weirds
>>>>
>>>
>>> _______________________________________________
>>> weirds mailing list
>>> [e-mail]
>>> https://www.ietf.org/mailman/listinfo/weirds
>>
> 
> 
>