Re: draft-tan-epp-launchphase-04

Bernhard,

Thank you for your detailed review.  I provide feedback below prefixed
with "JG-".  The updates will be in the future 05 draft.  From a high
level, the mark-1.0.xsd elements need a review by IBM and Deloitte in
matching with the TMCH data model.  Can someone from IBM and or Deloitte
review the elements and provide feedback on the full list of elements
names and element types in mark-1.0.xsd
(http://tools.ietf.org/html/draft-tan-epp-launchphase-04#page-45)? I've
copied the tmch-tech mail list on this reply as well.

-- 

JG
 

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







On 12/11/12 5:47 AM, "Bernhard Reutner-Fischer" <[email protected]>
wrote:

>Hi,
>
>I am attaching a diff against draft-tan-epp-launchphase-04 from skimming
>over the draft (against the .txt, i did not find TeX source or the
>like).
>
>I am with James Gould that using dateTime feels more comfortable than
>plain date since EPP generally uses the former.
>
>Since in EPP the XML frames are entitled "commands" rather than frames,
>i suggest to change all "Frame" occurances to "Command" in the section
>headers (e.g. "Claims Create Form" -> "Claims Create Command") as well
>as in the document body. I can provide a follow-up patch unless you
>prefer to change that yourself.

JG - My only concern with changing the "Form" references to "Command" is
that we're really not defined a new command / verb but we just extending
the domain create with a different kind of extension dependent on the
phase.  Do others feel that the term "Form" should be changed to "Command"
or something else for "Sunrise Create Form" and "Claims Create Form"?


>
>Changes
>- 2.3.  Status Values:
>  The server SHOULD NOT use of the "custom" status value.
>  either "make use of" or "use the". I did choose the latter.

JG - Changed to "The server SHOULD NOT use the "custom" status value."

>
>  For example, an application MAY immediately start at the
>  allocated status or an application MAY skip the pendingAuction status
>  if server does not support an auction.  If a <domain:create>
>  missing "the" in "if server"

JG - Fixed

>
>  s attribute enumeration: Capitalize description phrases

JG - I believe this comment was to capitalize the description sentences of
the phrases.  If so it is fixed.

>
>- 2.5.  Mark
>  <mark:label>:  Zero or more domain name labels that corresponds to
>  Shouldn't that be "that correspond" without the s?

JG - Fixed

>
>  What is the difference between <mark:type> and <mark:entitlement>? The
>  description looks like it was just copy'n pasted?

JG - I recently notice this and yes it was a copy/paste issue.  The 02
draft had the "type" defined as "Indicates the type of claim being made
(trademark,
      symbol, combined mark, company name, etc.)".  This has been fixed.

>
>  I take it that <mark:country> can be specified Zero or more times?

JG - No, currently it is a single country.  Should this be a list?

>
>  Also capitalize the phrases in the element enumeration.

JG - Fixed

>
>- 2.6.  Contact
>  Likewise

JG - I assume this is related to the capitalization of the descriptions,
which has been fixed.

>
>What is the rationale behind using "smd" for the namespace of "Signed
>Mark"
>and not the more intuitive "sm" (especially since using a
>namespace-prefix is recommended anyway)?

JG - The term SMD, Signed Mark Data, has been discussed in the Community
Model, which is why it was chosen as the sample namespace prefix.  Any
prefix can be used, so this is provided simply as an example.


>
>- 2.7.1.  <smd:signedMark> element
>  <smd:serial>:  Signature serial number that that can
>  too many "that"

JG - Fixed

>  <smd:exDate>:  OPTIONAL date and time that the <smd:signedMark> expires.
>  of the ... Expiry

JG - Not clear on this one.  Can you clarify?

>
>- 2.7.2.  <smd:encodedSignedMark> element
>  The following is an example an <smd:encodedSignedMark> element
>  missing "of"

JG - Fixed

>
>- 3.1.  EPP <check> Command
>  The value of that the <launch:claimKey> element can be used
>  surplus "the"

JG - I removed the "that", so it reads "The value of the <launch:claimKey>
element can be usedŠ".

>
>- 3.2.  EPP <info> Command
>  I would leave out the second example (with the optional applicationID
>  omitted).

JG - Why since an info command could be submitted for a registration made
during sunrise in a first-come-first-server sunrise that may return back
the trademark information passed with the registration?  Do you believe
that this should not be supported?

>
>  launch:infData enumeration: Capitalize description phrases

JG - Fixed

>
>- 3.3.  EPP <create> Command
>  sunrise  The EPP <create> command ... is used to submit an registration
>  A

JG - Fixed

>
>- 3.3.1.  Sunrise Create Form
>  launch:create enumeration: Capitalize description phrases
>  resData enumeration: Capitalize description phrases

JG - Fixed

>
>  There is a mixture of
>  "xmlns:launch="urn:ietf:params:xml:ns:launch-1.0"
>  and
>  <launch:creData xmlns:lp="urn:ietf:params:xml:ns:launchphase-1.0">
>  in the last example.
>  Using the former uniformly.

JG - Fixed

>
>- 3.3.2.  Claims Create Form
>  This extension does not define any extension to the response of an
>  typo: s/an/a/

JG - Fixed

>
>  defined in the EPP domain mapping.
>  missing cross-reference to rfc5731.

JG - Fixed


>
>- 3.4.  EPP <update> Command
>  A server that does not support allow multiple applications
>  support or allow? Picking the former.

JG - Fixed, removed "allow"

>
>  domain name with a Application Identifier
>  An

JG - Fixed

>
>  along with an <launch:
>  A

JG - Fixed

>
>  launch:update enumeration: Capitalize description phrases

JG - Fixed

>
>  as defined in the EPP domain mapping
>  missing cross-reference to rfc5731.


JG - Fixed

>
>- 3.5.  EPP <delete> Command
>  domain name with a Application Identifier
>  An

JG - Fixed

>
>  submitting an EPP <delete> command along with an <launch:delete>
>  A

JG - Fixed

>
>  This extension does not define any extension to the response of an
>  A

JG - Fixed

>
>  as defined in the EPP domain mapping
>  missing cross-reference to rfc5731.

JG - Fixed

>
>  The example reponse has the wrong clTRID, i suspect this is wrong in
>  other places, too.

JG - Fixed, changed all clTRID to "ABC-12345" and all svTRID to
"54321-XYZ" so all of the TRID
Values should be consistent across the draft.

>
>- 3.7.  EPP <transfer> Command
>  as defined in the EPP domain mapping
>  missing cross-reference to rfc5731.

JG - Fixed

>
>- 4.1.  Launch Schema
>  Why is idContainerType->applicationID of type token and not
>  applicationIDType ?

JG - Fixed

>
>- 4.2.  Signed Mark Schema
>  Is the signedMarkType->id really necessary?

JG - Yes it is.  The Signature will refer to the signedMark via the IDREF.

>
>- 4.3.  Mark Schema
>  type="date"
>  as mentioned above it would be nice to have those as dateTime

JG - I agree that the dates should include the time element, but I want to
ensure that the data types match what is stored in the TMCH.  This is
really dependent on the true definition of the trademark attributes.  I'm
going to include a higher level comment at the top related to IBM and
Deloitte to help define the mark attributes along with the appropriate
types.  I'll hold off changing the date types to dateTime right now.

>
>  mark:ccType could be just a ref contact:ccType
>  Same for pcType, addrType, email and the phone numbers and extensions.

JG - We did not want to create a schema dependency of mark-1.0.xsd to
contact-1.0.xsd or any other EPP XSD, so the data types are redefined
instead of referenced from an external XSD.

>
>thanks,
>Bernhard

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