Subject: Re: [provreg] draft-tan-epp-launchphase-04

From: Bernhard Reutner-Fischer <[email-masked]>
Date: Tue, 11 Dec 2012 11:47:08 +0100

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.

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.

  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"

  s attribute enumeration: Capitalize description phrases

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

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

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

  Also capitalize the phrases in the element enumeration.

- 2.6.  Contact
  Likewise

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

- 2.7.1.  <smd:signedMark> element
  <smd:serial>:  Signature serial number that that can
  too many "that"
  <smd:exDate>:  OPTIONAL date and time that the <smd:signedMark> expires.
  of the ... expiry

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

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

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

  launch:infData enumeration: Capitalize description phrases

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

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

  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.

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

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

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

  domain name with a Application Identifier
  an

  along with an <launch:
  a

  launch:update enumeration: Capitalize description phrases

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

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

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

  This extension does not define any extension to the response of an
  a

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

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

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

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

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

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

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

thanks,
Bernhard
--- draft-tan-epp-launchphase-04.txt.orig	2012-12-04 14:03:39.000000000 +0100
+++ draft-tan-epp-launchphase-04.txt	2012-12-11 11:00:45.451411732 +0100
@@ -250,15 +250,15 @@ Internet-Draft        Launch Phase Mappi
 
    The following status values are defined using the required "s"
    attribute:
-   pending:  the initial state of a newly-created application object.
-   validated:  the application meets relevant registry rules.
-   invalid:  the application does not validate according to registry
+   pending:  The initial state of a newly-created application object.
+   validated:  The application meets relevant registry rules.
+   invalid:  The application does not validate according to registry
       rules.
-   pendingAuction:  the application is pending based on results of an
+   pendingAuction:  The application is pending based on results of an
       auction.
-   allocated:  one of two possible end states of an application object;
+   allocated:  One of two possible end states of an application object;
       the object corresponding to the application has been provisioned.
-   rejected:  the other possible end state; the object was not
+   rejected:  The other possible end state; the object was not
       provisioned.
    custom:  A custom status that is defined using the "name" attribute.
 
@@ -271,7 +271,7 @@ Internet-Draft        Launch Phase Mappi
    For extensibility the <launch:status> element includes an OPTIONAL
    "name" attribute that can define a sub-status or the full name of the
    status when the status value is "custom".  The server SHOULD NOT use
-   of the "custom" status value.
+   the "custom" status value.

@@ -285,9 +285,9 @@ Internet-Draft        Launch Phase Mappi
    can be invalid and rejected.  Additionally certain statuses MAY be
    skipped.  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>
+   if the server does not support an auction.  If a <domain:create>
    processes a request synchronously without the use of an intermediate
-   application, than an Application Identifier (Section 2.1) is not
+   application, then an Application Identifier (Section 2.1) is not
    needed along with the application status.
 
 2.3.1.  State Transition
@@ -449,29 +449,29 @@ Tan, et al.               Expires June 7
 Internet-Draft        Launch Phase Mapping for EPP         December 2012

-   <mark:id>:  an identifier for the mark.  This identifier MUST be
+   <mark:id>:  An identifier for the mark.  This identifier MUST be
       unique among all marks associated with an application object.
    <mark:name>:  The registered trademark text string.  This value is
       free-form text that MAY be mapped to one or more <mark:label>
       values.
-   <mark:label>:  Zero or more domain name labels that corresponds to
+   <mark:label>:  Zero or more domain name labels that correspond to
       the <mark:name>.  Each <mark:label> can match directly to the
       domain name after adding the parent zone.
-   <mark:issuer>:  name of the authority which issued the right
+   <mark:issuer>:  Name of the authority which issued the right
       (trademark clearinghouse, trademark office, company registration
       bureau, etc.)
