Re: [ire] CSV: contactPostal clarification question

"Gould, James" <JGould@verisign.com> Thu, 17 October 2013 20:52 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 2A08611E81E1 for <ire@ietfa.amsl.com>; Thu, 17 Oct 2013 13:52:48 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.599
X-Spam-Level:
X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[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 j4BtokojCv1N for <ire@ietfa.amsl.com>; Thu, 17 Oct 2013 13:52:43 -0700 (PDT)
Received: from exprod6og125.obsmtp.com (exprod6og125.obsmtp.com [64.18.1.218]) by ietfa.amsl.com (Postfix) with ESMTP id 58AD521F8CCB for <ire@ietf.org>; Thu, 17 Oct 2013 13:52:39 -0700 (PDT)
Received: from osprey.verisign.com ([216.168.239.75]) (using TLSv1) by exprod6ob125.postini.com ([64.18.5.12]) with SMTP ID DSNKUmBOFy2xN1fxii9jUXRGK7eoGsZQy8zA@postini.com; Thu, 17 Oct 2013 13:52:41 PDT
Received: from brn1wnexcas01.vcorp.ad.vrsn.com (brn1wnexcas01.vcorp.ad.vrsn.com [10.173.152.205]) by osprey.verisign.com (8.13.6/8.13.4) with ESMTP id r9HKqcPs002272 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 17 Oct 2013 16:52:38 -0400
Received: from BRN1WNEXMBX01.vcorp.ad.vrsn.com ([::1]) by brn1wnexcas01.vcorp.ad.vrsn.com ([::1]) with mapi id 14.02.0342.003; Thu, 17 Oct 2013 16:52:37 -0400
From: "Gould, James" <JGould@verisign.com>
To: Klaus Malorny <Klaus.Malorny@knipp.de>, "ire@ietf.org" <ire@ietf.org>
Thread-Topic: [ire] CSV: contactPostal clarification question
Thread-Index: AQHOym7l3dOgkVhqp0aRnO+xHyUWrJn4iQAAgABwS4CAAUFWgA==
Date: Thu, 17 Oct 2013 20:52:36 +0000
Message-ID: <CE8679E3.5041D%jgould@verisign.com>
In-Reply-To: <525FBF0B.9010607@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: <6C05859BE8BAE1428073B3E5E2756F6D@verisign.com>
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Subject: Re: [ire] CSV: contactPostal clarification question
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: Thu, 17 Oct 2013 20:52:48 -0000

Klaus,

Yes, you are correct.  If a registry decided to implement the "int" and
"loc" type of <contact:postalInfo> using a single record with a set of
columns per type.  I do not believe this is optimal but it is certainly
possible.  We could tighten up the draft to normalize this with splitting
of the columns into separate CSV records by making the
csvContact:fPostalType field required for the "contactPostal" CSV file.
What do you think?

-- 
 
JG
 

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




On 10/17/13 7:42 PM, "Klaus Malorny" <Klaus.Malorny@knipp.de> wrote:

>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):
>
>   <csvContact:contents>
>    ...
>      <rdeCsv:csv name="contactPostal">
>        <rdeCsv:fields>
>          <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"/>
>        </rdeCsv:fields>
>        <rdeCsv:files>
>          <rdeCsv:file
>            cksum="02CC2504">
>            contactPostal-YYYYMMDD.csv
>          </rdeCsv:file>
>        </rdeCsv:files>
>      </rdeCsv:csv>
>    ...
>    </csvRegistrar:contents>
>
>Do you agree?
>
>Regards,
>
>Klaus
>