Subject: [ire] Extended Verification Process

From: David Kipling <[email-masked]>
Date: Fri, 15 Mar 2013 10:21:08 +0000

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:  [email-masked]<mailto:[email-masked]>
        [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

For more information please visit <a href="http://www.mimecast.com">http://www.mimecast.com<br>
This email message has been delivered safely and archived online by Mimecast.
</a>

---

From: James Mitchell <[email-masked]>
Date: Sun, 17 Mar 2013 01:39:28 +1100

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 <[email-masked]<mailto:[email-masked]>>
Date: Friday, 15 March 2013 9:21 PM
To: "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
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?

“<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

---

From: Francisco Obispo <[email-masked]>
Date: Sat, 16 Mar 2013 10:23:19 -0700

It shouldn't be a problem, because he must've used xmlns declarations in the root, and the parser will simply use that as a reference, internally XML parsers will expand the prefix to '{namespace-uri}attribute' form, so regardless of what the prefix was, as long as the namespace declarations are good, it should all work as expected.

On Mar 16, 2013, at 7:39 AM, James Mitchell <[email-masked]> wrote:

> From: David Kipling <[email-masked]>
> To: "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>
> Website: www.nccgroup.com
> Email:  [email-masked]
> 
> 
> For more information about NCC Group please visit www.nccgroup.com
> 
> _______________________________________________
> ire mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ire

Francisco Obispo 
Director of Applications and Services - ISC
email: [email-masked]
Phone: +1 650 423 1374 || INOC-DBA *3557* NOC
PGP KeyID = B38DB1BE

---

From: James Mitchell <[email-masked]>
Date: Sun, 17 Mar 2013 07:30:10 +1100

I understand how namespaces are used, and how many EPP toolkits and
servers don't use them correctly. I'm sure his example worked, however in
the following example valid deposit I will probably have broken Davids
validation routines; it would work for me because my xpath will be
configured with a namespace resolver that will map "D" to the
rdeDomain-1.0 namespace etc, however Davids may be configured to only map
rdeDomain to the rdeDomain-1.0 namespace.

<?xml version="1.0" ?>
<deposit xmlns="urn:ietf:params:xml:ns:rde-1.0" type="FULL"
 id="20101017001" prevId="20101010001">
 <watermark>2010-10-18T00:00:00Z</watermark>
 <rdeMenu>
  <version>1.0</version>
  <objURI>...</objURI>
 </rdeMenu>
 <contents xmlns:D="urn:ietf:params:xml:ns:rdeDomain-1.0"
  xmlns:d="urn:ietf:params:xml:ns:domain-1.0"
xmlns:p="urn:ietf:params:xml:ns:rdePolicy-1.0">
  <D:domain>
   <D:name>example1.test</D:name>
   <D:roid>Dexample1-TEST</D:roid>
   <D:status s="ok" />
   <D:registrant>jd1234</D:registrant>
   <D:contact type="admin">sh8013</D:contact>
   <D:contact type="tech">sh8013</D:contact>
   <D:ns>
    <d:hostObj>ns1.example.com</d:hostObj>
    <d:hostObj>ns1.example1.test</d:hostObj>
   </D:ns>
   <D:clID>RegistrarX</D:clID>
   <D:crRr client="jdoe">RegistrarX</D:crRr>
   <D:crDate>1999-04-03T22:00:00.0Z</D:crDate>
   <D:exDate>2015-04-03T22:00:00.0Z</D:exDate>
  </D:domain>
  <p:policy scope=²//E:deposit/E:contents/D:domain²
element="D:registrant" />
 </contents>
</deposit>

Using java as an example, I know he could use the SAX
DefaultHandler.startPrefixMapping() method to find the namespace prefixes
bound in the document (I'm not sure how to achieve this in DOM), and use
this information to build a NamespaceContext that can be set on the XPath
instance, however it is not wrong if the xpath expression in the document
uses namespace prefixes not even bound in the document itselff because I
could have configured any prefixes in my xpath evaluator, e.g. the above
example instead with <p:policy
scope=²//LONELINESS:deposit/AND:contents/CHEESEBURGERS:domain²
element="HAHA:registrant" />.

Regards,
James

On 17/03/13 4:23 AM, "Francisco Obispo" <[email-masked]> wrote:

>It shouldn't be a problem, because he must've used xmlns declarations in
>the root, and the parser will simply use that as a reference, internally
>XML parsers will expand the prefix to '{namespace-uri}attribute' form, so
>regardless of what the prefix was, as long as the namespace declarations
>are good, it should all work as expected.
>
>
>
>On Mar 16, 2013, at 7:39 AM, James Mitchell
><[email-masked]> wrote:
>
>> 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
>> 
>> 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 :
>>  
>> 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
>> 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.
>>

---

From: David Kipling <[email-masked]>
Date: Mon, 18 Mar 2013 09:37:22 +0000

I was expecting the namespace declarations to be at the root level so I will investigate if there are any scenarios where this could cause an issue, though as Francisco mentioned as long as the XML document provided is internally consistent and the prefixes in the XPath query use the prefixes defined in the document then there is no problem.  My implementation maps from the document namespaces to the namespace prefixes I use in my validation, therefore as long as the xml document provided is consistent then there would be no issue.  As you mention I have already had to manage the use of rdeDom to my prefix of rdeDomain with no problems.

I am keen though to understand the problem domain more as you mention the use of namespaces with EPP toolkits etc. could be an issue.  The only issue I would have with the example below would be that the XPath query uses prefix "E" which is not defined in the document below.  This would require the original document to be updated to include prefix "E".  Can you think of any other concerns on the proposed update?

Regards

David

-----Original Message-----
From: James Mitchell [mailto:[email-masked]] 
Sent: 16 March 2013 20:30
To: Francisco Obispo
Cc: David Kipling; [email-masked]; [email-masked]
Subject: Re: [ire] Extended Verification Process

I understand how namespaces are used, and how many EPP toolkits and servers don't use them correctly. I'm sure his example worked, however in the following example valid deposit I will probably have broken Davids validation routines; it would work for me because my xpath will be configured with a namespace resolver that will map "D" to the
rdeDomain-1.0 namespace etc, however Davids may be configured to only map rdeDomain to the rdeDomain-1.0 namespace.

<?xml version="1.0" ?>

Using java as an example, I know he could use the SAX
DefaultHandler.startPrefixMapping() method to find the namespace prefixes bound in the document (I'm not sure how to achieve this in DOM), and use this information to build a NamespaceContext that can be set on the XPath instance, however it is not wrong if the xpath expression in the document uses namespace prefixes not even bound in the document itselff because I could have configured any prefixes in my xpath evaluator, e.g. the above example instead with <p:policy scope=²//LONELINESS:deposit/AND:contents/CHEESEBURGERS:domain²
element="HAHA:registrant" />.

Regards,
James

On 17/03/13 4:23 AM, "Francisco Obispo" <[email-masked]> wrote:

>It shouldn't be a problem, because he must've used xmlns declarations 
>in the root, and the parser will simply use that as a reference, 
>internally XML parsers will expand the prefix to 
>'{namespace-uri}attribute' form, so regardless of what the prefix was, 
>as long as the namespace declarations are good, it should all work as expected.
>
>
>
>> 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Š
>> 
>>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 :
>>  
>>policy element is altered to include the scope of the parent element 
>>as an XPath query:
>>  
>>name}" />²  ³<rdePolicy:policy 
>>scope=²//rde:deposit/rde:contents/rdeDomain:domain²
>>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
>> 
>>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.
>> 
>Phone: +1 650 423 1374 || INOC-DBA *3557* NOC PGP KeyID = B38DB1BE
>

---

From: Gustavo Lozano <[email-masked]>
Date: Tue, 26 Mar 2013 18:25:42 -0700

Hi David,

Comments inline.

Regards,
Gustavo

From: David Kipling <[email-masked]<mailto:[email-masked]>>
Date: Friday, March 15, 2013 3:21 AM
To: Gustavo Lozano <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Subject: Extended Verification Process

Hi Gustavo,

What are your thoughts?

This makes a lot of sense. I will discuss with the co authors of the draft, the inclusion of this idea, in the new version of the draft (merge of CSV and XML).

Regards

David Kipling

Regards

David