-   <mark:number>:  the registration number of the right (trademark
+   <mark:number>:  The registration number of the right (trademark
       number, company registration number, etc.)
-   <mark:type>:  indicates the applicant's entitlement to the mark
+   <mark:type>:  Indicates the applicant's entitlement to the mark
       (owner, licensee, etc.)
-   <mark:class>:  zero or more Nice Classification class numbers as
+   <mark:class>:  Zero or more Nice Classification class numbers as
       defined in the Nice List of Classes [2]
-   <mark:entitlement>:  indicates the applicant's entitlement to the
+   <mark:entitlement>:  Indicates the applicant's entitlement to the
       mark (owner, licensee, etc.)
-   <mark:regDate>:  the date of registration / application of the mark
-   <mark:effectiveDate>:  the date the mark becomes effective
-   <mark:exDate>:  the date of expiration of the mark
-   <mark:country>:  indicates the country in which the mark is valid.
+   <mark:regDate>:  The date of registration / application of the mark
+   <mark:effectiveDate>:  The date the mark becomes effective
+   <mark:exDate>:  The date of expiration of the mark
+   <mark:country>:  Indicates the country in which the mark is valid.
       This may be a two-character code from [WIPO.ST3]
    <mark:region>:  indicates the name of a city, state, province or
       other geographic region in which the mark is valid.
@@ -505,21 +505,21 @@ Tan, et al.               Expires June 7
 Internet-Draft        Launch Phase Mapping for EPP         December 2012

-   <mark:name>:  name of the individual or role represented by the
+   <mark:name>:  Name of the individual or role represented by the
        contact.
-   <mark:org>:  name of the organization with which the contact is
+   <mark:org>:  Name of the organization with which the contact is
        affiliated.
-   <mark:addr>:  address information associated with the contact. the
-       <mark:addr> element contains the following child elements:
+   <mark:addr>:  Address information associated with the contact. the
+       <mark:addr> Element contains the following child elements:
 
-       <mark:street>  zero to three <mark:street> elements that contain
+       <mark:street>  Zero to three <mark:street> elements that contain
            the contact's street address.
-       <mark:city>  contact's city
-       <mark:sp>  contact's state or province
-       <mark:cc>  contact's country code
-   <mark:voice>:  contact's voice telephone number
-   <mark:fax>:  contact's facsimile telephone number
-   <mark:email>:  contact's email address
+       <mark:city>  Contact's city
+       <mark:sp>  Contact's state or province
+       <mark:cc>  Contact's country code
+   <mark:voice>:  Contact's voice telephone number
+   <mark:fax>:  Contact's facsimile telephone number
+   <mark:email>:  Contact's email address
 
    All of the child elements are OPTIONAL.  Server policy may place
    additional constraints on the format and requirements of such
@@ -561,10 +561,10 @@ Tan, et al.               Expires June 7
 Internet-Draft        Launch Phase Mapping for EPP         December 2012

-   <smd:serial>:  Signature serial number that that can be compared with
+   <smd:serial>:  Signature serial number that can be compared with
       a revocation list by the server.
-   <smd:exDate>:  OPTIONAL date and time that the <smd:signedMark>
-      expires.  The server MUST NOT accept a <smd:signedMark> that has
+   <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.
    <mark:mark>:  Trademark information as defined in the Mark
@@ -673,7 +673,7 @@ Tan, et al.               Expires June 7
 Internet-Draft        Launch Phase Mapping for EPP         December 2012

-   The following is an example an <smd:encodedSignedMark> element that
+   The following is an example of an <smd:encodedSignedMark> element that
    uses the default "base64" for encoding a <smd:signedMark> element.
 
           <smd:encodedSignedMark
@@ -763,7 +763,7 @@ Internet-Draft        Launch Phase Mappi
    is available the Claims Check Command will return whether or not at
    least one matching trademark exists for the domain name.  If there is
    at least one matching trademark that exists for the domain name a
-   <launch:claimKey> element is returned.  The value of that the
+   <launch:claimKey> element is returned.  The value of that
    <launch:claimKey> element can be used with an info service of a third
    party trademark provider like the Trademark Clearinghouse (TMCH) for
    getting the information needed to generate the trademark claims
@@ -1091,14 +1091,14 @@ Internet-Draft        Launch Phase Mappi
    infData> element along with the regular EPP <resData>.  The <launch:
    infData> contains the following child elements:
 
-   <launch:phase>  the phase during which the application was submitted
+   <launch:phase>  The phase during which the application was submitted
        or is associated with that matches the associated <info> command
        <launch:phase>.
    <launch:applicationID>  OPTIONAL application identifier of the launch
        application.
    <launch:status>  OPTIONAL status of the launch application using one
        of the supported status values (Section 2.3).
-   <mark:mark>  zero or more <mark:mark> elements.  The <mark:mark>
+   <mark:mark>  Zero or more <mark:mark> elements.  The <mark:mark>
        child elements are defined in the <mark:mark> element
        (Section 2.5) section.
 
@@ -1198,7 +1198,7 @@ Internet-Draft        Launch Phase Mappi
    below:
 
    sunrise  The EPP <create> command with the "sunrise" launch phase is
-      used to submit an registration with trademark information that can
+      used to submit a registration with trademark information that can
       be verified by the server with the <domain:name> value.  The
       Sunrise Create Form (Section 3.3.1) is used for the "sunrise"
       launch phase.  Optionally, the server can support multiple
@@ -1244,13 +1244,13 @@ Internet-Draft        Launch Phase Mappi
    <launch:phase>  The launch phase for the create like the "sunrise"
        launch phase.
    <launch:codeMark> or <smd:signedMark> or <smd:encodedSignedMark>
-       <launch:codeMark>  zero or more <launch:codeMark> elements.  The
+       <launch:codeMark>  Zero or more <launch:codeMark> elements.  The
            <launch:codeMark> child elements are defined in the <launch:
            codeMark> element (Section 2.4.1) section.
-       <smd:signedMark>  zero or more <smd:signedMark> elements.  The
+       <smd:signedMark>  Zero or more <smd:signedMark> elements.  The
            <smd:signedMark> child elements are defined in the <smd:
            signedMark> element (Section 2.7.1) section.
-       <smd:encodedSignedMark>  zero or more <smd:encodedSignedMark>
+       <smd:encodedSignedMark>  Zero or more <smd:encodedSignedMark>
            elements.  The <smd:encodedSignedMark> child elements are
            defined in the <smd:encodedSignedMark> element
            (Section 2.7.2) section.
@@ -1683,7 +1683,7 @@ Internet-Draft        Launch Phase Mappi
 
    <launch:phase>  The phase of the application that mirrors the
        <launch:phase> element included in the <launch:create>.
-   <launch:applicationID>  the application identifier of the
+   <launch:applicationID>  The application identifier of the
        application.
 
    An example response when multiple overlapping applications are
@@ -1704,7 +1704,7 @@ Internet-Draft        Launch Phase Mappi
       </domain:creData>
     </resData>
     <extension>
-      <launch:creData xmlns:lp="urn:ietf:params:xml:ns:launchphase-1.0">
+      <launch:creData xmlns:launch="urn:ietf:params:xml:ns:launch-1.0">
         <launch:phase>sunrise</launch:phase>
         <launch:applicationID>2393-9323-E08C-03B1</launch:applicationID>
       </launch:creData>
@@ -1783,7 +1783,7 @@ Internet-Draft        Launch Phase Mappi
      </command>
    </epp>
 
-   This extension does not define any extension to the response of an
+   This extension does not define any extension to the response of a
    <create> domain command for the Claims Create Form.  After processing

@@ -1794,31 +1794,31 @@ Internet-Draft        Launch Phase Mappi

    the command, the server replies with a standard EPP response as
-   defined in the EPP domain mapping.
+   defined in the EPP domain mapping [RFC5731].
 
 3.4.  EPP <update> Command
 
    This extension defines additional elements to extend the EPP <update>
    command to be used in conjunction with the domain name mapping.
 
-   A server that does not support allow multiple applications of a given
-   domain name with a Application Identifier (Section 2.1) during its
+   A server that does not support multiple applications of a given
+   domain name with an Application Identifier (Section 2.1) during its
    launch phase operations MUST return an EPP error result code of 2102.
 
    Registry policies permitting, clients may update an application
-   object by submitting an EPP <update> command along with an <launch:
+   object by submitting an EPP <update> command along with a <launch:
    update> element to indicate the application object to be updated.
    The <launch:update> element contains the following child elements:
 
-   <launch:phase>  the phase during which the application was submitted
+   <launch:phase>  The phase during which the application was submitted
        or is associated with.
-   <launch:applicationID>  the application identifier for which the
+   <launch:applicationID>  The application identifier for which the
        client wishes to update.
 
    This extension does not define any extension to the response of an
    <update> domain command.  After processing the command, the server
    replies with a standard EPP response as defined in the EPP domain
-   mapping.
+   mapping [RFC5731].

@@ -1926,23 +1926,23 @@ Internet-Draft        Launch Phase Mappi
    command to be used in conjunction with the domain name mapping.
 
    A server that does not support multiple applications of a given
-   domain name with a Application Identifier (Section 2.1) during its
+   domain name with an Application Identifier (Section 2.1) during its
    launch phase operations MUST return an EPP error result code of 2102.
 
    Registry policies permitting, clients MAY withdraw an application by
-   submitting an EPP <delete> command along with an <launch:delete>
+   submitting an EPP <delete> command along with a <launch:delete>
    element to indicate the application object to be deleted.  The
    <launch:delete> element contains the following child elements:
 
-   <launch:phase>  the phase during which the application was submitted
+   <launch:phase>  The phase during which the application was submitted
        or is associated with.
-   <launch:applicationID>  the application identifier for which the
+   <launch:applicationID>  The application identifier for which the
        client wishes to delete.
 
-   This extension does not define any extension to the response of an
+   This extension does not define any extension to the response of a
    <delete> domain command.  After processing the command, the server
    replies with a standard EPP response as defined in the EPP domain
-   mapping.
+   mapping [RFC5731].

@@ -2009,6 +2009,7 @@ Internet-Draft        Launch Phase Mappi
 
    This extension does not define any extension to the EPP <transfer>
    command or response described in the EPP domain name mapping
+   [RFC5731].

---

From: "Gould, James" <[email-masked]>
Date: Tue, 11 Dec 2012 15:57:14 +0000

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-masked]
 
