Subject: [provreg] Launch: identifying an application

From: James Mitchell <[email-masked]>
Date: Fri, 5 Apr 2013 21:30:23 +1100

The extension to domain info requires phase and an optional application id. It makes no sense to me why phase is mandatory, and why application id is not mandatory.

A phase that allocates from applications will require the application id field be provided to uniquely identify the application. In this case the phase element provides no value, unless the server generates application identifiers unique to one phase – however both phase and application id are required.

A phase that allocates on FCFS should not require the phase element on info to view the domain (a normal domain info should work). Providing this element makes no sense, other than perhaps signalling to the server that the launch:infData response is requested.

I vote for removing phase from the info command, requiring application id only (registries can allocate application identifiers that are globally unique), and, if necessary, updating the flag for clients to request launch:infData information without the mark, e.g:

<!-- example: during the phase -->
<info xmlns="urn:ietf:params:xml:ns:launch-1.0" include="mark">
  <applicationID>abc123</applicationID>
</info>

<!-- example: view the application post phase (until allocation, or as long as the registry allows info commands on applications if applications are separate to domains) -->
<info xmlns="urn:ietf:params:xml:ns:launch-1.0" include="no-mark">
  <applicationID>abc123</applicationID>
</info>

<!-- example: post allocation, view the launch information used in the allocation of this domain name, if allowed by the server -->
<info xmlns="urn:ietf:params:xml:ns:launch-1.0" include="all" />

<!-- example: post allocation; do not view application information -->
<!-- do not include <info xmlns="urn:ietf:params:xml:ns:launch-1.0" /> element -->

Comments/feedback?

Regards,
James

---

From: "Gould, James" <[email-masked]>
Date: Fri, 5 Apr 2013 15:54:42 +0000

James,

The launches can create either applications or registrations, where registrations may include state transitions.  This means that for the info command, the application id can not be required to support info commands for launch registrations.  The draft includes support for returning the <launch:phase>, <launch:applicationID>, <launch:status>, and <mark:mark>, where <launch:phase>, <launch:status> and <mark:mark> may apply to launch registrations.  The requirement for the <launch:phase> in the info command mirrors the remainder of the commands (create, update, and delete), where it makes the intent explicit from the client.  The <launch:applicationID> is currently not defined as a unique identifier across all phases, where the <launch:phase> would not be needed to uniquely identify the object being queried.  Do you propose defining the <launch:applicatonID> as a unique identifier across all phases, which I believe makes sense?  I believe it is better to leave the <launch:phase> as required, since it is consistent with the remainder of the extended commands, and it explicitly defines the intent of the client (e.g. give me the sunrise registration information for foo.tld).

I provide feedback to your examples below.

Any other thoughts to this?

--

JG

James Gould
Principal Software Engineer
[email-masked]

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

From: James Mitchell <[email-masked]<mailto:[email-masked]>>
Date: Friday, April 5, 2013 6:30 AM
To: EPP Provreg <[email-masked]<mailto:[email-masked]>>
Subject: [provreg] Launch: identifying an application

The draft already includes an "includeMark" attribute that is boolean with a default value of "false" that matches your "include" attribute.  The only other difference is the exclusion of the <phase> that could be implied if the <applicationID> were unique across all phases, but I feel being explicit is better here.

Same feedback to the first example, where the draft "includeMark" attribute matches the use of the "include" attribute.

Since the only element that can optionally be returned based on server policy is the <mark:mark> element, includeMark="true" will match include="all".

Yes, the response will only include the extension if the command included it.

Comments/feedback?

Regards,
James