Subject: [regext] Postal-address transformation in RDAP

From: Gustavo Lozano <[email-masked]>
Date: Thu, 21 Jul 2016 01:08:50 +0000

Hello WG,
 
During the presentation of draft-lozano-regext-rdap-transf-contact-inf in
the IETF96, it was mentioned that there could be other options to represent
transformations (i.e. translations and transliterations) in RDAP, for
example, within the jCard itself.
 
These are the possibilities that were analyzed while writing the draft:

It’s worth mentioning that the policy recommendation requires to show the
source of the transformation (e.g. registry, registrar, etc), and the type
of transformation (e.g. translation or transliteration).
 
Option 1:
* Use the ALTID vCard parameter to represent the transformations.
* Register new parameters in the vCard elements registry
(http://www.iana.org/assignments/vcard-elements/vcard-elements.xhtml) to
show the source of the transformation, and the type of transformation.
 
I think that these parameters are too specific to the DNS industry,
therefore it may not be a good idea to register them in the vCard elements
registry.
 
Option 2:
* Use the ALTID vCard parameter to represent the transformations.
* Include new elements in the JSON response to show the source of the
transformation, and the type of transformation. A PID parameter could be
used to reference the transformation within the vCard.
 
I think this option is complex. The advantage is that there is no need to
add new parameters to the vCard elements registry.
 
Option 3:
Using additional jCard objects to represent the transformations. This option
is explained in draft-lozano-regext-rdap-transf-contact-inf-00.
 
Option 4:
Use the NOTE vCard property to specify the extra transformation information.
I don't like this idea, because we can end with overloading the NOTE
property (similar to the overloading of the TXT RRTYPE).
 
What option do you think should be preferred?
Any other options worth considering?
Additional feedback?
 
Example of option 1:
 
 "entities": [
    {
     "objectClassName": "entity",
      "handle": "XXXX",
     "vcardArray": [
       "vcard",
        [
          [
           "version",
            {},
           "text",
           "4.0"
          ],
          [
           "fn",
            {
             "language": "ru",
              "altid": "1",
             "infSource": "registrant",
             "transMechanism": "authoritative"
            },
           "text",
            "Иван Петрович Сидоров"
          ],
          [
           "fn",
            {
             "language": "ru-Latn",
             "altid": "1",
             "infSource": "registrar",
             "transMechanism": "transliteration",
             "transliterationStd": "iso9"
            },
           "text",
            "Ivan Petrovič Sidorov"
          ]
        ]
      ]
    }
  ]
 
Examples of option 2:
 
 "entities": [
    {
     "objectClassName": "entity",
     "handle": "XXXX",
     "vcardArray": [
       "vcard",
        [
          [
           "version",
            {},
            "text",
           "4.0"
          ],
          [
           "fn",
            {
             "language": "ru",
             "altid": "1",
             "pid": "1"
            },
           "text",
            "Иван Петрович Сидоров"
          ],
          [
           "fn",
            {
             "language": "ru-Latn",
             "altid": "1",
             "pid": "2"
            },
           "text",
            "Ivan Petrovič Sidorov"
          ]
        ]
      ],
     "transformations": [
        {
         "objectClassName": "transformation",
         "pidRef": "1",
         "infSource": "registrant",
         "transMechanism": "authoritative"
        },
        {
          "objectClassName": "transformation",
         "pidRef": "2",
         "infSource": "registrar",
         "transMechanism": "transliteration",
         "transliterationStd": "iso9"
        }
      ]
    }
  ]
 
Regards,
Gustavo

---

From: Andy Newton <[email-masked]>
Date: Thu, 21 Jul 2016 07:47:10 +0000

Gustavo,

Thanks for outlining these approaches. My comments are in-line:

> On Jul 21, 2016, at 3:08 AM, Gustavo Lozano <[email-masked]> wrote:
> 
> Hello WG,
>  
> During the presentation of draft-lozano-regext-rdap-transf-contact-inf in the IETF96, it was mentioned that there could be other options to represent transformations (i.e. translations and transliterations) in RDAP, for example, within the jCard itself.
>  
> It’s worth mentioning that the policy recommendation requires to show the source of the transformation (e.g. registry, registrar, etc), and the type of transformation (e.g. translation or transliteration).
>  
> Option 1:
> * Register new parameters in the vCard elements registry (http://www.iana.org/assignments/vcard-elements/vcard-elements.xhtml) to show the source of the transformation, and the type of transformation.
>  
> I think that these parameters are too specific to the DNS industry, therefore it may not be a good idea to register them in the vCard elements registry.

This is the approach I favor the most as it keeps the vCard information in one place, and from what I can tell, allows a more discreet level of identifying the vCard elements for translation/transliteration. By keeping it all in one place, clients are in a better position to extract the information.

I disagree that the parameters are too specific, though the values for the parameters are specific to this industry. The parameters could be placed in the IANA registry with generic values, and your RDAP draft could narrow the values to specific RDAP uses.

Here’s what I am thinking:
* “infoSource” - a URI. For RDAP, it is the URI pointing to the RDAP entity, which is either a registry or registrar.
* “transMechanism” - a string. For RDAP, the known strings values are ‘translation’ and ‘transliteration’
* “transliterationStd” - a string.

> * Include new elements in the JSON response to show the source of the transformation, and the type of transformation. A PID parameter could be used to reference the transformation within the vCard.
>  
> I think this option is complex. The advantage is that there is no need to add new parameters to the vCard elements registry.

I agree, but I still like option 1.

>  
> Option 3:
> Using additional jCard objects to represent the transformations. This option is explained in draft-lozano-regext-rdap-transf-contact-inf-00.
>  
> Option 4:
> Use the NOTE vCard property to specify the extra transformation information. I don't like this idea, because we can end with overloading the NOTE property (similar to the overloading of the TXT RRTYPE).

I agree. Overloading NOTE is not helpful.

-andy