[gtld-tech] RDAP questions

Francisco Arias francisco.arias at icann.org
Fri Nov 10 07:42:19 UTC 2017


Hi Taras,

I'll attempt to provide some answers, but I should mention that for RDAP questions in general (as opposed to those related to the pilot program) there is the REGEXT mailing list in the IETF at https://www.ietf.org/mailman/listinfo/regext

The question of language tags for the registration data is something that is being considered in the gTLD space as part of the work to implement the policy recommendations regarding Translation and Transliteration of contact data. If it is of interest, you can find the implementation page at https://www.icann.org/resources/pages/transliteration-contact-2016-06-27-en. We have identified the same issue you raise, i.e., the potential need of an EPP extension to transmit the language tags. Work is still ongoing.

I'd agree with 1a below, i.e., unless you have a "policy requirement" you can provide an RDAP response without language tags since they are optional in RDAP.

Regarding your second question, I think RDAP allows you to redact the responses, please look at section 9 of RFC 7483. I must confess I don't know the answer to your specific question about FN, perhaps others in this list or in the REGEXT mailing list may be able to provide a better answer. You may want to take a look at the RDAP pilots listed at https://docs.google.com/spreadsheets/d/e/2PACX-1vTT4uM8RxJx6L7IEUJpdfa-JqE6Fn-98tZUT2L90uZuSrQk_7QF12spelQN0un0hhhjRUtrs5Xrb0Pg/pubhtml?gid=1777559671&single=true to see what they are doing.

-- 
Francisco


On 11/10/17, 12:24 AM, "gtld-tech-bounces at icann.org on behalf of Taras Heichenko" <gtld-tech-bounces at icann.org on behalf of tasic at hostmaster.ua> wrote:

    Hi all!
    According to https://community.icann.org/display/RP/RDAP+Pilot this mailing list is used for RDAP pilot program. I work at .UA registry and we plan to implement RDAP. But during RFCs reading I got some questions. I wrote one question to another mailing list and had received some answers with possible solutions. But variants are questionable (I will show them after question) and may be anyone has better solutions.
    1. Contact data of our registrants can be in ASCII encoding (international-int) and/or in UTF-8 encoding (local-loc). For local data the UTF-8 encoding is used but language of data is not defined. It is impossible to define language because EPP does not provide language definition mechanism. So when we show ENTITY we can not define strings language for local data according to vCard RFC. The question is: How should we present data in conformity with RFC?
    To this question I received two answers:
    1a. Do not define language at all. Just include multiply values without language definition. As for me this answer does not conflict with RFC but it is very inconvenient for user recognition and/or data processing (we do not think that JSON is the best format for data presentation for end user, isn't it?)
    1b. The second advice is better (as for me). Int and loc data we can separate by ALTID property parameter. This allows at least differentiate data of different languages and encoding. Of course we just shift data representation to those who will process and present received JSON data. But all local data uses UTF-8 encoding and this should not cause any problem on web.
    But may be anyone has better solution for this question?
    2. The second question is also concerns of entity data presentation. According to legislation of our country private person may demand to hide private data. In this case registrator  in EPP request defines fields that must not be shown. Besides all it can be registrant's name. According to vCard RFC FN field is mandatory but according to our legislation sometimes I must not show this field. What should I do in this case? Do not show this entity at all? Or may be I should write "privacy protected" in FN field? Any ideas?
    
    --
    Best regards
    
    Taras Heychenko
    tasic at hostmaster.ua
    
    
    
    
    
    



More information about the gtld-tech mailing list