Re: [ire] CSV: contactPostal clarification question

"Gould, James" <JGould@verisign.com> Wed, 16 October 2013 20:00 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 19CFD11E82DE for <ire@ietfa.amsl.com>; Wed, 16 Oct 2013 13:00:41 -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 O8GQSTLOBUf4 for <ire@ietfa.amsl.com>; Wed, 16 Oct 2013 13:00:36 -0700 (PDT)
Received: from exprod6og117.obsmtp.com (exprod6og117.obsmtp.com [64.18.1.39]) by ietfa.amsl.com (Postfix) with ESMTP id 95B6C11E82ED for <ire@ietf.org>; Wed, 16 Oct 2013 13:00:34 -0700 (PDT)
Received: from peregrine.verisign.com ([216.168.239.74]) (using TLSv1) by exprod6ob117.postini.com ([64.18.5.12]) with SMTP ID DSNKUl7wYum5y7J2CRUcvsQftVRQHeNU5p2e@postini.com; Wed, 16 Oct 2013 13:00:36 PDT
Received: from brn1wnexcas02.vcorp.ad.vrsn.com (brn1wnexcas02.vcorp.ad.vrsn.com [10.173.152.206]) by peregrine.verisign.com (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 BRN1WNEXMBX01.vcorp.ad.vrsn.com ([::1]) by brn1wnexcas02.vcorp.ad.vrsn.com ([::1]) with mapi id 14.02.0342.003; Wed, 16 Oct 2013 16:00:32 -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+xHyUWrJn4iQAA
Date: Wed, 16 Oct 2013 20:00:31 +0000
Message-ID: <CE851019.5035D%jgould@verisign.com>
In-Reply-To: <525E8C38.2040002@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: <B4404C9F39180D4DA682C05DE36ABC7A@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: Wed, 16 Oct 2013 20:00:41 -0000

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.  

-- 
 
JG
 

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




On 10/16/13 8:53 PM, "Klaus Malorny" <Klaus.Malorny@knipp.de> 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
>indicates 
>whether name, organization, street, city, state/province, postal and
>country 
>code fields shall be regarded as internationalized or localized. On the
>other 
>hand, these fields may contain their own "isLoc" attribute, indicating
>their 
>designation.
>
>Are these alternatives? I.e. one registry could decide to use the
>fPostalType. 
>In this case, the fields themselves would not use the "isLoc" attribute.
>A row 
>would contain either the internationalized _or_ the localized data set,
>but 
>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
>this 
>case, a row could contain data for the internationalized _or_ localized
>_or_ 
>both data sets.
>
>Is this correct?
>
>Regards,
>
>Klaus
>
>
>[1] http://tools.ietf.org/html/draft-arias-noguchi-dnrd-objects-mapping-05
>_______________________________________________
>ire mailing list
>ire@ietf.org
>https://www.ietf.org/mailman/listinfo/ire