Re: [tmch-tech] Extensibility of status values et al., was: Launch Phase EPP Extension Version 04 Posted

Klaus,

Thanks for your initial preliminary review.  My feedback is below.  I
highly recommend that you review the draft in full, since some of the
questions like the use of phases is addressed throughout the draft.  I've
copied the provreg list on this reply to get additional feedback from
those participants.

-- 

JG
 

 
James Gould
Principal Software Engineer
[email protected]
 
703-948-3271 (Office)
12061 Bluemont Way
Reston, VA 20190
VerisignInc.com







On 12/11/12 6:37 AM, "Klaus Malorny" <[email protected]> wrote:

>On 04/12/12 14:56, Gould, James wrote:
>> Wil Tan, Gavin Brown and I have updated the Launch Phase EPP Extension
>> Mapping to support the current state of the ICANN TMCH Sunrise and
>>Claims
>> implementation model.  You can find the draft at the URL
>> http://tools.ietf.org/html/draft-tan-epp-launchphase-04.
> > [...]
>
>Hi,
>
>while I do not plan to review the draft in-depth before ICANN publishes
>its 
>updated functional specification, I had a look on it today regarding the
>status 
>values and discovered the custom/@name extensibility. While it was
>already added 
>to the -03 version, I wonder whether this is really the best approach to
>add 
>extensible status values, esp. as this could be seen as a blue print for
>other 
>future extensions and EPP itself, as standard EPP misses this desirable
>feature 
>at all. First, allowing the addition of a "name" to standard status
>values 
>(pending, validated, ...) breaks the previous characteristic of status
>values 
>that they are only binary (i.e. set or not). Second, the "custom" value
>creates 
>an asymmetry between standard and non-standard status values, as the
>"name" 
>attribute is suddenly the primary discriminator in the "custom" case and
>not a 
>subdiscriminator as in the other cases.

JG - Addition of the "name" attribute does not break the concept of the
binary characteristic of a status.  The "name" attribute represents a
sub-status when using a non-"custom" enumerated status value, which still
maintains the binary characteristic (i.e. set or not).  In the case of the
sub-status, the client is not required to key off of the sub-status "name"
value if they choose to, but can strictly key off of the parent enumerated
status.  The sub-status could provide more clarity to the client if a
higher level status does have more fine grained states.  You are correct
when using the "custom" enumerated status value, the "name" attribute
becomes the true custom name of the status.


>
>IMHO, it would be better to
>   - get rid of the @name attribute

This would be mean that the enumerated list in the draft is final, with no
built in form of extensibility.

>   - allow other status value names as well, either allowing any token,
>     a token with a prefix ("x-") or even Qnames

JG - The use of "any" might be too heavyweight for what we need here.  I'm
not sure if there is the need to define additional XSD's for the handling
of custom server statuses.  I don't know of the case where a server will
want to create their own custom status, but defining a new XSD that the
client has to deal with can quickly get out of hand.  Do you have an
example of what you mean by using the prefix or Qnames to handle say two
custom statuses like "foo" and "bar".  The current draft would represent
the "foo" and "bar" statuses as <launch:status s="custom" name="foo"/> and
<launch:status s="custom" name="bar"/>, respectively.  In this case there
is no added complexity for the server or the client, and the client can
decide what to display for the status.  I would most likely display the
name attribute ("foo" or "bar") as the status and not drive any
client-side logic based on the use of the custom status unless I choose
to.  

>   - allow more than one status value in the info response


JG - The statuses are discrete steps in the state machine of an
application, meaning that there is only one state per application at a
time.  Maybe it would be better to call them states instead of statuses?


>
>If the current way of implementing states is retained, it is questionable
>whether a "pendingAuction" state is really required. Wouldn't it be a
>special 
>case of the "validated" status and thus should be identified via the
>"name" 
>attribute? Does ICANN require an auction in case of application
>conflicts, so 
>that it is necessary to include this state? This does not mean that I
>mind the 
>information that an application is part of an auction, but is it the
>right way 
>to express this?

JG - Yes, the "pendingAuction" status could be reflected as a "validated"
sub-status, but there is nothing wrong with including a possible known
status that an application may have.  This does not mean that it is a
required status, but that it is a possible status.  The "pendingAuction"
status was added based on feedback from Trung Tran on the provreg list.

>
>My criticism of the status values applies similarly to the phase names.
>Why 
>isn't it simply a token? I can't see that any semantics is enforced by
>the EPP 
>extension (although the registry may do so) on the use of the predefined
>phases, 
>e.g. if the phase is "sunrise", then this or that data has to be supplied.

JG - The phases in the draft define interface dependencies, where for
"sunrise" phase there is the use of the Sunrise Create Form by the passing
of the trademark information and for the "claims1" and "claims2" phases,
there is the use of the Claims Create Form that passes the required claims
notice information on create.  There is an additional dependency on the
phase value for the use of the Claims Check Command, since the Claims
Check Command is only applicable during the "claims1" and "claims2"
phases.  Having the phase name be freeform will not provide any form of a
interface contract between the client and the server.  How would the
client know what phase to pass and what should be passed along with it?
How would the server know what the intention of the client is?  For
example, the set of domain names used for a Claims Check Command is
different for the "claims1" and "claims2" phases.  The claims notice
claims notice presented to the Registrant is also different between the
"claims1" and "claims2" phases, so the server would want to ensure that it
is responding correctly based on what is explicitly being requested by the
client.  Having a predefined set of phases with expected extension
requirements (protocol interface) I believe will make the contract
stronger and cleaner between the client and the server.  Some servers
might decide to create custom phases, and in doing so will need to
communicate their interface requirements out-of-band to the clients.
Sub-phases could meet the same basic interface requirements of the parent
phase similar to the discussion above on the use of sub-statuses.


>
>Just my two cents,
>
>Klaus
>

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