Subject: [weirds] I-D Action: draft-ietf-weirds-json-response-03.txt

From: [email-masked]
Date: Mon, 08 Apr 2013 19:24:02 -0700

A New Internet-Draft is available from the on-line Internet-Drafts directories.
 This draft is a work item of the Web Extensible Internet Registration Data Service Working Group of the IETF.

	Title           : JSON Responses for the Registration Data Access Protocol (RDAP)
	Author(s)       : Andrew Lee Newton
                          Scott Hollenbeck
	Filename        : draft-ietf-weirds-json-response-03.txt
	Pages           : 51
	Date            : 2013-04-08

Abstract:
   This document describes JSON data structures representing
   registration information maintained by Regional Internet Registries
   (RIRs) and Domain Name Registries (DNRs).  These data structures are
   used to form Registration Data Access Protocol (RDAP) query
   responses.

The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-weirds-json-response

There's also a htmlized version available at:
http://tools.ietf.org/html/draft-ietf-weirds-json-response-03

A diff from the previous version is available at:
http://www.ietf.org/rfcdiff?url2=draft-ietf-weirds-json-response-03

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

---

From: Andy Newton <[email-masked]>
Date: Tue, 9 Apr 2013 02:28:49 +0000

All,

There are a lot of changes in this version based on the discussion in the
working group.
Here is the change log:

Added jCard verbiage and examples and deleted overlapping
         contact information and the appendix on postal addresses

         Removed the IANA considerations as they have been moved to
         another document

         Changed the remarks structure to be like notices

         Reordering and rewording some of the sections so they flow
         better

         Added note about object class "self" links

         Changed ipAddresses in nameserver object class to separate out
         v6 from v4

         Changed IP network version identifier from integer to string to
         be more consistent with ipAddresses identifier in nameserver
         object classes

         Changed DNS names to LDH names and Unicode names

         Modified the definition of 'conjoined' variant relationship so
         it was circular

         Added 'proxy', 'private', 'redacted', and 'obscured' status
         values (most useful for entities).

         Added a privacy considerations section

         Added a security considerations section

         Added 'reseller' and 'sponsor' to the list of entity roles

         Added the 'events' common data structure

         Added 'asEventActor' to entities

         Added appendix on event modeling

         Removed the subclasses/superclassing between RIRs/DNRs for
         entity and domain object classes

         Change suggested status/relation/etc values to be case/spacing
         consistent

         Normalized some of the definitions of object class members

         Modifying the JSON signaling section to reference the guidance
         in draft-ietf-weirds-using-http
<http://tools.ietf.org/html/draft-ietf-weirds-using-http>

         Changed the text regarding the process of unknown JSON
         attributes

-andy

On 4/8/13 10:24 PM, "[email-masked]" <[email-masked]>
wrote:

>_______________________________________________
>weirds mailing list
>[email-masked]
>https://www.ietf.org/mailman/listinfo/weirds
>

---

From: Jean-Philippe Dionne <[email-masked]>
Date: Wed, 10 Apr 2013 12:52:44 -0400

Hi,

>           Changed DNS names to LDH names and Unicode names

Is the "ldhName" property mendatory and "unicodeName" optional?

The unicode name, as it is defined in 
draft-ietf-weirds-json-response-03#section-4 , cannot represent a 100% 
ASCII domain name:

    Unicode names:    Textual representations of DNS names were one or
                      more of the labels are u-labels as described by
                      [RFC5890].  Trailing periods are optional.

and following into rfc5890#section-2.3.2.1 :

  A "U-label" is an IDNA-valid string of Unicode characters, in
       Normalization Form C (NFC) and including at least one non-ASCII
       character, expressed in a standard Unicode Encoding Form (such as
       UTF-8).

Regards
Jean-Philippe

---

From: Andy Newton <[email-masked]>
Date: Thu, 11 Apr 2013 13:49:31 +0000

Jean-Philippe,

Thanks for the comments. My reply is in-line:

>Is the "ldhName" property mendatory and "unicodeName" optional?

Good point. I would think that ldhName is a SHOULD with unicodeName
OPTIONAL.

