Hi Pawel,
This is a very interesting idea. Even in non-EPP registries, it is
unlikely that more than one representation of a name, etc.. will be
collected. Therefore, this reduction makes sense to me. I disagree
with wrapping name and role in the postal information as those
elements are used for non postal reasons and there are definitely
non-EPP registries that do not model this the same way.
-andy
On Wed, Sep 20, 2023 at 12:34 PM Pawel Kowalik <pawel.kowa...@denic.de> wrote:
>
> Hi Andrew,
>
> The new draft goes in the right direction, but for me there are still few
> elements, that seem to be too complex for the purpose.
>
> For all fields there is an assumed plurality with lists of values, where
> theoretically the only differentiator should be the localization, however
> actually the data structure does not exclude that there are several values
> with the same localization or without any localization, which might be
> confusing and also requires a complex processing by the clients to always
> iterate the whole list in order to find out if there is a certain
> localization present in the response.
>
> Lists have still the issue of addressing the list elements with JSON Pointers
> in redaction process.
>
> As localization is a specific use case and would used on a need basis, the
> case of single value being the main use-case, I would rather see the values
> to be singular international value, with a localization being a separate
> optional dictionary.
>
> Using the example from 2.8 of a draft it would be something like this:
>
> {
>
> "individualName": "Yomada Taro",
>
> "individualNameLoc": {
>
> "ja": "山田太郎"
>
> }
>
> }
>
> This approach allows a very compact representation if there is no
> localization provided, and also a deterministic data structure if the
> localization is necessary. It matches also EPP model in RFC 5733, where
> actually max 2 postalInfo objects are allowed, one in internationalized and
> one in local version.
>
> An access to the localization can be also very easily be implemented by the
> clients by looking up if the "Loc" key is present and then by dictionary
> lookup of the needed localization.
>
> I also suggest to stick to the field names and structure as defined in RFC
> 5733, rather than defining new names or partially reusing existing ones..
>
> addr instead of postalAddress
>
> streets instead of address
>
> postalInfo as a wrapping object etc.
>
>
> Example of complete simple contact (without localization):
>
> {
> "objectClassName" : "entity",
> "handle":"XXXX",
> "sc_data": {
> "kind" : "individual",
> "postalInfo": {
> "individualName" : "Yomada Taro",
> "roleName" : "Registration Services Help Desk",
> "organizationName" : "ACME",
> "addr" : {
> "streets" : [
> "Sunny Mansion #203",
> "4-7 Hommachi 2-choume",
> "Shibuya-ku, TOKYO 150-2345"
> ],
> "cc" : "JP-13",
> "pc" : "150-2345"
> }
> },
> "email" : "yamada.t...@example.net",
> "voice" : ["+81(03) 1234-5678"],
> "fax:" : ["tel:+810312345679"],
> "webContacts" : ["https://example.net/contact-me";]
> }
> ...
> }
>
> Kind Regards,
>
> Pawel
>
>
> Am 31.08.23 um 12:02 schrieb Andrew Newton:
>
> Hi all,
>
> We have posted an update to Simple Contact. Here are the summary of the
> changes:
>
> * removed structured names
> * removed structured addresses
> * fixed ISO-3166-2 usage
> * removed the "masked" property
> * updated the example
> * added a section on linking to vcard / jcard / jscontact
>
> Overall, this simplifies the draft significantly, which was the
> overall feedback from IETF 117.
>
> -andy
>
> ---------- Forwarded message ---------
> From: <internet-dra...@ietf.org>
> Date: Thu, Aug 31, 2023 at 5:56 AM
> Subject: New Version Notification for
> draft-newton-regext-rdap-simple-contact-01.txt
> To: Andy Newton <a...@hxr.us>, Tom Harrison <t...@apnic.net>
>
>
> A new version of Internet-Draft draft-newton-regext-rdap-simple-contact-01.txt
> has been successfully submitted by Andy Newton and posted to the
> IETF repository.
>
> Name: draft-newton-regext-rdap-simple-contact
> Revision: 01
> Title: RDAP Simple Contact
> Date: 2023-08-31
> Group: Individual Submission
> Pages: 11
> URL:
> https://www.ietf.org/archive/id/draft-newton-regext-rdap-simple-contact-01.txt
> Status:
> https://datatracker.ietf.org/doc/draft-newton-regext-rdap-simple-contact/
> HTML:
> https://www.ietf.org/archive/id/draft-newton-regext-rdap-simple-contact-01.html
> HTMLized:
> https://datatracker.ietf.org/doc/html/draft-newton-regext-rdap-simple-contact
> Diff:
> https://author-tools.ietf.org/iddiff?url2=draft-newton-regext-rdap-simple-contact-01
>
> Abstract:
>
> This document describes an extension to the Registry Data Access
> Protocol for entity contact data using basic JSON values, objects,
> and arrays. The data model defined by this document is purposefully
> limited to the data in-use by Internet Number Registries and Domain
> Name Registries and does not attempt to model the full data-set that
> can be expressed with other contact models such as jCard or
> JSContact.
>
>
>
> The IETF Secretariat
>
> _______________________________________________
> regext mailing list
> regext@ietf.org
> https://www.ietf.org/mailman/listinfo/regext
>
> Pawel Kowalik
> Head of Product Management
> --
> DENIC eG, Theodor-Stern-Kai 1, 60596 Frankfurt am Main, GERMANY
> E-Mail: pawel.kowa...@denic.de, Fon: +49 69 27235-105, Fax: -235
> https://www.denic.de
>
>
>
> Angaben nach § 25a Absatz 1 GenG: DENIC eG (Sitz: Frankfurt am Main)
> Vorstand: Thomas Keller, Martin Küchenthal, Andreas Musielak, Sebastian
> Röthler
> Vorsitzender des Aufsichtsrats: Daniel Rink
> Eingetragen unter Nr. 770 im Genossenschaftsregister, Amtsgericht Frankfurt
> am Main
>
>
>
> Allgemeiner Hinweis zur Erfüllung unserer Informationspflichten gemäß Art.
> 13, Art. 14 DS-GVO: Informationen zur Verarbeitung personenbezogener Daten
> durch DENIC finden Sie unter https://www.denic.de/datenverarbeitung-allgemein/
_______________________________________________
regext mailing list
regext@ietf.org
https://www.ietf.org/mailman/listinfo/regext
