Subject: [ire] CSV: contactPostal clarification question

From: Klaus Malorny <[email-masked]>
Date: Wed, 16 Oct 2013 14:53:12 +0200

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

---

From: "Gould, James" <[email-masked]>
Date: Wed, 16 Oct 2013 20:00:31 +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
[email-masked]
 
703-948-3271 (Office)
12061 Bluemont Way
Reston, VA 20190
VerisignInc.com

On 10/16/13 8:53 PM, "Klaus Malorny" <[email-masked]> wrote:

>_______________________________________________
>ire mailing list
>[email-masked]
>https://www.ietf.org/mailman/listinfo/ire

---

From: Klaus Malorny <[email-masked]>
Date: Thu, 17 Oct 2013 12:42:19 +0200

> attribute value can be used to define the form in the "registrar" csv

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

---

From: "Gould, James" <[email-masked]>
Date: Thu, 17 Oct 2013 20:52:36 +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
 
703-948-3271 (Office)
12061 Bluemont Way
Reston, VA 20190
VerisignInc.com

---

From: Rubens Kuhl <[email-masked]>
Date: Thu, 17 Oct 2013 18:01:06 -0300

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

Klaus question suggested me another point that I'm curious about: are all EBEROs providing capability for doing emergency failover of registries running host attributes instead of host records ? Although host records are the most usual solution among gTLD registries, not all new gTLD registries will use host records. As a matter of fact I know of at least 5 TLDs running on host attributes, could be more among the 1345 new gTLDs. 

Rubens

---

From: Klaus Malorny <[email-masked]>
Date: Fri, 18 Oct 2013 09:38:34 +0200

Hi James,

please don't ask me -- I would like to immediately scrap the whole CSV part ;-). 
So the proponents of this format should decide. In general, the less options the 
better. However, I can live with the option of having both sets in a single row.

Regards,

Klaus

---

From: Klaus Malorny <[email-masked]>
Date: Fri, 18 Oct 2013 10:08:42 +0200

On 17.10.2013 23:01, Rubens Kuhl wrote:
>>
>
> Klaus question suggested me another point that I'm curious about: are all
> EBEROs providing capability for doing emergency failover of registries
> running host attributes instead of host records ? Although host records are
> the most usual solution among gTLD registries, not all new gTLD registries
> will use host records. As a matter of fact I know of at least 5 TLDs running
> on host attributes, could be more among the 1345 new gTLDs.
>
>
> Rubens
>

Hi Rubens,

I think the two ways of representing hosts are rather exchangeable, so you can 
create host objects on the fly from host attributes and vice versa. In-zone 
hosts are then associated with the same sponsor as the containing domain, 
external hosts are associated with a default sponsor. In our system, we will 
definitely handle it this way in order to limit the changes to our registry 
software.

Regards,

Klaus