Re: draft-tan-epp-launchphase-04

On Tue, Dec 11, 2012 at 03:57:14PM +0000, Gould, James wrote:
>Bernhard,
>
>Thank you for your detailed review.  I provide feedback below prefixed

I just note that i do not consider my terse notes as a real review.
Unfortunately i do not have time to look closely anytime soon, it seems.

>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.5.  Mark
[]
>>  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?

I would have assumed that it can be specified 'Zero or more' times, or
at least multiple times, yes.

>>- 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.

I see. The 5730 contains this note about namespaces which i find more
clear (since it explicitly states that one can omit namespaces
completely):
The XML namespace prefixes used in examples (such as the
string "foo" in "xmlns:foo") are solely for illustrative purposes.  A
conforming implementation MUST NOT require the use of these or any
other specific namespace prefixes.

>>- 2.7.1.  <smd:signedMark> element

>>  <smd:exDate>:  OPTIONAL date and time that the <smd:signedMark> expires.
>>  of the ... Expiry
>
>JG - Not clear on this one.  Can you clarify?

2.5 Mark uses
   <mark:exDate>:  The date of expiration of the mark
so i would rephrase the signedMark.exDate to
   <smd:exDate>:  OPTIONAL date and time of the <smd:signedMark>
      expiry.  The server MUST NOT accept a <smd:signedMark> that has
      expired.  No <smd:exDate> element indicates that there is no
      expiry.
(like in the diff i attached in the original mail)
or, in the light of the mark:exDate description:
   <smd:exDate>:  OPTIONAL date and time of expiration of the
      <smd:signedMark>.

>>- 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

There are two examples for the info command extension:
The first contains the OPTIONAL applicationID, the second one does not
but is identical otherwise (so is pretty redundant IMO).
Furthermore you only show the response for the former command, i.e. the
command with the applicationID, and not for the latter which, i think,
would be identical except that it would not contain the applicationID.

I just find this a little bit inconsistent and thus would remove that
second example. No strong opinion on that one, though.

>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?

No, i guess that's fine. I was just refering to the examples.

>>- 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.

ok. Still, it would be a bad choice to use a data-type that is imprecise
for IMHO no real gain.

hmz. Great, there seems to be a minus missing in the note for
3.2.9.1 Lexical representation in
http://www.w3.org/TR/xmlschema-2/#date-lexical-representation
I think it should read '-11:59' and not '11:59'
but anyway..
>
>>
>>  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.

I can see your attempt. Perhaps you could mention that these data-types
are mirroring the contact data-types due to the reasons you mention
above and that eventual deviation from contact is not intentional. This
would make our implementation easier, at least.

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