Re: [ire] CSV woes

"Gould, James" <JGould@verisign.com> Tue, 01 October 2013 13:18 UTC

Return-Path: <JGould@verisign.com>
X-Original-To: ire@ietfa.amsl.com
Delivered-To: ire@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 42A6121E8200 for <ire@ietfa.amsl.com>; Tue, 1 Oct 2013 06:18:23 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.745
X-Spam-Level:
X-Spam-Status: No, score=-5.745 tagged_above=-999 required=5 tests=[AWL=0.854, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9V7k8ifNVb7J for <ire@ietfa.amsl.com>; Tue, 1 Oct 2013 06:18:18 -0700 (PDT)
Received: from exprod6og110.obsmtp.com (exprod6og110.obsmtp.com [64.18.1.25]) by ietfa.amsl.com (Postfix) with ESMTP id 4A23C21E81E2 for <ire@ietf.org>; Tue, 1 Oct 2013 06:18:15 -0700 (PDT)
Received: from osprey.verisign.com ([216.168.239.75]) (using TLSv1) by exprod6ob110.postini.com ([64.18.5.12]) with SMTP ID DSNKUkrLlpF6yH/xOfxc7HnbvfWaQAfXeMoA@postini.com; Tue, 01 Oct 2013 06:18:16 PDT
Received: from brn1wnexcas02.vcorp.ad.vrsn.com (brn1wnexcas02.vcorp.ad.vrsn.com [10.173.152.206]) by osprey.verisign.com (8.13.6/8.13.4) with ESMTP id r91DIAG6018860 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 1 Oct 2013 09:18:11 -0400
Received: from BRN1WNEXMBX01.vcorp.ad.vrsn.com ([::1]) by brn1wnexcas02.vcorp.ad.vrsn.com ([::1]) with mapi id 14.02.0342.003; Tue, 1 Oct 2013 09:18:09 -0400
From: "Gould, James" <JGould@verisign.com>
To: Klaus Malorny <Klaus.Malorny@knipp.de>, "ire@ietf.org" <ire@ietf.org>
Thread-Topic: [ire] CSV woes
Thread-Index: AQHOvpF5xwHv3nLgJEqR3DpisfF13pnf1CcA
Date: Tue, 1 Oct 2013 13:18:08 +0000
Message-ID: <CE703AC8.4EADE%jgould@verisign.com>
In-Reply-To: <524AA490.9060808@knipp.de>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
user-agent: Microsoft-MacOutlook/14.3.6.130613
x-originating-ip: [10.173.152.4]
Content-Type: text/plain; charset="us-ascii"
Content-ID: <9B7E71E8CA44E34D8B13EF197DA5BBE1@verisign.com>
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Subject: Re: [ire] CSV woes
X-BeenThere: ire@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "Internet Registration Escrow discussion list." <ire.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ire>, <mailto:ire-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/ire>
List-Post: <mailto:ire@ietf.org>
List-Help: <mailto:ire-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ire>, <mailto:ire-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 01 Oct 2013 13:18:23 -0000

Klaus,

I respond to your feedback below.

-- 
 
JG
 

 
James Gould
Principal Software Engineer
jgould@verisign.com
 
703-948-3271 (Office)
12061 Bluemont Way
Reston, VA 20190
VerisignInc.com




On 10/1/13 6:31 AM, "Klaus Malorny" <Klaus.Malorny@knipp.de>; wrote:

>
>
>Hi all,
>
>unfortunately, I now have to deal with the CSV format and read through
>the -05 
>version* of the document (previously, I skipped that CSV parts). I got
>the 
>following questions:
>
>- the separator: a separator different to the default comma separator can
>   be specified by the "sep" attribute. Following the schema definition,
>   it can be any token, including multi-character strings or even an empty
>   string (which makes the file unparsable, of course). I don't think that
>   this is intended

Good catch, we can update the schema to support a single character for the
separator like below:

...
    <attribute name="sep" type="rdeCsv:sepType" default=","/>
...

   <simpleType name="sepType">
      <restriction base="string">
         <minLength value="1"/>
         <maxLength value="1"/>
      </restriction>
   </simpleType>

Do you have any additional proposals on restrictions?




>
>- it is left open how to deal with special characters, including, but
>   not limited to, quotes, separators and newlines. I wonder why there
>   is no reference to RFC 4180

Additional clarity could be added here.
draft-arias-noguchi-dnrd-objects-mapping does not conform to RFC 4180
(e.g. No header and support for UTF-8), but elements of RFC 4180 could be
used to provide additional clarity around the handling of quotes,
separators, and newlines in the CSV files.


>
>- it is unclear to me why the "deletes" entries may have subtables
>included,
>   e.g. the "csvDomain:deletes" the "domainContacts", as depicted in
>   the example in section 5.1.2 on page 23. Does it mean that in
>incremental or
>   differential escrows, the CSV format allows the addition and removal of
>   individual multi-value entries? For example, if I have the domain
>   "example.tld", and the technical contact has changed from "abc123" to
>   "def456", the "domainContacts" table in the <csvDomain:contents>
>   section would *only* contain the line
>
>     example.tld,def456,tech
>
>   (and missing the admin and billing references) and the "domainContacts"
>   table in the <csvDomain:deletes> section would contain an entry
>
>     example.tld,abc123,tech
>
>   This would be a large difference to the XML format, as there the full
>   object is always being replaced, and it would be also quite a hassle
>and
>   error-prone to generate or read and process this.


Yes, the CSV model is relational based and not object based, so
incremental and differential deposits are done at the record level and not
at the object level.  The "domainContacts" CSV file, either used under the
<csvDomain:contents> or <csvDomain:deletes> elements, represents the link
table between the domain and the contact CSV files.  With the CSV files,
you apply the deltas at the record level as opposed to the object level.
That is the fundamental difference between the XML and CSV models in
draft-arias-noguchi-dnrd-objects-mapping.

>
>- I do not understand why in "domainNameServers", hosts are referenced
>   by their ROIDs, whereas in "domainContacts", contacts are referenced
>   by their IDs, especially as this seems to have been changed to the
>   worse. The specification argues with supporting both hostAttr and
>hostObj
>   models, however, it leaves completely open how the hostAttr model
>   is represented.

The hosts are referenced by ROIDs instead of the host name, since use of a
natural key (host name), will not work for some host models (hostAttr as
well as having a separate set of external hosts per registrar) and will
not support host name changes.  A host name change should only result in a
change to a single record and not all links to that host record.  The
contact identifier is unique and can't be changed, so it can be used
directly without use of a surrogate key via the ROID.

>
>These are the questions for now, maybe more come later ;-)

Thank you for your feedback.

>
>Regards,
>
>Klaus
>
>
>
>* http://tools.ietf.org/html/draft-arias-noguchi-dnrd-objects-mapping-05
>_______________________________________________
>ire mailing list
>ire@ietf.org
>https://www.ietf.org/mailman/listinfo/ire