Subject: [ire] CSV woes

From: Klaus Malorny <[email-masked]>
Date: Tue, 01 Oct 2013 12:31:44 +0200

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

- 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

- 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.

- 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.

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

Regards,

Klaus

* http://tools.ietf.org/html/draft-arias-noguchi-dnrd-objects-mapping-05

---

From: "Gould, James" <[email-masked]>
Date: Tue, 1 Oct 2013 13:18:08 +0000

Klaus,

I respond to your feedback below.

-- 
 
JG

James Gould
Principal Software Engineer
[email-masked]
 
703-948-3271 (Office)
12061 Bluemont Way
Reston, VA 20190
VerisignInc.com

>   string (which makes the file unparsable, of course). I don't think that

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?

>   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.

>   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.

>   models, however, it leaves completely open how the hostAttr model

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.

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

---

From: Klaus Malorny <[email-masked]>
Date: Tue, 01 Oct 2013 16:09:57 +0200

> Klaus,

Hi James,

> [...]

Yes, that makes sense. Just forgot that host names may change. As talking of 
hosts, there seems to be a small inconsistency in section 5.2.1.3: it says that 
the fName field is mandatory in "host", but the example for deleting hosts (page 
41) omits it.

Regards,

Klaus

---

From: Klaus Malorny <[email-masked]>
Date: Fri, 04 Oct 2013 12:33:07 +0200

Hi,

just another discovery: It seems to be that the specification* contains IANA 
namespace applications in section 11 that are actually not used in any way, 
namely all those starting with "urn:ietf:params:xml:schema:". I expected the 
elements defining the fields of the CSV files to use these (as one could regard 
this as a schema definition), but this is not the case. It would be nice if 
someone could clarify this.

Regards,

Klaus

---

From: "Gould, James" <[email-masked]>
Date: Fri, 4 Oct 2013 13:31:46 +0000

Klaus,

Each of the XSD's referenced in the I-D includes a set of IANA URI
requests for both urn:ietf:params:xml:ns (e.g.
urn:ietf:params:xml:ns:rdeCsv-1.0) and urn:ietf:params:xml:schema (e.g.
urn:ietf:params:xml:schema:rdeCsv-1.0).  The  urn:ietf:params:xml:schema
URI's are used to register the schemas and the urn:ietf:params:xml:ns
URI's are used within the XML documents that use that schema.  The field
definitions for the CSV model within the XML manifest file follow the same
convention that is used for the XML model, where there is a schema that
contains the definitions and a namespace URI that is used within the XML
manifest file.  In the case of the CSV model, the fields define the format
of the CSV files that would be used by a CSV validator.  There is a level
of indirection with the fields, since they are directly validated using an
XML parser in the XML manifest file and they include a type attribute,
with a XSD type value, that is validated by a CSV validator in the
referenced CSV files.   I don't believe there is any substantial
difference between the XML and CSV models when it comes to the IANA URI
requests.  Let me know if I'm missing something from your question.

Thanks,

-- 
 
JG

James Gould
 
703-948-3271 (Office)
12061 Bluemont Way
Reston, VA 20190
VerisignInc.com

---

From: Klaus Malorny <[email-masked]>
Date: Fri, 04 Oct 2013 17:29:57 +0200

On 04.10.2013 15:31, Gould, James wrote:
> urn:ietf:params:xml:schema:rdeCsv-1.0).
> [...]
>
> Thanks,
>

Hi James,

thanks. I was not fully aware of the RFC 3866 registration procedures, i.e. that 
the registered "schema" URIs refer to the actual XML Schema files themselves and 
are not other namespace URIs. So that makes now sense to me.

Regards,

Klaus