Handling of "loc" and "int" contacts
All, We're currently evaluating the options regarding the "int" and "loc" postalInfo elements of the EPP contact mapping. Currently, we use the "int" type exclusively, but looking at the recent developtments in the "IRD" area (http://singapore49.icann.org/en/schedule/wed-ird-requirements), we're looking into the options to move forward with allowing "loc" postalInfo types as well. I'm trying to grasp a "sense of the room" with regards to the following questions, and would appreciate feedback: - For registries that implement "loc" postalInfo, which of the options do you support? a) just "loc" b) either "loc" or "int" c) "int" required, "loc" optional d) "loc" required, "int" optional - For registries that allow both "loc" and "int", do you require any connection between the two postalInfo data sets (for example, "identical cc", or "identical pc"?) - For registries that allow both "loc" and "int", which of the two are you displaying in WHOIS? Are you trying to serve "different views" depending on user location or (in the case of web whois) user agent information (eg. "accept-language" header?) - Do you limit the text contents of "loc" fields to a certain sensible subset of UTF-8, for example to the set of scripts that are also the basis for the registry's IDN tables? Feedback appreciated :) thanks, Alex
Hi Alex,
We're currently evaluating the options regarding the "int" and "loc" postalInfo elements of the EPP contact mapping. Currently, we use the "int" type exclusively, but looking at the recent developtments in the "IRD" area (http://singapore49.icann.org/en/schedule/wed-ird-requirements), we're looking into the options to move forward with allowing "loc" postalInfo types as well.
I'm trying to grasp a "sense of the room" with regards to the following questions, and would appreciate feedback:
- For registries that implement "loc" postalInfo, which of the options do you support? a) just "loc" b) either "loc" or "int" c) "int" required, "loc" optional d) "loc" required, "int" optional
e) one of "loc" or "int" is required, the other optional
- For registries that allow both "loc" and "int", do you require any connection between the two postalInfo data sets (for example, "identical cc", or "identical pc"?)
No.
- For registries that allow both "loc" and "int", which of the two are you displaying in WHOIS? Are you trying to serve "different views" depending on user location or (in the case of web whois) user agent information (eg. "accept-language" header?)
No, we display both, for example, "Name" and "Ext. Name"
- Do you limit the text contents of "loc" fields to a certain sensible subset of UTF-8, for example to the set of scripts that are also the basis for the registry's IDN tables?
No, we also allow characters that are not within the same script. After all, a Latin-script domain could also be registered by someone living in China. And why shouldn't he be allowed to enter his localised address. Best regards, Michael -- TANGO REGISTRY SERVICES® is a product of: Knipp Medien und Kommunikation GmbH Dr. Michael Bauland Technologiepark Phone: +49 231 9703-0 Martin-Schmeisser-Weg 9 Fax: +49 231 9703-200 D-44227 Dortmund E-Mail: Michael.Bauland@knipp.de Germany
Hi Alex, On 24 Apr 2014, at 9:18 AM, Alexander Mayrhofer <alexander.mayrhofer@nic.at> wrote:
All,
We're currently evaluating the options regarding the "int" and "loc" postalInfo elements of the EPP contact mapping. Currently, we use the "int" type exclusively, but looking at the recent developtments in the "IRD" area (http://singapore49.icann.org/en/schedule/wed-ird-requirements), we're looking into the options to move forward with allowing "loc" postalInfo types as well.
I'm trying to grasp a "sense of the room" with regards to the following questions, and would appreciate feedback:
- For registries that implement "loc" postalInfo, which of the options do you support? a) just "loc" b) either "loc" or "int" c) "int" required, "loc" optional d) "loc" required, "int" optional
Either "loc" or "int" the other is optional
- For registries that allow both "loc" and "int", do you require any connection between the two postalInfo data sets (for example, "identical cc", or "identical pc"?)
No
- For registries that allow both "loc" and "int", which of the two are you displaying in WHOIS? Are you trying to serve "different views" depending on user location or (in the case of web whois) user agent information (eg. "accept-language" header?)
"loc" falling back to "int" - besides that, nothing fancy
- Do you limit the text contents of "loc" fields to a certain sensible subset of UTF-8, for example to the set of scripts that are also the basis for the registry's IDN tables?
No Kind regards, Mike O'Connell ZACR EPP Administrator
Alex, My feedback is below. -- JG James Gould Principal Software Engineer jgould@verisign.com 703-948-3271 (Office) 12061 Bluemont Way Reston, VA 20190 VerisignInc.com On 4/24/14, 3:18 AM, "Alexander Mayrhofer" <alexander.mayrhofer@nic.at> wrote:
All,
We're currently evaluating the options regarding the "int" and "loc" postalInfo elements of the EPP contact mapping. Currently, we use the "int" type exclusively, but looking at the recent developtments in the "IRD" area (http://singapore49.icann.org/en/schedule/wed-ird-requirements), we're looking into the options to move forward with allowing "loc" postalInfo types as well.
I'm trying to grasp a "sense of the room" with regards to the following questions, and would appreciate feedback:
- For registries that implement "loc" postalInfo, which of the options do you support? a) just "loc" b) either "loc" or "int" c) "int" required, "loc" optional d) "loc" required, "int" optional
b) either ³loc² or ³int"
- For registries that allow both "loc" and "int", do you require any connection between the two postalInfo data sets (for example, "identical cc", or "identical pc"?)
n/a
- For registries that allow both "loc" and "int", which of the two are you displaying in WHOIS? Are you trying to serve "different views" depending on user location or (in the case of web whois) user agent information (eg. "accept-language" header?)
n/a
- Do you limit the text contents of "loc" fields to a certain sensible subset of UTF-8, for example to the set of scripts that are also the basis for the registry's IDN tables?
No, all UTF-8 characters is supported.
Feedback appreciated :)
thanks, Alex
Hi Alex, I added the .be way of working inline. Kind regards, Loesje Hermans Functional Analyst +32 16 29 89 23 DNS Belgium vzw/asbl Ubicenter - Philipssite 5, bus 13 - 3001 Leuven www.dnsbelgium.be On 24 Apr 2014, at 09:18, Alexander Mayrhofer <alexander.mayrhofer@nic.at> wrote:
All,
We're currently evaluating the options regarding the "int" and "loc" postalInfo elements of the EPP contact mapping. Currently, we use the "int" type exclusively, but looking at the recent developtments in the "IRD" area (http://singapore49.icann.org/en/schedule/wed-ird-requirements), we're looking into the options to move forward with allowing "loc" postalInfo types as well.
I'm trying to grasp a "sense of the room" with regards to the following questions, and would appreciate feedback:
- For registries that implement "loc" postalInfo, which of the options do you support? a) just "loc" b) either "loc" or "int" c) "int" required, "loc" optional d) "loc" required, "int” optional We only accept type ‘loc’. When ‘int’ is specified we answer with a 2306 parameter value policy error.
- For registries that allow both "loc" and "int", do you require any connection between the two postalInfo data sets (for example, "identical cc", or "identical pc”?) na
- For registries that allow both "loc" and "int", which of the two are you displaying in WHOIS? Are you trying to serve "different views" depending on user location or (in the case of web whois) user agent information (eg. "accept-language" header?) na
- Do you limit the text contents of "loc" fields to a certain sensible subset of UTF-8, for example to the set of scripts that are also the basis for the registry's IDN tables? Yes, we limit to a set of 200 characters. This set covers the most frequently used characters in Belgium. Because we want our support to be able to read the entered data and we want to be able to reproduce all entered characters in pdf documents, like our WHOIS certificate.
Feedback appreciated :)
thanks, Alex
Hi Alexander, Here’s what we do at Uniregistry. On Apr 24, 2014, at 12:18 AM, Alexander Mayrhofer <alexander.mayrhofer@nic.at> wrote:
All,
We're currently evaluating the options regarding the "int" and "loc" postalInfo elements of the EPP contact mapping. Currently, we use the "int" type exclusively, but looking at the recent developtments in the "IRD" area (http://singapore49.icann.org/en/schedule/wed-ird-requirements), we're looking into the options to move forward with allowing "loc" postalInfo types as well.
I'm trying to grasp a "sense of the room" with regards to the following questions, and would appreciate feedback:
- For registries that implement "loc" postalInfo, which of the options do you support? a) just "loc" b) either "loc" or "int" c) "int" required, "loc" optional d) "loc" required, “int” optional
Option C.
- For registries that allow both "loc" and "int", do you require any connection between the two postalInfo data sets (for example, "identical cc", or "identical pc”?)
No
- For registries that allow both "loc" and "int", which of the two are you displaying in WHOIS? Are you trying to serve "different views" depending on user location or (in the case of web whois) user agent information (eg. "accept-language" header?)
Int - we don’t want to display the ‘loc’ in whois because clients are not expected to support UTF-8
- Do you limit the text contents of "loc" fields to a certain sensible subset of UTF-8, for example to the set of scripts that are also the basis for the registry's IDN tables?
no. free form UTF-8 accepted.
Feedback appreciated :)
thanks, Alex
participants (6)
-
Alexander Mayrhofer -
Francisco Obispo -
Gould, James -
Loesje Hermans -
Michael Bauland -
Mike O'Connell