Subject: [weirds] Comments on draft-ietf-weirds-json-response-03.txt

From: Gavin Brown <[email-masked]>
Date: Tue, 09 Apr 2013 20:19:28 +0100

Hi all,

The latest update to the json-response draft has introduced some
significant changes -- and complexity -- to the format and contents of
RDAP responses. As the developer of both client and server
implementations of RDAP, I have some comments regarding this.

1. vCard

I have no particular preference for vCard or any other format for
address information. However I would like to note that the suggestion
that vCard be used was prompted by my request that entity responses
allowed for structured address data, so that address data held by DNRs
is not represented in a lossy way.

We now have a situation where vCard is used to represent address
information -- at the cost of a more complex data model -- but address
data is still a flat array of strings, so my original suggestion has
still not been satisfied.

2. Events

I can understand why the new event model has been added. It allows for
more events to be represented than the previous model, which just
supported timestamps for registration, expiration, and the last update.

However, the new model is more complicated for both client and server
implementers, the use of the free-form "eventAction" doesn't meet the
goal of properly structured data, and also makes internationalisation
harder. If this property is used, the values it can take should be
enumerated.

3. Embedding

The new draft allows entities to be embedded into events. Of course,
events can also be embedded into entities. This allows for recursion.
Instead of allowing full entities to be embedded into an event, the
specification should recommend the use of an elided entity object
containing just a handle and a link object. In fact, my preference would
be for such elided objects to be used whenever one object is embedded
inside another.

G.

-- 
Gavin Brown
Chief Technology Officer
CentralNic Ltd
Innovative, Reliable and Flexible Registry Services
for ccTLD, gTLD and private domain name registries
https://www.centralnic.com/

CentralNic Ltd is a company registered in England and Wales with company
number 4985780. Registered Offices: 35-39 Moorgate, London, EC2R 6AR.

---

From: Andy Newton <[email-masked]>
Date: Tue, 9 Apr 2013 20:00:24 +0000

Gavin,

Thanks for looking at the latest document. My comments are in-line:

>still not been satisfied.

I think it is just a matter of providing examples that use structured
addresses with jCard. Perhaps Scott and I should start thinking of an
appendix which discusses the use of structured and unstructured addresses
with jCard. But jCard can support both.

>harder. If this property is used, the values it can take should be

Like status, role relationships, and variant relationships, the suggested
event actions are listed in an appendix (see Appendix A.2, page 40). I
just noticed that xml2rfc left out the table of contents, so that is
probably very easy to miss. Appendix C (page 46) discusses the event
modeling.

It might be that we want to create expert-review or first-come,
first-serve IANA registries for all these values, not just the event
actions.

>be for such elided objects to be used whenever one object is embedded

I agree that recursive entity embedding would be bad. And by that I mean
entities that embed entities. However, I don't believe the new event model
allows that. Certainly it could be that a domain embeds a name server that
embeds an entity, but that would be true even with the old event model.

-andy

---

From: Ernie Dainow <[email-masked]>
Date: Fri, 12 Apr 2013 13:12:30 -0400

> with jCard. But jCard can support both.
Many examples have vCard entries. I would prefer one section on vCard 
showing a few examples, and then just referring back to that section 
instead of repeating the same vCard in all examples as in the current draft.

In discussions about remarks and notices, it was concluded that the 
server should not be doing formatting. The inclusion of the \n control 
character in the vCard examples is inconsistent with this principle.

Instead of:
  [ "label", {}, "text", "123 Maple Ave\n",
                         "Suite 90001\n",
                         ...
Can we not do:
  [ "label", {}, "text", ["123 Maple Ave", "Suite 90001", ...]

-Ernie

---

From: Andy Newton <[email-masked]>
Date: Fri, 12 Apr 2013 19:16:14 +0000

>  [ "label", {}, "text", ["123 Maple Ave", "Suite 90001", ...]

Ernie,

I think the \n is the unstructured jCard. Honestly, I don't know enough
about jCard to tell you if the examples shouldn't have \n in them, though
I certainly understand your point.

-andy

---

From: Simon Perreault <[email-masked]>
Date: Sat, 13 Apr 2013 18:11:39 +0200

> I certainly understand your point.

In this particular case, with the label property, the embedded \n is 
correct. An array would not be. That's because the value of the label 
property is defined as a single text value in vCard (RFC 6350).

Simon
-- 
DTN made easy, lean, and smart --> http://postellation.viagenie.ca
NAT64/DNS64 open-source        --> http://ecdysis.viagenie.ca
STUN/TURN server               --> http://numb.viagenie.ca