Re: [ire] CSV: contactPostal clarification question

"Gould, James" <> Wed, 16 October 2013 20:00 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 19CFD11E82DE for <>; Wed, 16 Oct 2013 13:00:41 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -6.599
X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id O8GQSTLOBUf4 for <>; Wed, 16 Oct 2013 13:00:36 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 95B6C11E82ED for <>; Wed, 16 Oct 2013 13:00:34 -0700 (PDT)
Received: from ([]) (using TLSv1) by ([]) with SMTP ID; Wed, 16 Oct 2013 13:00:36 PDT
Received: from ( []) by (8.13.6/8.13.4) with ESMTP id r9GK0WZM031158 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 16 Oct 2013 16:00:33 -0400
Received: from ([::1]) by ([::1]) with mapi id 14.02.0342.003; Wed, 16 Oct 2013 16:00:32 -0400
From: "Gould, James" <>
To: Klaus Malorny <>, "" <>
Thread-Topic: [ire] CSV: contactPostal clarification question
Thread-Index: AQHOym7l3dOgkVhqp0aRnO+xHyUWrJn4iQAA
Date: Wed, 16 Oct 2013 20:00:31 +0000
Message-ID: <>
In-Reply-To: <>
Accept-Language: en-US
Content-Language: en-US
user-agent: Microsoft-MacOutlook/
x-originating-ip: []
Content-Type: text/plain; charset="us-ascii"
Content-ID: <>
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
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: Wed, 16 Oct 2013 20:00:41 -0000


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


James Gould
Principal Software Engineer
703-948-3271 (Office)
12061 Bluemont Way
Reston, VA 20190

On 10/16/13 8:53 PM, "Klaus Malorny" <> wrote:

>Hi all,
>I am still a bit puzzled about the "contactPostal" table, containing the
>internationalized/localized postal data (section 5.3.2, pages 55 et seqq.
>of [1]).
>On the one hand, there is a flag field, csvContact:fPostalType, which
>whether name, organization, street, city, state/province, postal and
>code fields shall be regarded as internationalized or localized. On the
>hand, these fields may contain their own "isLoc" attribute, indicating
>Are these alternatives? I.e. one registry could decide to use the
>In this case, the fields themselves would not use the "isLoc" attribute.
>A row 
>would contain either the internationalized _or_ the localized data set,
>never both. So the registry would have to actually use two rows in the
>case that 
>it wants to provide both. Or the registry could decide not to use the
>fPostalType, but to add the isLoc attribute to the field definitions. In
>case, a row could contain data for the internationalized _or_ localized
>both data sets.
>Is this correct?
>ire mailing list