Re: Launchphase and <check>

Thanks for taking this into consideration.

I believe this is the right thing to do, and now is the right time to fix it.

Francisco


On May 14, 2013, at 9:43 AM, "Gould, James" <[email protected]> wrote:

> 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
>  
> <8A7A655D-9ED0-4D38-898D-E9E8B754666E[3].png>
>  
> James Gould
> Principal Software Engineer
> [email protected]
>  
> 703-948-3271 (Office)
> 12061 Bluemont Way
> Reston, VA 20190
> VerisignInc.com
> 
> From: Francisco Obispo <[email protected]>
> Date: Friday, May 10, 2013 1:07 AM
> To: EPP Provreg <[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]
>> Phone: +1 650 423 1374 || INOC-DBA *3557* NOC
>> PGP KeyID = B38DB1BE
>> 
> _______________________________________________
> provreg mailing list
> [email protected]
> https://www.ietf.org/mailman/listinfo/provreg

Francisco Obispo 
Director of Applications and Services - ISC
email: [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