Re: [ire] Extended Verification Process

[James Mitchell <[e-mail]>]

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
>