Gustavo, Thanks for outlining these approaches. My comments are in-line:
> On Jul 21, 2016, at 3:08 AM, Gustavo Lozano <[email protected]> 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. > > 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. 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. > 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. 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 _______________________________________________ regext mailing list [email protected] https://www.ietf.org/mailman/listinfo/regext
