Re: [ire] Extended Verification Process

[David Kipling <[e-mail]>]

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:[e-mail]] 
Sent: 16 March 2013 20:30
To: Francisco Obispo
Cc: David Kipling; [e-mail]; [e-mail]
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" ?>
<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" <[e-mail]> 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 
><[e-mail]> 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
>> 
>> From: David Kipling <[e-mail]>
>> Date: Friday, 15 March 2013 9:21 PM
>> To: "[e-mail]" <[e-mail]>, 
>>"[e-mail]" <[e-mail]>
>> 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: [phone]
>> Mobile: 
>> Fax: 
>> Website: www.nccgroup.com
>> Email:  [e-mail]
>> 
>> 
>> 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
>> 
>> P Before you print think about the ENVIRONMENT
>> 
>> 
>> _______________________________________________
>> ire mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/ire
>
>Francisco Obispo
>Director of Applications and Services - ISC
>email: [e-mail]
>Phone: [phone] || INOC-DBA *3557* NOC PGP KeyID = B38DB1BE
>


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>