Re: Launchphase and <check>

Francisco,

I believe what you propose makes sense.  Changing to use the <extension> section instead of the <resData> section does fall in line better with an extension, but does represent an impactful, non-backward compatible change to the draft text.  I would like to hear from the community of the impacts of making this proposed change at this point.  I have a version of the draft created that includes the requested change on GitHub at the URL https://github.com/james-f-gould/EPP-Launch-Phase-Extension-Specification.git for review.  Please let me know publicly or privately if you support or don't support this change.  If this is supported, the hope is that draft 11 is the candidate draft to move forward with; otherwise draft 10 is the candidate draft to move forward with.  Splintering the versions that the servers implement is very undesirable, so please provide your feedback.

Thanks,

--

JG

[cid:C52435F1-F67B-4EC0-8F83-03FB0E79EBE3]

James Gould
Principal Software Engineer
[email protected]

703-948-3271 (Office)
12061 Bluemont Way
Reston, VA 20190
VerisignInc.com

From: Francisco Obispo <[email protected]<mailto:[email protected]>>
Date: Friday, May 10, 2013 1:07 AM
To: EPP Provreg <[email protected]<mailto:[email protected]>>
Subject: [provreg] Launchphase and <check>

We're currently implementing the launchphase extentension.

In my opinion the Claims Check system should use the <extension> section and not the <resData>

The reason for my reasoning has to do with RFC5730 and:

2.9.2.1.  EPP <check> Command


   The EPP <check> command is used to determine if an object can be
   provisioned within a repository.  It provides a hint that allows a
   client to anticipate the success or failure of provisioning an object
   using the <create> command as object-provisioning requirements are
   ultimately a matter of server policy.


Referring to "Objects", however launch-1.0 is an extension, or at least is handled in EPP like one, so my belief is that the response should go into the <extension> section:

   S:<?xml version="1.0" encoding="UTF-8" standalone="no"?>
   S:<epp xmlns="urn:ietf:params:xml:ns:epp-1.0">
   S:  <response>
   S:    <result code="1000">
   S:     <msg>Command completed successfully</msg>
   S:    </result>
   S:    <resData>
   S:     <launch:chkData
   S:      xmlns:launch="urn:ietf:params:xml:ns:launch-1.0">
   S:      <launch:phase>claims</launch:phase>
   S:      <launch:cd>
   S:        <launch:name exists="0">example1.tld</launch:name>
   S:      </launch:cd>
   S:      <launch:cd>
   S:        <launch:name exists="1">example2.tld</launch:name>
   S:        <launch:claimKey>abc123</launch:claimKey>
   S:      </launch:cd>
   S:     </launch:chkData>
   S:    </resData>
   S:    <trID>
   S:     <clTRID>ABC-12345</clTRID>
   S:     <svTRID>54321-XYZ</svTRID>
   S:    </trID>
   S:  </response>
   S:</epp>

SHOULD BE:

   S:<?xml version="1.0" encoding="UTF-8" standalone="no"?>
   S:<epp xmlns="urn:ietf:params:xml:ns:epp-1.0">
   S:  <response>
   S:    <result code="1000">
   S:     <msg>Command completed successfully</msg>
   S:    </result>
   S:    <extension>
   S:     <launch:chkData
   S:      xmlns:launch="urn:ietf:params:xml:ns:launch-1.0">
   S:      <launch:phase>claims</launch:phase>
   S:      <launch:cd>
   S:        <launch:name exists="0">example1.tld</launch:name>
   S:      </launch:cd>
   S:      <launch:cd>
   S:        <launch:name exists="1">example2.tld</launch:name>
   S:        <launch:claimKey>abc123</launch:claimKey>
   S:      </launch:cd>
   S:     </launch:chkData>
   S:    </extension>
   S:    <trID>
   S:     <clTRID>ABC-12345</clTRID>
   S:     <svTRID>54321-XYZ</svTRID>
   S:    </trID>
   S:  </response>
   S:</epp>



The main reasoning behind this, is that some systems (including ours) expect extensions to write on the <extension> section and NOT in the rest of the document.

Having extensions that behave like "objects" could lead to unnecessary processing and confusion.

Does anyone feel the same?


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

_______________________________________________
provreg mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/provreg