Re: Launch Phase EPP Extension Version 06
"Gould, James" <[email protected]>
| Newsgroups | gmane.ietf.provreg |
|---|---|
| Message-ID | <C41D7AF7FCECBE44940E9477E8E70D7A24BC0479@BRN1WNEXMBX01.vcorp.ad.vrsn.com> |
Rubens, The Launch Phase draft does support asynchronous operations with support for applications versus registrations. Take a look at section 2.1 Application Identifiers in the draft that defines the Application Identifier and its use. This can be used during any launch phase. Are you looking for something different? Jim ________________________________ From: Rubens Kuhl [[email protected]] Sent: Tuesday, February 26, 2013 9:38 AM To: Gould, James Cc: EPP Provreg ([email protected]) Subject: Re: [provreg] Launch Phase EPP Extension Version 06 James, The main advantage I see in ARI's competing draft for this task is the suitability to registries that operates asynchronously during its normal operations. This happens with a lot of ccTLDs, and most community or restricted new gTLDs could also benefit. Do you see a way to incorporate such mechanisms into your draft ? In this way we could have a general mechanism for domain registrations that cannot be completed based just of name availability: auctions, no-money bids (like who proposes the best use of a generic name on a TLD), registration restrictions that cannot be checked online (membership, taxpayer status) etc. It could even have a new name like draft-tan-epp-asynchronous, but the two drafts model Chris Wright suggest could work better. Rubens Em 26/02/2013, às 11:30:000, Gould, James escreveu: Wil Tan, Gavin Brown and I have updated the Launch Phase EPP Extension Mapping to Version 06. The IETF Internet-Draft Submission page is suspended until 2013-03-11, so the draft is attached in TXT and HTML format. We will post the draft once the IETF Internet-Draft Submission page opens. This version includes the following changes: 1. Removed the definition of the mark-1.0 and signedMark-1.0 and replaced with reference to draft-lozano-smd, that contains the definition for the mark, signed marked, and encoded signed mark. 2. Split the <launch:timestamp> into <launch:generatedDate> and <launch:acceptedDate> based on feedback from Trung Tran. 3. Added the "includeMark" optional attribute to the <launch:info> element to enable the client to request whether or not to include the mark in the info response. 4. Fixed state diagram to remove redundant transition from "invalid" to "rejected"; thanks Klaus Malorny. Please reply with any feedback. Thanks, JG James Gould Verisign <draft-tan-epp-launchphase.txt><draft-tan-epp-launchphase.html>_______________________________________________ provreg mailing list [email protected]<mailto:[email protected]> https://www.ietf.org/mailman/listinfo/provreg _______________________________________________ provreg mailing list [email protected] https://www.ietf.org/mailman/listinfo/provreg