Re: [ire] Extended Verification Process

James Mitchell <james.mitchell@ausregistry.com.au> Sat, 16 March 2013 14:39 UTC

Return-Path: <james.mitchell@ausregistry.com.au>
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 656DE21F89A5 for <ire@ietfa.amsl.com>; Sat, 16 Mar 2013 07:39:42 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.895
X-Spam-Level:
X-Spam-Status: No, score=-1.895 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HELO_EQ_AU=0.377, HOST_EQ_AU=0.327, HTML_MESSAGE=0.001]
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 VFfF6iRZOXnY for <ire@ietfa.amsl.com>; Sat, 16 Mar 2013 07:39:41 -0700 (PDT)
Received: from mx02.ausregistry.net.au (mx02.ausregistry.net.au [202.65.15.42]) by ietfa.amsl.com (Postfix) with ESMTP id 1F87E21F899E for <ire@ietf.org>; Sat, 16 Mar 2013 07:39:36 -0700 (PDT)
Received: from off-win2003-01.stkildard.vic.ausregistry.com.au (HELO off-win2003-01.ausregistrygroup.local) ([10.30.1.3]) by iron02.off08.stkildard.vic.ausregistry.com.au with ESMTP; 17 Mar 2013 01:39:34 +1100
Received: from off-win2003-01.ausregistrygroup.local ([10.30.1.3]) by off-win2003-01.ausregistrygroup.local ([10.30.1.3]) with mapi; Sun, 17 Mar 2013 01:39:24 +1100
From: James Mitchell <james.mitchell@ausregistry.com.au>
To: David Kipling <David.Kipling@nccgroup.com>, "gustavo.lozano@icann.org" <gustavo.lozano@icann.org>, "ire@ietf.org" <ire@ietf.org>
Date: Sun, 17 Mar 2013 01:39:28 +1100
Thread-Topic: [ire] Extended Verification Process
Thread-Index: Ac4iVA1gD8CXTJayR7C/G9qJy/tpXQ==
Message-ID: <CD6ABFF5.654F1%james.mitchell@ausregistry.com.au>
In-Reply-To: <31655AEAB7ACEE41A2D1321E18D4BF3261D4A0DF@manexchprd01>
Accept-Language: en-US, en-AU
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
user-agent: Microsoft-MacOutlook/14.3.1.130117
acceptlanguage: en-US, en-AU
x-kse-antivirus-interceptor-info: scan successful
x-kse-antivirus-info: Clean
Content-Type: multipart/alternative; boundary="_000_CD6ABFF5654F1jamesmitchellausregistrycomau_"
MIME-Version: 1.0
Subject: Re: [ire] Extended Verification Process
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: Sat, 16 Mar 2013 14:39:42 -0000

Worried.

Are we going to assume that every validator has to map the prefixes rde and rdeDomain to "urn:ietf:params:xml:ns:rde-1.0" and "urn:ietf:params:xml:ns:rdeDomain-1.0" respectively? What happens when I use namespace prefixes other than those used in the examples (e.g. bind rde to default and rdeDomain to "d")? I assume that I would not change the Xpath query because I would guess that I would break validator implementations…

I note also the inconsistent use of namespace prefixes for the RDE Domain namespace, with the document referring to both rdeDom and rdeDomain.

Regards,
James

From: David Kipling <David.Kipling@nccgroup.com<mailto:David.Kipling@nccgroup.com>>
Date: Friday, 15 March 2013 9:21 PM
To: "gustavo.lozano@icann.org<mailto:gustavo.lozano@icann.org>" <gustavo.lozano@icann.org<mailto:gustavo.lozano@icann.org>>, "ire@ietf.org<mailto:ire@ietf.org>" <ire@ietf.org<mailto:ire@ietf.org>>
Subject: [ire] Extended Verification Process

Hi Gustavo,

At NCC Group we are working on the extended verification process and have noted a query around the RDE policy rule.  The element allows you to specify required fields such as “<rdePolicy:policy element="rdeDom:registrant" />” as required.  The issue I have with this is that the scope of the element needs to be known to be able to perform the check e.g. is it :



·        one registrant per deposit?

·        one registrant per domain record?

·        one registrant per postalInfo element in each contact record?


You have the namespace, though I would suggest to be clear that the policy element is altered to include the scope of the parent element as an XPath query:

“<rdePolicy:policy scope=”{XPath query}” element="{qualified element name}" />”
“<rdePolicy:policy scope=”//rde:deposit/rde:contents/rdeDomain:domain” element="rdeDomain:registrant" />”


What are your thoughts?

Regards

David Kipling













1.      I have some really easy XPath queries etc. setup to handle the extended validation though my issue is with the CSV files.  Looks like I’m going to have to build a module to load all the csv elements into the same XML file for me to process.  It’s a shame it isn’t just XML as the process would be a lot easier including the Open Source Tool.

Regards

David
________________________________
David Kipling
IT Service Desk Analyst
NCC Group
Manchester Technology Centre, Oxford Road
Manchester, M1 7EF

Telephone: +44 161 209 5430
Mobile:
Fax:
Website: www.nccgroup.com<http://www.nccgroup.com>
Email:  David.Kipling@nccgroup.com<mailto:David.Kipling@nccgroup.com>
        [http://www.nccgroup.com/media/192418/nccgrouplogo.jpg] <http://www.nccgroup.com/>
________________________________

This email is sent for and on behalf of NCC Group. NCC Group is the trading name of NCC Services Limited (Registered in England CRN: 2802141). Registered Office: Manchester Technology Centre, Oxford Road, Manchester, M1 7EF. The ultimate holding company is NCC Group plc (Registered in England CRN: 4627044).

Confidentiality: This e-mail contains proprietary information, some or all of which may be confidential and/or legally privileged. It is for the intended recipient only. If an addressing or transmission error has misdirected this e-mail, please notify the author by replying to this e-mail and then delete the original. If you are not the intended recipient you may not use, disclose, distribute, copy, print or rely on any information contained in this e-mail. You must not inform any other person other than NCC Group or the sender of its existence.

For more information about NCC Group please visit www.nccgroup.com<http://www.nccgroup.com>

P Before you print think about the ENVIRONMENT