Hi,
Il 20/09/2023 18:34, Pawel Kowalik ha scritto:
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.
[ML] I agree with Pawel that the main values should be separated from
their language-dependent variants. In addition, it seems to me that the
simple contact data model allows for some inconsistencies.
For example, it allows for multiple individual names.
I'm perfectly know that it doesn't correspond to a real case but the
point is that, in theory, the current model allows for that.
This is because of the lacking of constraints.
Representing the individual name information as a single text wouldn't
allow to set multiple individual names accidentally.
In addition, using simple type values whenever it is possible allows to
validate the objects against some constraints by simply annotating the
object members in the source code.
Lists have still the issue of addressing the list elements with JSON
Pointers in redaction process.
[ML] This is one of the reasons why almost all of the JSContact
collections are maps. The drawbacks from using JSONPointers in
JSContact localizations are the same as those from using JSONPaths in
the 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.
[ML] Having multiple properties representing localizations is
inefficient in my opinion. Grouping all the localizations in one
property makes very easy for a client to know if there are localizations
or not and process all the localizations in the same way.
In addition, if this model will ever be extended with a property
admitting languange-dependent variants, there will be no need to define
an additional property representing the related localizations.
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.
[ML] Why doesn't the postal address include a property representing the
city ? The country code and the city are required information in RFC5733
while the postal code is optional.
Last, since the RDAP implementers have already mapped the RFC5733 "addr"
elements to the related vCard ADR elements, why should they change that
mapping instead of simply replacing the target properties with new ones ?
An unstructured address can be represented through a seprated property.
Best,
Mario
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 unterhttps://www.denic.de/datenverarbeitung-allgemein/
_______________________________________________
regext mailing list
regext@ietf.org
https://www.ietf.org/mailman/listinfo/regext
--
Dott. Mario Loffredo
Senior Technologist
Technological Unit “Digital Innovation”
Institute of Informatics and Telematics (IIT)
National Research Council (CNR)
via G. Moruzzi 1, I-56124 PISA, Italy
Phone: +39.0503153497
Web:http://www.iit.cnr.it/mario.loffredo
_______________________________________________
regext mailing list
regext@ietf.org
https://www.ietf.org/mailman/listinfo/regext
