Re: [ire] CSV: contactPostal clarification question

Klaus Malorny <> Thu, 17 October 2013 10:43 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 41CF811E8174 for <>; Thu, 17 Oct 2013 03:43:36 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
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 ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id xdN7m9r82H8l for <>; Thu, 17 Oct 2013 03:43:21 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id DB5FF11E8135 for <>; Thu, 17 Oct 2013 03:43:18 -0700 (PDT)
Received: from localhost ( []) by (Postfix) with ESMTP id DB65E45; Thu, 17 Oct 2013 12:43:17 +0200 (MESZ)
X-Knipp-VirusScanned: Yes
Received: from ([]) by localhost ( []) (amavisd-new, port 10004) with ESMTP id uwZklb9H05je; Thu, 17 Oct 2013 12:42:13 +0200 (MESZ)
Received: from ( []) by (Postfix) with ESMTP id 72A514F; Thu, 17 Oct 2013 12:42:13 +0200 (MESZ)
Received: from [] ( []) by (@(#)Sendmail version 8.13.3 - Revision 1.000 - 1st August,2006/8.13.3) with ESMTP id r9HAgCZ0001646; Thu, 17 Oct 2013 12:42:13 +0200 (MESZ)
Message-ID: <>
Date: Thu, 17 Oct 2013 12:42:19 +0200
From: Klaus Malorny <>
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:27.0) Gecko/20100101 Thunderbird/27.0a1
MIME-Version: 1.0
To: "Gould, James" <>, "" <>
References: <>
In-Reply-To: <>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Subject: Re: [ire] CSV: contactPostal clarification question
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "Internet Registration Escrow discussion list." <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Thu, 17 Oct 2013 10:43:36 -0000

On 16.10.2013 22:00, Gould, James wrote:
> Klaus,
> The use of the csvContact:fPostalType and the "isLoc" attribute covers two
> different use cases.  One is using the csvContact:fPostalType field to
> allow the data field to define the internationalized form of an entire
> record, so it is data driven instead of being directly defined within the
> XML manifest file.  The "isLoc" attribute allows for specifying the
> internationalized form directly within the XML manifest file, where it is
> not data driven.  The csvContact:fPostalType field can be used in the
> "contactPostal" csv file to match up with RFC 5733, while the "isLoc"
> attribute value can be used to define the form in the "registrar" csv
> file.

Hi James,

yes, I understood this so far, but this does not really answer my question. 
Maybe I made my point not clear enough. Just as a background information, I ask 
these questions not because we want to generate CSV format, but we need to read 
this (in the context of EBERO). So from my understanding, it would be valid for 
a registry regarding the -05 version of the document to omit the "fPostalType" 
field at all (since it is not "required") and include two sets of fields, if it 
meets its needs, for example, if both versions are mandatory. This could look 
like the following (modified example from the specs):

      <rdeCsv:csv name="contactPostal">
          <csvContact:fId parent="true"/>
          <csvContact:fName isLoc="0"/>
          <csvContact:fOrg isLoc="0"/>
          <csvContact:fStreet isLoc="0" index="0"/>
          <csvContact:fStreet isLoc="0" index="1"/>
          <csvContact:fStreet isLoc="0" index="2"/>
          <csvContact:fCity isLoc="0"/>
          <csvContact:fSp isLoc="0"/>
          <csvContact:fPc isLoc="0"/>
          <csvContact:fCc isLoc="0"/>
          <csvContact:fName isLoc="1"/>
          <csvContact:fOrg isLoc="1"/>
          <csvContact:fStreet isLoc="1" index="0"/>
          <csvContact:fStreet isLoc="1" index="1"/>
          <csvContact:fStreet isLoc="1" index="2"/>
          <csvContact:fCity isLoc="1"/>
          <csvContact:fSp isLoc="1"/>
          <csvContact:fPc isLoc="1"/>
          <csvContact:fCc isLoc="1"/>

Do you agree?