Re: draft-tan-epp-launchphase-04

Bernhard,

My feedback is below.

-- 

JG
 

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







On 12/13/12 7:00 AM, "Bernhard Reutner-Fischer" <[email protected]>
wrote:

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

JG - Well if that wasn't a real review, I look forward to the real review.

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

JG - That is a real good question.  I really would like the IBM and or
Deloitte representatives to review the mark elements at a minimum to
verify against the TMCH data model, since I really don't want to be
guessing on this.  

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

JG - Do you believe that the text in section 1.1 "Conventions Used in This
Document" does not correct reflect the intent?  I include a snippet for
the use of the "smd" prefix below:

"urn:ietf:params:xml:ns:signedMark-1.0".  The XML namespace prefix
   "smd" is used, but implementations MUST NOT depend on it and instead
   employ a proper namespace-aware XML parser and serializer to
   interpret and output the XML documents.




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

JG - Got it.  I replaced expires with expiry.

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

JG - Yes, I agree that it identical except for the reference to the
applicationID.  I wanted to be clear that the info command could be used
for a launch registration as well as for a launch application.  I'll leave
for now and if more folks feel that it is redundant and not needed I'll
remove it.

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

JG - Ok

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

JG - I updated the sentence in section 2.6 "Contact" to read "Some of the
contact elements defined in EPP contact mapping RFC5733 are replicated for
the mark contact so there is no dependency to the EPP contact mapping
RFC5733 XML schema from the Mark XML schema."

>
>thanks,

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