From Klaus.Malorny@knipp.de Tue Oct 1 03:31:58 2013 Return-Path: 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 0A41F21F9D44 for ; Tue, 1 Oct 2013 03:31:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.249 X-Spam-Level: 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 mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FfL6f2GjuO3T for ; Tue, 1 Oct 2013 03:31:52 -0700 (PDT) Received: from kmx10a.knipp.de (clust3c.bbone.knipp.de [195.253.6.130]) by ietfa.amsl.com (Postfix) with ESMTP id 2B2C821F8F9A for ; Tue, 1 Oct 2013 03:31:50 -0700 (PDT) Received: from localhost (localhost.bbone.knipp.de [127.0.0.1]) by kmx10a.knipp.de (Postfix) with ESMTP id C48A649; Tue, 1 Oct 2013 12:31:48 +0200 (MESZ) X-Knipp-VirusScanned: Yes Received: from kmx10a.knipp.de ([127.0.0.1]) by localhost (kmx10a.knipp.de [127.0.0.1]) (amavisd-new, port 10004) with ESMTP id 4DS2rdGLhvrB; Tue, 1 Oct 2013 12:31:43 +0200 (MESZ) Received: from hp9000.do.knipp.de (hp9000.do.knipp.de [195.253.2.54]) by kmx10a.knipp.de (Postfix) with ESMTP id 17A4B48; Tue, 1 Oct 2013 12:31:43 +0200 (MESZ) Received: from [195.253.2.27] (mclane.do.knipp.de [195.253.2.27]) by hp9000.do.knipp.de (@(#)Sendmail version 8.13.3 - Revision 1.000 - 1st August,2006/8.13.3) with ESMTP id r91AVfF8028434; Tue, 1 Oct 2013 12:31:42 +0200 (MESZ) Message-ID: <524AA490.9060808@knipp.de> Date: Tue, 01 Oct 2013 12:31:44 +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: ire@ietf.org Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Subject: [ire] CSV woes X-BeenThere: ire@ietf.org 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: Tue, 01 Oct 2013 10:31:58 -0000 Hi all, unfortunately, I now have to deal with the CSV format and read through the -05 version* of the document (previously, I skipped that CSV parts). I got the following questions: - the separator: a separator different to the default comma separator can be specified by the "sep" attribute. Following the schema definition, it can be any token, including multi-character strings or even an empty string (which makes the file unparsable, of course). I don't think that this is intended - it is left open how to deal with special characters, including, but not limited to, quotes, separators and newlines. I wonder why there is no reference to RFC 4180 - it is unclear to me why the "deletes" entries may have subtables included, e.g. the "csvDomain:deletes" the "domainContacts", as depicted in the example in section 5.1.2 on page 23. Does it mean that in incremental or differential escrows, the CSV format allows the addition and removal of individual multi-value entries? For example, if I have the domain "example.tld", and the technical contact has changed from "abc123" to "def456", the "domainContacts" table in the section would *only* contain the line example.tld,def456,tech (and missing the admin and billing references) and the "domainContacts" table in the section would contain an entry example.tld,abc123,tech This would be a large difference to the XML format, as there the full object is always being replaced, and it would be also quite a hassle and error-prone to generate or read and process this. - I do not understand why in "domainNameServers", hosts are referenced by their ROIDs, whereas in "domainContacts", contacts are referenced by their IDs, especially as this seems to have been changed to the worse. The specification argues with supporting both hostAttr and hostObj models, however, it leaves completely open how the hostAttr model is represented. These are the questions for now, maybe more come later ;-) Regards, Klaus * http://tools.ietf.org/html/draft-arias-noguchi-dnrd-objects-mapping-05 From JGould@verisign.com Tue Oct 1 06:18:23 2013 Return-Path: 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 42A6121E8200 for ; Tue, 1 Oct 2013 06:18:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.745 X-Spam-Level: X-Spam-Status: No, score=-5.745 tagged_above=-999 required=5 tests=[AWL=0.854, 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 9V7k8ifNVb7J for ; Tue, 1 Oct 2013 06:18:18 -0700 (PDT) Received: from exprod6og110.obsmtp.com (exprod6og110.obsmtp.com [64.18.1.25]) by ietfa.amsl.com (Postfix) with ESMTP id 4A23C21E81E2 for ; Tue, 1 Oct 2013 06:18:15 -0700 (PDT) Received: from osprey.verisign.com ([216.168.239.75]) (using TLSv1) by exprod6ob110.postini.com ([64.18.5.12]) with SMTP ID DSNKUkrLlpF6yH/xOfxc7HnbvfWaQAfXeMoA@postini.com; Tue, 01 Oct 2013 06:18:16 PDT Received: from brn1wnexcas02.vcorp.ad.vrsn.com (brn1wnexcas02.vcorp.ad.vrsn.com [10.173.152.206]) by osprey.verisign.com (8.13.6/8.13.4) with ESMTP id r91DIAG6018860 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 1 Oct 2013 09:18:11 -0400 Received: from BRN1WNEXMBX01.vcorp.ad.vrsn.com ([::1]) by brn1wnexcas02.vcorp.ad.vrsn.com ([::1]) with mapi id 14.02.0342.003; Tue, 1 Oct 2013 09:18:09 -0400 From: "Gould, James" To: Klaus Malorny , "ire@ietf.org" Thread-Topic: [ire] CSV woes Thread-Index: AQHOvpF5xwHv3nLgJEqR3DpisfF13pnf1CcA Date: Tue, 1 Oct 2013 13:18:08 +0000 Message-ID: In-Reply-To: <524AA490.9060808@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: <9B7E71E8CA44E34D8B13EF197DA5BBE1@verisign.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [ire] CSV woes X-BeenThere: ire@ietf.org 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: Tue, 01 Oct 2013 13:18:23 -0000 Klaus, I respond to your feedback below. --=20 =20 JG =20 =20 James Gould Principal Software Engineer jgould@verisign.com =20 703-948-3271 (Office) 12061 Bluemont Way Reston, VA 20190 VerisignInc.com On 10/1/13 6:31 AM, "Klaus Malorny" wrote: > > >Hi all, > >unfortunately, I now have to deal with the CSV format and read through >the -05=20 >version* of the document (previously, I skipped that CSV parts). I got >the=20 >following questions: > >- the separator: a separator different to the default comma separator can > be specified by the "sep" attribute. Following the schema definition, > it can be any token, including multi-character strings or even an empty > string (which makes the file unparsable, of course). I don't think that > this is intended Good catch, we can update the schema to support a single character for the separator like below: ... ... Do you have any additional proposals on restrictions? > >- it is left open how to deal with special characters, including, but > not limited to, quotes, separators and newlines. I wonder why there > is no reference to RFC 4180 Additional clarity could be added here. draft-arias-noguchi-dnrd-objects-mapping does not conform to RFC 4180 (e.g. No header and support for UTF-8), but elements of RFC 4180 could be used to provide additional clarity around the handling of quotes, separators, and newlines in the CSV files. > >- it is unclear to me why the "deletes" entries may have subtables >included, > e.g. the "csvDomain:deletes" the "domainContacts", as depicted in > the example in section 5.1.2 on page 23. Does it mean that in >incremental or > differential escrows, the CSV format allows the addition and removal of > individual multi-value entries? For example, if I have the domain > "example.tld", and the technical contact has changed from "abc123" to > "def456", the "domainContacts" table in the > section would *only* contain the line > > example.tld,def456,tech > > (and missing the admin and billing references) and the "domainContacts" > table in the section would contain an entry > > example.tld,abc123,tech > > This would be a large difference to the XML format, as there the full > object is always being replaced, and it would be also quite a hassle >and > error-prone to generate or read and process this. Yes, the CSV model is relational based and not object based, so incremental and differential deposits are done at the record level and not at the object level. The "domainContacts" CSV file, either used under the or elements, represents the link table between the domain and the contact CSV files. With the CSV files, you apply the deltas at the record level as opposed to the object level. That is the fundamental difference between the XML and CSV models in draft-arias-noguchi-dnrd-objects-mapping. > >- I do not understand why in "domainNameServers", hosts are referenced > by their ROIDs, whereas in "domainContacts", contacts are referenced > by their IDs, especially as this seems to have been changed to the > worse. The specification argues with supporting both hostAttr and >hostObj > models, however, it leaves completely open how the hostAttr model > is represented. The hosts are referenced by ROIDs instead of the host name, since use of a natural key (host name), will not work for some host models (hostAttr as well as having a separate set of external hosts per registrar) and will not support host name changes. A host name change should only result in a change to a single record and not all links to that host record. The contact identifier is unique and can't be changed, so it can be used directly without use of a surrogate key via the ROID. > >These are the questions for now, maybe more come later ;-) Thank you for your feedback. > >Regards, > >Klaus > > > >* 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 From Klaus.Malorny@knipp.de Tue Oct 1 07:11:47 2013 Return-Path: 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 C577411E81B9 for ; Tue, 1 Oct 2013 07:11:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.249 X-Spam-Level: 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 mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6lKldUZwBkoe for ; Tue, 1 Oct 2013 07:11:41 -0700 (PDT) Received: from kmx10a.knipp.de (clust3c.bbone.knipp.de [195.253.6.130]) by ietfa.amsl.com (Postfix) with ESMTP id A08AF11E8233 for ; Tue, 1 Oct 2013 07:10:05 -0700 (PDT) Received: from localhost (localhost.bbone.knipp.de [127.0.0.1]) by kmx10a.knipp.de (Postfix) with ESMTP id 151E84C; Tue, 1 Oct 2013 16:10:03 +0200 (MESZ) X-Knipp-VirusScanned: Yes Received: from kmx10a.knipp.de ([127.0.0.1]) by localhost (kmx10a.knipp.de [127.0.0.1]) (amavisd-new, port 10004) with ESMTP id yxSVxEnUJ-Kq; Tue, 1 Oct 2013 16:09:55 +0200 (MESZ) Received: from hp9000.do.knipp.de (hp9000.do.knipp.de [195.253.2.54]) by kmx10a.knipp.de (Postfix) with ESMTP id 292CE49; Tue, 1 Oct 2013 16:09:55 +0200 (MESZ) Received: from [195.253.2.27] (mclane.do.knipp.de [195.253.2.27]) by hp9000.do.knipp.de (@(#)Sendmail version 8.13.3 - Revision 1.000 - 1st August,2006/8.13.3) with ESMTP id r91E9rVv021313; Tue, 1 Oct 2013 16:09:55 +0200 (MESZ) Message-ID: <524AD7B5.10201@knipp.de> Date: Tue, 01 Oct 2013 16:09:57 +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: "ire@ietf.org" References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [ire] CSV woes X-BeenThere: ire@ietf.org 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: Tue, 01 Oct 2013 14:11:48 -0000 On 01.10.2013 15:18, Gould, James wrote: > Klaus, > Hi James, > [...] > > The hosts are referenced by ROIDs instead of the host name, since use of a > natural key (host name), will not work for some host models (hostAttr as > well as having a separate set of external hosts per registrar) and will > not support host name changes. A host name change should only result in a > change to a single record and not all links to that host record. The > contact identifier is unique and can't be changed, so it can be used > directly without use of a surrogate key via the ROID. Yes, that makes sense. Just forgot that host names may change. As talking of hosts, there seems to be a small inconsistency in section 5.2.1.3: it says that the fName field is mandatory in "host", but the example for deleting hosts (page 41) omits it. Regards, Klaus From Klaus.Malorny@knipp.de Fri Oct 4 03:33:34 2013 Return-Path: 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 73DF221F99F0 for ; Fri, 4 Oct 2013 03:33:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.249 X-Spam-Level: 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 mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2NQepeU+scsm for ; Fri, 4 Oct 2013 03:33:23 -0700 (PDT) Received: from kmx10a.knipp.de (clust3c.bbone.knipp.de [195.253.6.130]) by ietfa.amsl.com (Postfix) with ESMTP id B8B4221F99D5 for ; Fri, 4 Oct 2013 03:33:11 -0700 (PDT) Received: from localhost (localhost.bbone.knipp.de [127.0.0.1]) by kmx10a.knipp.de (Postfix) with ESMTP id 18E0251; Fri, 4 Oct 2013 12:33:10 +0200 (MESZ) X-Knipp-VirusScanned: Yes Received: from kmx10a.knipp.de ([127.0.0.1]) by localhost (kmx10a.knipp.de [127.0.0.1]) (amavisd-new, port 10004) with ESMTP id 7lmbu04DmMeZ; Fri, 4 Oct 2013 12:33:04 +0200 (MESZ) Received: from hp9000.do.knipp.de (hp9000.do.knipp.de [195.253.2.54]) by kmx10a.knipp.de (Postfix) with ESMTP id 2E64850; Fri, 4 Oct 2013 12:33:04 +0200 (MESZ) Received: from [195.253.2.27] (mclane.do.knipp.de [195.253.2.27]) by hp9000.do.knipp.de (@(#)Sendmail version 8.13.3 - Revision 1.000 - 1st August,2006/8.13.3) with ESMTP id r94AX3t0027156; Fri, 4 Oct 2013 12:33:04 +0200 (MESZ) Message-ID: <524E9963.5010609@knipp.de> Date: Fri, 04 Oct 2013 12:33:07 +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: ire@ietf.org References: <524AA490.9060808@knipp.de> In-Reply-To: <524AA490.9060808@knipp.de> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [ire] CSV woes: unused namespaces? X-BeenThere: ire@ietf.org 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: Fri, 04 Oct 2013 10:33:34 -0000 Hi, just another discovery: It seems to be that the specification* contains IANA namespace applications in section 11 that are actually not used in any way, namely all those starting with "urn:ietf:params:xml:schema:". I expected the elements defining the fields of the CSV files to use these (as one could regard this as a schema definition), but this is not the case. It would be nice if someone could clarify this. Regards, Klaus * http://tools.ietf.org/html/draft-arias-noguchi-dnrd-objects-mapping-05 From JGould@verisign.com Fri Oct 4 06:39:31 2013 Return-Path: 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 7DE1221F9BCE for ; Fri, 4 Oct 2013 06:39:31 -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 1lhL6rrhmRPc for ; Fri, 4 Oct 2013 06:39:13 -0700 (PDT) Received: from exprod6og110.obsmtp.com (exprod6og110.obsmtp.com [64.18.1.25]) by ietfa.amsl.com (Postfix) with ESMTP id A542F21F9C7D for ; Fri, 4 Oct 2013 06:31:51 -0700 (PDT) Received: from osprey.verisign.com ([216.168.239.75]) (using TLSv1) by exprod6ob110.postini.com ([64.18.5.12]) with SMTP ID DSNKUk7DRkuHaz4Rs6Yi5nxLPmZ+hKY90k7H@postini.com; Fri, 04 Oct 2013 06:31:53 PDT Received: from BRN1WNEXCHM01.vcorp.ad.vrsn.com (brn1wnexchm01.vcorp.ad.vrsn.com [10.173.152.255]) by osprey.verisign.com (8.13.6/8.13.4) with ESMTP id r94DVlnr027898 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 4 Oct 2013 09:31:47 -0400 Received: from BRN1WNEXMBX01.vcorp.ad.vrsn.com ([::1]) by BRN1WNEXCHM01.vcorp.ad.vrsn.com ([::1]) with mapi id 14.02.0342.003; Fri, 4 Oct 2013 09:31:46 -0400 From: "Gould, James" To: Klaus Malorny , "ire@ietf.org" Thread-Topic: [ire] CSV woes: unused namespaces? Thread-Index: AQHOwO1XGLgZhPIBsU+T1uGKiezaLJnkikQA Date: Fri, 4 Oct 2013 13:31:46 +0000 Message-ID: In-Reply-To: <524E9963.5010609@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: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [ire] CSV woes: unused namespaces? X-BeenThere: ire@ietf.org 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: Fri, 04 Oct 2013 13:39:32 -0000 Klaus, Each of the XSD's referenced in the I-D includes a set of IANA URI requests for both urn:ietf:params:xml:ns (e.g. urn:ietf:params:xml:ns:rdeCsv-1.0) and urn:ietf:params:xml:schema (e.g. urn:ietf:params:xml:schema:rdeCsv-1.0). The urn:ietf:params:xml:schema URI's are used to register the schemas and the urn:ietf:params:xml:ns URI's are used within the XML documents that use that schema. The field definitions for the CSV model within the XML manifest file follow the same convention that is used for the XML model, where there is a schema that contains the definitions and a namespace URI that is used within the XML manifest file. In the case of the CSV model, the fields define the format of the CSV files that would be used by a CSV validator. There is a level of indirection with the fields, since they are directly validated using an XML parser in the XML manifest file and they include a type attribute, with a XSD type value, that is validated by a CSV validator in the referenced CSV files. I don't believe there is any substantial difference between the XML and CSV models when it comes to the IANA URI requests. Let me know if I'm missing something from your question. Thanks, --=20 =20 JG =20 =20 James Gould Principal Software Engineer jgould@verisign.com =20 703-948-3271 (Office) 12061 Bluemont Way Reston, VA 20190 VerisignInc.com On 10/4/13 6:33 AM, "Klaus Malorny" wrote: > > >Hi, > >just another discovery: It seems to be that the specification* contains >IANA=20 >namespace applications in section 11 that are actually not used in any >way,=20 >namely all those starting with "urn:ietf:params:xml:schema:". I expected >the=20 >elements defining the fields of the CSV files to use these (as one could >regard=20 >this as a schema definition), but this is not the case. It would be nice >if=20 >someone could clarify this. > >Regards, > >Klaus > > >* 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 From Klaus.Malorny@knipp.de Fri Oct 4 08:30:46 2013 Return-Path: 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 0580421F99F4 for ; Fri, 4 Oct 2013 08:30:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.249 X-Spam-Level: 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 mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uXL-+TBqXBdr for ; Fri, 4 Oct 2013 08:30:33 -0700 (PDT) Received: from kmx10a.knipp.de (clust3c.bbone.knipp.de [195.253.6.130]) by ietfa.amsl.com (Postfix) with ESMTP id F1E8221F9AA7 for ; Fri, 4 Oct 2013 08:30:03 -0700 (PDT) Received: from localhost (localhost.bbone.knipp.de [127.0.0.1]) by kmx10a.knipp.de (Postfix) with ESMTP id 2EFD461; Fri, 4 Oct 2013 17:30:02 +0200 (MESZ) X-Knipp-VirusScanned: Yes Received: from kmx10a.knipp.de ([127.0.0.1]) by localhost (kmx10a.knipp.de [127.0.0.1]) (amavisd-new, port 10004) with ESMTP id L7a2mgRpJdvw; Fri, 4 Oct 2013 17:29:54 +0200 (MESZ) Received: from hp9000.do.knipp.de (hp9000.do.knipp.de [195.253.2.54]) by kmx10a.knipp.de (Postfix) with ESMTP id 3A0FF60; Fri, 4 Oct 2013 17:29:54 +0200 (MESZ) Received: from [195.253.2.27] (mclane.do.knipp.de [195.253.2.27]) by hp9000.do.knipp.de (@(#)Sendmail version 8.13.3 - Revision 1.000 - 1st August,2006/8.13.3) with ESMTP id r94FTrBN000315; Fri, 4 Oct 2013 17:29:53 +0200 (MESZ) Message-ID: <524EDEF5.6060709@knipp.de> Date: Fri, 04 Oct 2013 17:29:57 +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" , "ire@ietf.org" References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [ire] CSV woes: unused namespaces? X-BeenThere: ire@ietf.org 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: Fri, 04 Oct 2013 15:30:46 -0000 On 04.10.2013 15:31, Gould, James wrote: > Klaus, > > Each of the XSD's referenced in the I-D includes a set of IANA URI > requests for both urn:ietf:params:xml:ns (e.g. > urn:ietf:params:xml:ns:rdeCsv-1.0) and urn:ietf:params:xml:schema (e.g. > urn:ietf:params:xml:schema:rdeCsv-1.0). > [...] > > Thanks, > Hi James, thanks. I was not fully aware of the RFC 3866 registration procedures, i.e. that the registered "schema" URIs refer to the actual XML Schema files themselves and are not other namespace URIs. So that makes now sense to me. Regards, Klaus From Klaus.Malorny@knipp.de Wed Oct 16 05:53:18 2013 Return-Path: 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 DCF8E11E81CF for ; Wed, 16 Oct 2013 05:53:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.249 X-Spam-Level: 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 mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fC-SM-SHfGqQ for ; Wed, 16 Oct 2013 05:53:13 -0700 (PDT) Received: from kmx10a.knipp.de (clust3c.bbone.knipp.de [195.253.6.130]) by ietfa.amsl.com (Postfix) with ESMTP id B9F3921F9F08 for ; Wed, 16 Oct 2013 05:53:12 -0700 (PDT) Received: from localhost (localhost.bbone.knipp.de [127.0.0.1]) by kmx10a.knipp.de (Postfix) with ESMTP id CB8B352; Wed, 16 Oct 2013 14:53:11 +0200 (MESZ) X-Knipp-VirusScanned: Yes Received: from kmx10a.knipp.de ([127.0.0.1]) by localhost (kmx10a.knipp.de [127.0.0.1]) (amavisd-new, port 10004) with ESMTP id qsPlzbFqYsUg; Wed, 16 Oct 2013 14:53:06 +0200 (MESZ) Received: from hp9000.do.knipp.de (hp9000.do.knipp.de [195.253.2.54]) by kmx10a.knipp.de (Postfix) with ESMTP id 1578E50; Wed, 16 Oct 2013 14:53:06 +0200 (MESZ) Received: from [195.253.2.27] (mclane.do.knipp.de [195.253.2.27]) by hp9000.do.knipp.de (@(#)Sendmail version 8.13.3 - Revision 1.000 - 1st August,2006/8.13.3) with ESMTP id r9GCr5fg025048; Wed, 16 Oct 2013 14:53:06 +0200 (MESZ) Message-ID: <525E8C38.2040002@knipp.de> Date: Wed, 16 Oct 2013 14:53:12 +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: ire@ietf.org Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Subject: [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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Oct 2013 12:53:19 -0000 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 JGould@verisign.com Wed Oct 16 13:00:41 2013 Return-Path: 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 ; 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 ; 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 ; 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" To: Klaus Malorny , "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: 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: 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-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. =20 --=20 =20 JG =20 =20 James Gould Principal Software Engineer jgould@verisign.com =20 703-948-3271 (Office) 12061 Bluemont Way Reston, VA 20190 VerisignInc.com 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 >indicates=20 >whether name, organization, street, city, state/province, postal and >country=20 >code fields shall be regarded as internationalized or localized. On the >other=20 >hand, these fields may contain their own "isLoc" attribute, indicating >their=20 >designation. > >Are these alternatives? I.e. one registry could decide to use the >fPostalType.=20 >In this case, the fields themselves would not use the "isLoc" attribute. >A row=20 >would contain either the internationalized _or_ the localized data set, >but=20 >never both. So the registry would have to actually use two rows in the >case that=20 >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=20 >case, a row could contain data for the internationalized _or_ localized >_or_=20 >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 From guo050402@126.com Wed Oct 16 20:09:52 2013 Return-Path: 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 F0DAA21F9BEF for ; Wed, 16 Oct 2013 20:09:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 3.754 X-Spam-Level: *** X-Spam-Status: No, score=3.754 tagged_above=-999 required=5 tests=[BAYES_80=2, HTML_MESSAGE=0.001, MIME_BASE64_TEXT=1.753] 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 jJOh5i9Gt-95 for ; Wed, 16 Oct 2013 20:09:35 -0700 (PDT) Received: from m50-111.126.com (m50-111.126.com [123.125.50.111]) by ietfa.amsl.com (Postfix) with ESMTP id B733621F9BD5 for ; Wed, 16 Oct 2013 20:09:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=126.com; s=s110527; h=Received:Date:From:To:Reply-To:Subject:Mime-Version: Message-ID:Content-Type; bh=rV3wCjubjukbUj+xIrhOsVSblotp0ltZO2Qs 7HFwZjo=; b=mHMkbxIy0FsH9DeWAJcCJ2GfffAW9CV17eX46tueztcbNAPRbNwq y560pjd6tK4Fw8sbzjaKLcFvBtqyuCjbvAZMnEpPKpHPPXzqTYqf44gmkdNUbsd0 O3aVmyyqJ2re6+t77SigtVifVtWRO2ewqe2ymZZkM3sz+ncPIA+axAw= Received: from haoxh_t052 (unknown [59.252.170.29]) by smtp5 (Coremail) with SMTP id jtKowEAZZkzlVF9SYv97Cw--.267S2; Thu, 17 Oct 2013 11:09:27 +0800 (CST) Date: Thu, 17 Oct 2013 11:09:12 +0800 From: guo050402 To: ire X-Priority: 3 X-Has-Attach: no X-Mailer: Foxmail 7.0.1.86[cn] Mime-Version: 1.0 Message-ID: <2013101711091114305011@126.com> Content-Type: multipart/alternative; boundary="----=_001_NextPart657672757642_=----" X-CM-TRANSID: jtKowEAZZkzlVF9SYv97Cw--.267S2 X-Coremail-Antispam: 1Uf129KBjDUn29KB7ZKAUJUUUUU529EdanIXcx71UUUUU7v73 VFW2AGmfu7bjvjm3AaLaJ3UbIYCTnIWIevJa73UjIFyTuYvjxU19N3UUUUU X-CM-SenderInfo: xjxrikaquqjqqrswhudrp/1tbi2xe5HUr1Hq+yFAAAsA Subject: [ire] How to submit Deposit to Escrow Agent X-BeenThere: ire@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: guo050402 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 03:09:52 -0000 This is a multi-part message in MIME format. ------=_001_NextPart657672757642_=---- Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: base64 SGksZXZlcnlvbmUhDQpJIHdhbnQgdG8ga25vdyBob3cgdG8gc3VibWl0IERlcG9zaXQgdG8gRXNj cm93IEFnZW50Lg0KQW55Ym9keSBrbm93IHRoYXQ/IFBsZWFzZSBnaXZlIG1lIHNvbWUgaGVscC4N ClRoYW5rcy4NCg0KDQoNCg0KZ3VvMDUwNDAy ------=_001_NextPart657672757642_=---- Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Hi,everyone!
I want to know how to submit Deposit to Es= crow=20 Agent.
Anybody know that? Please give me some hel= p.
Thanks.
 
guo050402
------=_001_NextPart657672757642_=------ From Klaus.Malorny@knipp.de Thu Oct 17 03:43:36 2013 Return-Path: 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 41CF811E8174 for ; Thu, 17 Oct 2013 03:43:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.249 X-Spam-Level: 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 mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xdN7m9r82H8l for ; Thu, 17 Oct 2013 03:43:21 -0700 (PDT) Received: from kmx10a.knipp.de (clust3c.bbone.knipp.de [195.253.6.130]) by ietfa.amsl.com (Postfix) with ESMTP id DB5FF11E8135 for ; Thu, 17 Oct 2013 03:43:18 -0700 (PDT) Received: from localhost (localhost.bbone.knipp.de [127.0.0.1]) by kmx10a.knipp.de (Postfix) with ESMTP id DB65E45; Thu, 17 Oct 2013 12:43:17 +0200 (MESZ) X-Knipp-VirusScanned: Yes Received: from kmx10a.knipp.de ([127.0.0.1]) by localhost (kmx10a.knipp.de [127.0.0.1]) (amavisd-new, port 10004) with ESMTP id uwZklb9H05je; Thu, 17 Oct 2013 12:42:13 +0200 (MESZ) Received: from hp9000.do.knipp.de (hp9000.do.knipp.de [195.253.2.54]) by kmx10a.knipp.de (Postfix) with ESMTP id 72A514F; Thu, 17 Oct 2013 12:42:13 +0200 (MESZ) Received: from [195.253.2.27] (mclane.do.knipp.de [195.253.2.27]) by hp9000.do.knipp.de (@(#)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: <525FBF0B.9010607@knipp.de> 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" , "ire@ietf.org" 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-BeenThere: ire@ietf.org 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): ... contactPostal-YYYYMMDD.csv ... Do you agree? Regards, Klaus From JGould@verisign.com Thu Oct 17 13:52:48 2013 Return-Path: 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 ; 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 ; 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 ; 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" To: Klaus Malorny , "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: 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-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 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? --=20 =20 JG =20 =20 James Gould Principal Software Engineer jgould@verisign.com =20 703-948-3271 (Office) 12061 Bluemont Way Reston, VA 20190 VerisignInc.com On 10/17/13 7:42 PM, "Klaus Malorny" 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.=20 >Maybe I made my point not clear enough. Just as a background information, >I ask=20 >these questions not because we want to generate CSV format, but we need >to read=20 >this (in the context of EBERO). So from my understanding, it would be >valid for=20 >a registry regarding the -05 version of the document to omit the >"fPostalType"=20 >field at all (since it is not "required") and include two sets of fields, >if it=20 >meets its needs, for example, if both versions are mandatory. This could >look=20 >like the following (modified example from the specs): > > > ... > > > > > > > > > > > > > > > > > > > > > > > > cksum=3D"02CC2504"> > contactPostal-YYYYMMDD.csv > > > > ... > > >Do you agree? > >Regards, > >Klaus > From rubensk@nic.br Thu Oct 17 14:01:25 2013 Return-Path: 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 A38F011E8180 for ; Thu, 17 Oct 2013 14:01:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] 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 sCh7JjcBGSu4 for ; Thu, 17 Oct 2013 14:01:25 -0700 (PDT) Received: from mail.nic.br (mail.nic.br [IPv6:2001:12ff:0:4::5]) by ietfa.amsl.com (Postfix) with ESMTP id BABA111E8242 for ; Thu, 17 Oct 2013 14:01:09 -0700 (PDT) Received: from rubens.in.registro.br (3.195.net.registro.br [200.160.3.195]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by mail.nic.br (Postfix) with ESMTPSA id 7F95920801C7 for ; Thu, 17 Oct 2013 18:01:06 -0300 (BRT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Apple Message framework v1283) From: Rubens Kuhl In-Reply-To: <525FBF0B.9010607@knipp.de> Date: Thu, 17 Oct 2013 18:01:06 -0300 Content-Transfer-Encoding: quoted-printable Message-Id: References: <525FBF0B.9010607@knipp.de> To: ire@ietf.org X-Mailer: Apple Mail (2.1283) Subject: Re: [ire] EBERO and host attributes X-BeenThere: ire@ietf.org 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 21:01:25 -0000 >=20 >=20 > 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.=20 Rubens =20 From Klaus.Malorny@knipp.de Fri Oct 18 00:38:43 2013 Return-Path: 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 746B221F9ED1 for ; Fri, 18 Oct 2013 00:38:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.249 X-Spam-Level: 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 mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yEl81ZmeBcMu for ; Fri, 18 Oct 2013 00:38:37 -0700 (PDT) Received: from kmx10a.knipp.de (clust3c.bbone.knipp.de [195.253.6.130]) by ietfa.amsl.com (Postfix) with ESMTP id 2DAE221F9E46 for ; Fri, 18 Oct 2013 00:38:36 -0700 (PDT) Received: from localhost (localhost.bbone.knipp.de [127.0.0.1]) by kmx10a.knipp.de (Postfix) with ESMTP id 1669A4A; Fri, 18 Oct 2013 09:38:36 +0200 (MESZ) X-Knipp-VirusScanned: Yes Received: from kmx10a.knipp.de ([127.0.0.1]) by localhost (kmx10a.knipp.de [127.0.0.1]) (amavisd-new, port 10004) with ESMTP id YY5tTbqP2gmU; Fri, 18 Oct 2013 09:38:28 +0200 (MESZ) Received: from hp9000.do.knipp.de (hp9000.do.knipp.de [195.253.2.54]) by kmx10a.knipp.de (Postfix) with ESMTP id 3FF0549; Fri, 18 Oct 2013 09:38:28 +0200 (MESZ) Received: from [195.253.2.27] (mclane.do.knipp.de [195.253.2.27]) by hp9000.do.knipp.de (@(#)Sendmail version 8.13.3 - Revision 1.000 - 1st August,2006/8.13.3) with ESMTP id r9I7cRDP028180; Fri, 18 Oct 2013 09:38:28 +0200 (MESZ) Message-ID: <5260E57A.9030002@knipp.de> Date: Fri, 18 Oct 2013 09:38:34 +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" , "ire@ietf.org" 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-BeenThere: ire@ietf.org 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: Fri, 18 Oct 2013 07:38:43 -0000 On 17.10.2013 22:52, Gould, James wrote: > Klaus, > > Yes, you are correct. If a registry decided to implement the "int" and > "loc" type of 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? > 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@knipp.de Fri Oct 18 01:09:07 2013 Return-Path: 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 46A3511E810C for ; Fri, 18 Oct 2013 01:09:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.249 X-Spam-Level: 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 mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GczJpTzgHOtW for ; Fri, 18 Oct 2013 01:08:52 -0700 (PDT) Received: from kmx10a.knipp.de (clust3c.bbone.knipp.de [195.253.6.130]) by ietfa.amsl.com (Postfix) with ESMTP id 4206611E8128 for ; Fri, 18 Oct 2013 01:08:47 -0700 (PDT) Received: from localhost (localhost.bbone.knipp.de [127.0.0.1]) by kmx10a.knipp.de (Postfix) with ESMTP id 7DF7D45; Fri, 18 Oct 2013 10:08:46 +0200 (MESZ) X-Knipp-VirusScanned: Yes Received: from kmx10a.knipp.de ([127.0.0.1]) by localhost (kmx10a.knipp.de [127.0.0.1]) (amavisd-new, port 10004) with ESMTP id amO7os3E4Yca; Fri, 18 Oct 2013 10:08:39 +0200 (MESZ) Received: from hp9000.do.knipp.de (hp9000.do.knipp.de [195.253.2.54]) by kmx10a.knipp.de (Postfix) with ESMTP id 02B9144; Fri, 18 Oct 2013 10:08:39 +0200 (MESZ) Received: from [195.253.2.27] (mclane.do.knipp.de [195.253.2.27]) by hp9000.do.knipp.de (@(#)Sendmail version 8.13.3 - Revision 1.000 - 1st August,2006/8.13.3) with ESMTP id r9I88Z6f003193; Fri, 18 Oct 2013 10:08:35 +0200 (MESZ) Message-ID: <5260EC8A.9090202@knipp.de> Date: Fri, 18 Oct 2013 10:08:42 +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: Rubens Kuhl , ire@ietf.org References: <525FBF0B.9010607@knipp.de> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [ire] EBERO and host attributes X-BeenThere: ire@ietf.org 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: Fri, 18 Oct 2013 08:09:07 -0000 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