703-948-3271 (Office)
12061 Bluemont Way
Reston, VA 20190
VerisignInc.com

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

>  either "make use of" or "use the". I did choose the latter.

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

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

>  Shouldn't that be "that correspond" without the s?

JG - Fixed

>  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

>  Likewise

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

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

>  <smd:serial>:  Signature serial number that that can

JG - Fixed

>  of the ... Expiry

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

>  The following is an example an <smd:encodedSignedMark> element

JG - Fixed

>  The value of that the <launch:claimKey> element can be used

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

>  I would leave out the second example (with the optional applicationID

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

>  A

JG - Fixed

>  resData enumeration: Capitalize description phrases

JG - Fixed

>  Using the former uniformly.

JG - Fixed

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

JG - Fixed

>  missing cross-reference to rfc5731.

JG - Fixed

>  support or allow? Picking the former.

JG - Fixed, removed "allow"

>  An

JG - Fixed

>  A

JG - Fixed

>  launch:update enumeration: Capitalize description phrases

JG - Fixed

>  missing cross-reference to rfc5731.

JG - Fixed

>  An

JG - Fixed

>  A

JG - Fixed

>  A

JG - Fixed

>  missing cross-reference to rfc5731.

JG - Fixed

>  The example reponse has the wrong clTRID, i suspect this is wrong in

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.

>  missing cross-reference to rfc5731.

JG - Fixed

>  Why is idContainerType->applicationID of type token and not

JG - Fixed

>  Is the signedMarkType->id really necessary?

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

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

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

---

From: Wil Tan <[email-masked]>
Date: Wed, 12 Dec 2012 10:50:28 +1100

Bernhard,

Thank you very much for your review. Just a note that we're using
github for collaboration, and James' repository is the most active:

https://github.com/james-f-gould/EPP-Launch-Phase-Extension-Specification

.wil

---

From: Bernhard Reutner-Fischer <[email-masked]>
Date: Thu, 13 Dec 2012 13:00:15 +0100

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

>copied the tmch-tech mail list on this reply as well.
[]
>>- 2.5.  Mark
[]
>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.

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

>that this should not be supported?

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

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

---

From: Bernhard Reutner-Fischer <[email-masked]>
Date: Thu, 13 Dec 2012 13:04:22 +0100

>https://github.com/james-f-gould/EPP-Launch-Phase-Extension-Specification

Thanks, i found your repo just after sending the mail. Pity that
neither of them seem to be up to date. James' does not contain the
spelling fixes yet..

cheers,
Bernhard

---

From: "Gould, James" <[email-masked]>
Date: Thu, 13 Dec 2012 13:27:02 +0000

Bernhard,

I just checked in the updates based on your feedback along with some other
small fixes. 

-- 

JG

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

---

From: Bernhard Reutner-Fischer <[email-masked]>
Date: Thu, 13 Dec 2012 14:51:16 +0100

>>  Using the former uniformly.

I do not see this committed to your repo yet?
Furthermore there is now a surplus closing list tag that prevents
rendering the files..

https://github.com/james-f-gould/EPP-Launch-Phase-Extension-Specification/pull/3

and it would be great if you could update the generated files, too.

thanks in advance and cheers,

---

From: "Gould, James" <[email-masked]>
Date: Thu, 13 Dec 2012 13:54:51 +0000

Bernhard,

My feedback is below.

-- 

JG

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

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

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

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

>   <smd:exDate>:  OPTIONAL date and time of expiration of the

JG - Got it.  I replaced expires with expiry.

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

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

JG - Ok

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

---

From: Bernhard Reutner-Fischer <[email-masked]>
Date: Thu, 13 Dec 2012 16:38:17 +0100

> verify against the TMCH data model, since I really don't want to be

agree

>    interpret and output the XML documents.

"instead employ a proper namespace-aware XML parser" is exactly the problem.
EPP allows me to drive completely without namespace, see quote from
RFC5730 above.

>>I think it should read '-11:59' and not '11:59'

So let's wait for input from TMCH folks..

---

From: Gregory Berezowsky <[email-masked]>
Date: Thu, 13 Dec 2012 11:00:58 -0500

> EPP allows me to drive completely without namespace, see quote from

I think you're misinterpreting that statement (or perhaps I'm misinterpreting your comment). It doesn't say you don't have to deal with namespaces, it just says you don't have to use the prefixes in the RFC.

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