[ire] CSV woes

Klaus Malorny <Klaus.Malorny@knipp.de> Tue, 01 October 2013 10:31 UTC

Return-Path: <Klaus.Malorny@knipp.de>
X-Original-To: ire@ietfa.amsl.com
Delivered-To: ire@ietfa.amsl.com
Received: from localhost (localhost []) by ietfa.amsl.com (Postfix) with ESMTP id 0A41F21F9D44 for <ire@ietfa.amsl.com>; Tue, 1 Oct 2013 03:31:58 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.249
X-Spam-Status: No, score=-3.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id FfL6f2GjuO3T for <ire@ietfa.amsl.com>; Tue, 1 Oct 2013 03:31:52 -0700 (PDT)
Received: from kmx10a.knipp.de (clust3c.bbone.knipp.de []) by ietfa.amsl.com (Postfix) with ESMTP id 2B2C821F8F9A for <ire@ietf.org>; Tue, 1 Oct 2013 03:31:50 -0700 (PDT)
Received: from localhost (localhost.bbone.knipp.de []) by kmx10a.knipp.de (Postfix) with ESMTP id C48A649; Tue, 1 Oct 2013 12:31:48 +0200 (MESZ)
X-Knipp-VirusScanned: Yes
Received: from kmx10a.knipp.de ([]) by localhost (kmx10a.knipp.de []) (amavisd-new, port 10004) with ESMTP id 4DS2rdGLhvrB; Tue, 1 Oct 2013 12:31:43 +0200 (MESZ)
Received: from hp9000.do.knipp.de (hp9000.do.knipp.de []) by kmx10a.knipp.de (Postfix) with ESMTP id 17A4B48; Tue, 1 Oct 2013 12:31:43 +0200 (MESZ)
Received: from [] (mclane.do.knipp.de []) by hp9000.do.knipp.de (@(#)Sendmail version 8.13.3 - Revision 1.000 - 1st August,2006/8.13.3) with ESMTP id r91AVfF8028434; Tue, 1 Oct 2013 12:31:42 +0200 (MESZ)
Message-ID: <524AA490.9060808@knipp.de>
Date: Tue, 01 Oct 2013 12:31:44 +0200
From: Klaus Malorny <Klaus.Malorny@knipp.de>
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:27.0) Gecko/20100101 Thunderbird/27.0a1
MIME-Version: 1.0
To: ire@ietf.org
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Subject: [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 10:31:58 -0000

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


   (and missing the admin and billing references) and the "domainContacts"
   table in the <csvDomain:deletes> section would contain an entry


   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 ;-)



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