>       character, expressed in a standard Unicode Encoding Form (such as

To represent 100% ASCII in unicodeName, our restriction could be changed
to "where zero or more of the labels are u-labelsŠ". But I don't
understand. What's the point of populating unicodeName with a 100% ASCII
domain name?

-andy

---

From: Jean-Philippe Dionne <[email-masked]>
Date: Thu, 11 Apr 2013 10:12:03 -0400

Hi,

> understand. What's the point of populating unicodeName with a 100% ASCII

The definition doesn't have to be changed. I just wanted to show that, 
according to the definitions, unicodeName couldn't be used in all 
situation and had to be OPTIONAL.

Thanks
Jean-Philippe

---

From: Simon Perreault <[email-masked]>
Date: Thu, 11 Apr 2013 16:18:01 +0200

> situation and had to be OPTIONAL.

OPTIONAL is incorrect.  unicodeName MUST be present if the name has a 
u-label representation.

But even for pure ASCII names I think unicodeName should be there. I 
don't want to sprinkle all my future scripts with "if unicodeName is 
present then use it, otherwise use ldhName". I just want to get to the 
Unicode representation, and I don't care if it's full ASCII or not.

Simon

---

From: Andy Newton <[email-masked]>
Date: Thu, 11 Apr 2013 18:22:50 +0000

>OPTIONAL is incorrect.  unicodeName MUST be present if the name has a

Well, the MUST use unicodeName if they want to express the unicode
version. But it is all up to registry police. Certainly use of unicodeName
is RECOMMENDED if the domain name is an IDN.

>Unicode representation, and I don't care if it's full ASCII or not.

Unfortunately, that is all up to the policy of the registry.

-andy

---

From: Simon Perreault <[email-masked]>
Date: Thu, 11 Apr 2013 20:46:58 +0200

> Unfortunately, that is all up to the policy of the registry.

I don't get why this is a policy issue. If it's not provided by the 
server, it can be computed by the client. Providing it is just being 
nice so that clients don't need to implement the complex IDNA machinery.

Maybe I missed something...

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

---

From: Dmitry Kohmanyuk <[email-masked]>
Date: Thu, 11 Apr 2013 22:13:06 +0300

> Unfortunately, that is all up to the policy of the registry.

if registry has IDN names, it has to provide their IDNA form (A-label) as ldhName and possibly U-label (in unicodeName);
if registry has only ASCII names, it should provide them as ldhName;  unicodeName can be used, or not.

so ldhName field is MUST, and unicodeName is SHOULD?   Some registries (UA included) provide only A-labels in whois.

Personally, if I would be writing a client I would use my own Unicode conversion if needed - but i can see why
somebody may want decoded name and encoded name fields.  So the rationale was to make it easier for clients?

---

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

> somebody may want decoded name and encoded name fields.  So the rationale was to make it easier for clients?
There was also discussion of including the "IDN table identifier" with 
unicode names. Has this been ruled out?
http://www.ietf.org/mail-archive/web/weirds/current/msg02391.html

-Ernie

---

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

>http://www.ietf.org/mail-archive/web/weirds/current/msg02391.html

This was an oversight. Though looking over that draft it isn't apparent to
me which tables identifiers are being referenced. Is there more specific
information?

-andy

---

From: Ernie Dainow <[email-masked]>
Date: Fri, 12 Apr 2013 16:15:49 -0400

> me which tables identifiers are being referenced. Is there more specific
http://www.iana.org/domains/idn-tables

-Ernie

---

From: Dmitry Kohmanyuk <[email-masked]>
Date: Fri, 12 Apr 2013 23:55:01 +0300

> >http://www.ietf.org/mail-archive/web/weirds/current/msg02391.html

this refers to 

http://tools.ietf.org/html/draft-obispo-epp-idn-02

which was recently updated (April 5th) - but that draft has no reference to IDN table repository 
 ("provided by (EPP) server" identifier is mentioned, only.)

> http://www.iana.org/domains/idn-tables

those tables are not very usable as machine-readable registry - as their format is usually free-formed text.

a (working draft) document was written by Kim Davies a while ago to offer XML format for them, 
but have not been adopted by IANA yet.  I don't have reference to it on hand.

also, multiple table versions may exist - but only last one is referenced from this page.

also, URLs are constructed (usually) using triple of IDNA-converted TLD names, language, and version identifiers - 
  for example, http://www.iana.org/domains/idn-tables/tables/xn--90a3ac_cyrl_1.1.html - but sometimes 
  convention is a bit different, e.g. http://www.iana.org/domains/idn-tables/tables/pl_sr-pl_1.0.html 
     for Serbian names in PL - here, it looks like "sr-pl" is used instead of just sr as language tag.

-- dk@

---

From: Ernie Dainow <[email-masked]>
Date: Fri, 12 Apr 2013 17:25:01 -0400

On Fri, Apr 12, 2013 at 4:55 PM, Dmitry Kohmanyuk <[email-masked]> wrote:

> also, URLs are constructed (usually) using triple of IDNA-converted TLD
> names, language, and version identifiers -
>   for example,
> http://www.iana.org/domains/idn-tables/tables/xn--90a3ac_cyrl_1.1.html -
> but sometimes
>   convention is a bit different, e.g.
> http://www.iana.org/domains/idn-tables/tables/pl_sr-pl_1.0.html

I would expect RDAP to return only the name of the table, like  ".ASIA
Japanese", and optionally a url link. I think most clients/users want to
know primarily the language of the IDN, and only secondarily the full table
of code points.

-Ernie