Subject: Re: [provreg] Launch Phase EPP Extension Version 08

From: Rubens Kuhl <[email-masked]>
Date: Mon, 1 Apr 2013 21:31:17 -0300

James,

We would prefer something which resembles option 2 in allowing the client to be explicit about the phase, in a optional manner, but prefer that server behavior would also be optional. The server could fail the command based on registry policy, but it would not be obligated to. So both the parameter and the behavior would be optional. 

Rubens

Em 28/03/2013, às 17:20:000, Gould, James escreveu:

> Seth,
> 
> I believe that the server will support only an application or a registration, but not both,  during a particular phase.  The creation of an application by the server will be indicated by the return of the 1001 result code and the creation of a registration by the server will be indicated by the return of a 1000 result code.  This is the same behavior when dealing with registries that do or don't support the pendingCreate in RFC 5731.  With support of the launch extension, the create response will return the launch extension with the application identifier for an application as well.  The question is whether the client should or be required to explicitly pass the launch extension with the applicable launch phase when the mark or notice is not needed.  If so, should the client also explicitly specify whether the intent is to create an application or a registration.  If the active phase of the server does not support the intent of the client (phase and application/registration) the server should fail the command.  As defined now, the client can not pass the launch extension  when the mark or notice is not required on create, and the server will create the appropriate object (application or registration) based on the active phase.    
> 
> Should we do the following:
> Leave the draft, where the client only passes the extension when the mark or notice information is needed.  The server will create the appropriate object (application or registration) based on the active phase and return the appropriate result code (1001 or 1000) and optionally with the launch phase extension.  
> Update the draft to support the option for the client to explicitly define the intended phase and optionally the intended object type (application or registration) in the extension to create.  The server will fail the command if the specified phase does not match and the specified object type does not match.  
> Update the draft to require the client to explicitly define the intended phase and intended object type (application or registration) in the extension to create.  The server will fail the command if the specified phase does not match and the specified object type does not match.
> I prefer #1 and between #2 and #3, I prefer #2.  
> 
> Are there any other options that should be considered?  Which option is preferred?
> 
> Thanks,
> 
> 
> -- 
>  
> JG
>  
> <8A7A655D-9ED0-4D38-898D-E9E8B754666E[49].png>
>  
> James Gould
> Principal Software Engineer
> [email-masked]
>  
> 703-948-3271 (Office)
> 12061 Bluemont Way
> Reston, VA 20190
> VerisignInc.com
> 
> From: Seth Goldman <[email-masked]>
> Date: Thursday, March 28, 2013 3:31 PM
> To: James Gould <[email-masked]>
> Cc: Ben Levac <[email-masked]>, EPP Provreg <[email-masked]>
> Subject: Re: [provreg] Launch Phase EPP Extension Version 08
> 
>> True, the phase may not be sufficient. I guess there are three possible values here:
>> Create an application for this domain, otherwise fail.
>> Allocate this domain, otherwise fail.
>> Allocate this domain if possible; otherwise create an application.
>> If registrars are fine with 3) being the default behavior, then there's no need for them to signal their intent. If they would ever want 1) or 2), though, then we should make their intent explicit. I was imagining they 1) or 2) to be desireable because 3) seems like a bad customer experience. But I'm just speculating, and I don't have any special insight here.
>> 
>> 
>> On Thu, Mar 28, 2013 at 3:13 PM, Gould, James <[email-masked]> wrote:
>>> Seth & Ben,
>>> 
>>> Being explicit is certainly good.  Do the Registrars have an issue with the registries requiring the extension to be passed as a form of signaling the intent for creates during the launch phases?  If so, should an element or attribute be added on the create to indicate whether the intent is to create an application or registration?  The phase alone might not define the intent.
>>> 
>>> 
>>> -- 
>>>  
>>> JG
>>>  
>>> <8A7A655D-9ED0-4D38-898D-E9E8B754666E[46].png>
>>>  
>>> James Gould
>>> Principal Software Engineer
>>> [email-masked]
>>>  
>>> 703-948-3271 (Office)
>>> 12061 Bluemont Way
>>> Reston, VA 20190
>>> VerisignInc.com
>>> 
>>> From: Seth Goldman <[email-masked]>
>>> Date: Thursday, March 28, 2013 12:49 PM
>>> To: Ben Levac <[email-masked]>
>>> Cc: James Gould <[email-masked]>, EPP Provreg <[email-masked]>
>>> 
>>> Subject: Re: [provreg] Launch Phase EPP Extension Version 08
>>> 
>>>> I think the extension would be preferable. It can serve as a signal of intent from the registrar that they know exactly what phase they're applying for. I could perhaps envision a scenario where there's some intercommunication between the registry and registrar on the ending time of sunrise, and the registrar ends up creating an application instead of an allocated registration on create.
>>>> 
>>>> 
>>>> On Thu, Mar 28, 2013 at 12:36 PM, Ben Levac <[email-masked]> wrote:
>>>>> James,
>>>>> 
>>>>> In an environment where multiple TLDs are hosted on the same server, where TLDs can be in different phases, then it might seem like a good idea to ask the registrar to pass in the <lauch:create> extension to confirm that they know what they are asking for (sunrise application vs landrush application vs registration).  And it might not only be for landrush, but some registries may have multiple sunrise periods where the second sunrise is based on other criteria (belonging to an organization, or to a group for example), and not on Mark data.
>>>>> 
>>>>> But I also realize that making the <choice> optional means that we can't rely on XML validation to ensure that those elements are passed for regular ICANN mandated sunrise periods.
>>>>> 
>>>>> I would be interested to hear from other registries planning on running landrush phases and whether they feel that an extension would be preferable or not.
>>>>> 
>>>>> Cheers,
>>>>> 
>>>>> Ben
>>>>> 
>>>>> -----Original Message-----
>>>>> From: Gould, James [mailto:[email-masked]]
>>>>> Sent: Thursday, March 28, 2013 9:21 AM
>>>>> To: Ben Levac; EPP Provreg ([email-masked])
>>>>> Subject: Re: [provreg] Launch Phase EPP Extension Version 08
>>>>> 
>>>>> Ben,
>>>>> 
>>>>> If the registry does not require any additional launch information from the client on the create (mark or notice), then the extension does not need to be passed.  By making the mark or notice optional on the create, the only element passed would be the phase.  Do you believe that passing the phase and requirement the extension will help in the contract between the client and the server for a non-sunrise phase where a notice is not required?  I recommend only adding the extension when it is needed.
>>>>> 
>>>>> --
>>>>> 
>>>>> JG
>>>>> 
>>>>> 
>>>>> 
>>>>> James Gould
>>>>> Principal Software Engineer
>>>>> [email-masked]
>>>>> 
>>>>> 703-948-3271 (Office)
>>>>> 12061 Bluemont Way
>>>>> Reston, VA 20190
>>>>> VerisignInc.com
>>>>> 
>>>>> 
>>>>> 
>>>>> 
>>>>> 
>>>>> On 3/28/13 12:02 PM, "Ben Levac" <[email-masked]> wrote:
>>>>> 
>>>>> >Guys,
>>>>> >
>>>>> >Thank you for the updated spec.
>>>>> >
>>>>> >One small comment.  If a registry wishes to use the <launch:create>
>>>>> >extension for landrush, the schema forces us to pass either of
>>>>> ><launch:codeMark>, <smd:signedMark>, <smd:encodedSignedMark> or
>>>>> ><launch:notice>.  However, in most cases, I assume that registries
>>>>> >would not expect any Mark information, and for most cases, no notice
>>>>> >information during the landrush period.  Could we not make those pieces
>>>>> >of information optional by adding a minOccurs = 0 to the choice element?
>>>>> >
>>>>> >I guess another option would be to NOT require the <launch:create> in
>>>>> >landrush since no other pieces of information are required... However,
>>>>> >I feel that it is nice to require it because it confirms that the
>>>>> >registrar knows that he's submitting a domain application as opposed to
>>>>> >a domain registration.
>>>>> >
>>>>> >Cheers,
>>>>> >
>>>>> >Ben Levac
>>>>> >
>>>>> >-----Original Message-----
>>>>> >From: [email-masked] [mailto:[email-masked]] On
>>>>> >Behalf Of Gould, James
>>>>> >Sent: Thursday, March 28, 2013 6:58 AM
>>>>> >To: EPP Provreg ([email-masked])
>>>>> >Subject: [provreg] Launch Phase EPP Extension Version 08
>>>>> >
>>>>> >Wil Tan, Gavin Brown and I have updated the Launch Phase EPP Extension
>>>>> >Mapping to Version 08.  You can find the draft at the URL
>>>>> >http://tools.ietf.org/html/draft-tan-epp-launchphase-08.  This version
>>>>> >includes the following changes:
>>>>> >
>>>>> >   1.  Added support for use of the launch statuses and poll messaging
>>>>> >for Launch Registrations based on feedback from Sharon Wodjenski and
>>>>> >Trung Tran.
>>>>> >   2.  Incorporated changes based on updates or clarifications in
>>>>> >draft-lozano-tmch-func-spec-01
>>>>> ><http://tools.ietf.org/html/draft-lozano-tmch-func-spec-01>, which
>>>>> >include:
>>>>> >       1.  Removed the unused <launch:generatedDate> element.
>>>>> >       2.  Removed the <launch:source> element.
>>>>> >       3.  Added the <launch:notAfter> element based on the required
>>>>> ><tmNotice:notAfter> element.
>>>>> >
>>>>> >We are hoping that the draft can be stabilized to help with the
>>>>> >implementations.  Please reply with any feedback.
>>>>> >
>>>>> >Thanks,
>>>>> >
>>>>> >JG
>>>>> >
>>>>> >James F. Gould
>>>>> >Verisign
>>>>> >
>>>>> >
>>>>> >_______________________________________________
>>>>> >provreg mailing list
>>>>> >[email-masked]
>>>>> >https://www.ietf.org/mailman/listinfo/provreg
>>>>> >
>>>>> >Please NOTE: This electronic message, including any attachments, may
>>>>> >include privileged, confidential and/or inside information owned by
>>>>> >Demand Media, Inc. Any distribution or use of this communication by
>>>>> >anyone other than the intended recipient(s) is strictly prohibited and
>>>>> >may be unlawful.  If you are not the intended recipient, please notify
>>>>> >the sender by replying to this message and then delete it from your
>>>>> >system. Thank you.
>>>>> >_______________________________________________
>>>>> >provreg mailing list
>>>>> >[email-masked]
>>>>> >https://www.ietf.org/mailman/listinfo/provreg
>>>>> 
>>>>> 
>>>>> Please NOTE: This electronic message, including any attachments, may include privileged, confidential and/or inside information owned by Demand Media, Inc. Any distribution or use of this communication by anyone other than the intended recipient(s) is strictly prohibited and may be unlawful.  If you are not the intended recipient, please notify the sender by replying to this message and then delete it from your system. Thank you.
>>>>> _______________________________________________
>>>>> provreg mailing list
>>>>> [email-masked]
>>>>> https://www.ietf.org/mailman/listinfo/provreg
>>>> 
>> 
> <8A7A655D-9ED0-4D38-898D-E9E8B754666E[46].png>_______________________________________________
> provreg mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/provreg

---

From: "Gould, James" <[email-masked]>
Date: Tue, 2 Apr 2013 12:32:37 +0000

Rubens,

Are you saying that the server should not be required to validate the properties passed or that the server should not require the extension?  The options that we have been discussing thus far include:

  1.  Option 1 – Leave it as is, meaning the extension can only be passed when the mark or notice is required.
  2.  Option 2 – The extension is optional when the mark and notice is not required
     *   Option 2b – Option 2 plus the server is required to validate what is passed
  3.  Option 3 – The extension is required for all non-open phases and the server is required to validate what is passed
  4.  Option 4 – The extension is optional when the mark and notice is not required, but may be required based on registry policy.
     *   Option 4b - Option 4 plus the server is required to validate what is passed

I added an Option 4 and Option 4b if we cannot come to consensus on the server behavior.  Which option do you support or do you have any more options for consideration?

--

JG

James Gould

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

From: Rubens Kuhl <[email-masked]<mailto:[email-masked]>>
Date: Monday, April 1, 2013 8:31 PM
To: James Gould <[email-masked]<mailto:[email-masked]>>
Cc: Seth Goldman <[email-masked]<mailto:[email-masked]>>, EPP Provreg <[email-masked]<mailto:[email-masked]>>
Subject: Re: [provreg] Launch Phase EPP Extension Version 08

James,

Rubens

Seth,

  1.  Leave the draft, where the client only passes the extension when the mark or notice information is needed.  The server will create the appropriate object (application or registration) based on the active phase and return the appropriate result code (1001 or 1000) and optionally with the launch phase extension.
  2.  Update the draft to support the option for the client to explicitly define the intended phase and optionally the intended object type (application or registration) in the extension to create.  The server will fail the command if the specified phase does not match and the specified object type does not match.
  3.  Update the draft to require the client to explicitly define the intended phase and intended object type (application or registration) in the extension to create.  The server will fail the command if the specified phase does not match and the specified object type does not match.

Thanks,

--

JG

James Gould
Principal Software Engineer
[email-masked]<mailto:[email-masked]>

703-948-3271 (Office)
12061 Bluemont Way
Reston, VA 20190
VerisignInc.com<http://VerisignInc.com>

From: Seth Goldman <[email-masked]<mailto:[email-masked]>>
Date: Thursday, March 28, 2013 3:31 PM
To: James Gould <[email-masked]<mailto:[email-masked]>>
Cc: Ben Levac <[email-masked]<mailto:[email-masked]>>, EPP Provreg <[email-masked]<mailto:[email-masked]>>
Subject: Re: [provreg] Launch Phase EPP Extension Version 08

  1.  Create an application for this domain, otherwise fail.
  2.  Allocate this domain, otherwise fail.
  3.  Allocate this domain if possible; otherwise create an application.

On Thu, Mar 28, 2013 at 3:13 PM, Gould, James <[email-masked]<mailto:[email-masked]>> wrote:
Seth & Ben,

--

JG

James Gould
Principal Software Engineer
[email-masked]<mailto:[email-masked]>

703-948-3271 (Office)
12061 Bluemont Way
Reston, VA 20190
VerisignInc.com<http://VerisignInc.com>

From: Seth Goldman <[email-masked]<mailto:[email-masked]>>
Date: Thursday, March 28, 2013 12:49 PM
To: Ben Levac <[email-masked]<mailto:[email-masked]>>
Cc: James Gould <[email-masked]<mailto:[email-masked]>>, EPP Provreg <[email-masked]<mailto:[email-masked]>>

On Thu, Mar 28, 2013 at 12:36 PM, Ben Levac <[email-masked]<mailto:[email-masked]>> wrote:
James,

Cheers,

Ben

-----Original Message-----
From: Gould, James [mailto:[email-masked]<mailto:[email-masked]>]
Sent: Thursday, March 28, 2013 9:21 AM
To: Ben Levac; EPP Provreg ([email-masked]<mailto:[email-masked]>)
Subject: Re: [provreg] Launch Phase EPP Extension Version 08

Ben,

--

JG

James Gould
Principal Software Engineer
[email-masked]<mailto:[email-masked]>

703-948-3271 (Office)
12061 Bluemont Way
Reston, VA 20190
VerisignInc.com<http://VerisignInc.com>

On 3/28/13 12:02 PM, "Ben Levac" <[email-masked]<mailto:[email-masked]>> wrote:

>From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]<mailto:[email-masked]>] On
>Behalf Of Gould, James
>To: EPP Provreg ([email-masked]<mailto:[email-masked]>)
>[email-masked]<mailto:[email-masked]>
>[email-masked]<mailto:[email-masked]>

Please NOTE: This electronic message, including any attachments, may include privileged, confidential and/or inside information owned by Demand Media, Inc. Any distribution or use of this communication by anyone other than the intended recipient(s) is strictly prohibited and may be unlawful.  If you are not the intended recipient, please notify the sender by replying to this message and then delete it from your system. Thank you.
_______________________________________________
provreg mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/provreg

<8A7A655D-9ED0-4D38-898D-E9E8B754666E[46].png>_______________________________________________
provreg mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/provreg

---

From: Rubens Kuhl <[email-masked]>
Date: Tue, 2 Apr 2013 11:56:02 -0300

James,

I was referring to the server not be required to validate the properties (option 2a). Option 4 seems to be getting into RRA (Registry-Registrar Agreement) territory...

Requiring or not the extension seems an ICANN policy topic to me, probably best suited for other fora... 

Rubens

Em 02/04/2013, às 09:32:000, Gould, James escreveu:

> Option 1 – Leave it as is, meaning the extension can only be passed when the mark or notice is required.
> Option 2 – The extension is optional when the mark and notice is not required
> Option 2b – Option 2 plus the server is required to validate what is passed 
> Option 3 – The extension is required for all non-open phases and the server is required to validate what is passed
> Option 4 – The extension is optional when the mark and notice is not required, but may be required based on registry policy.  
> Option 4b - Option 4 plus the server is required to validate what is passed 
> <8A7A655D-9ED0-4D38-898D-E9E8B754666E[73].png>
>  
> James Gould
> From: Rubens Kuhl <[email-masked]>
> Cc: Seth Goldman <[email-masked]>, EPP Provreg <[email-masked]>

---

From: "Gould, James" <[email-masked]>
Date: Tue, 2 Apr 2013 15:06:51 +0000

Rubens,

Option 4 covers when the extension is applicable, and therefore belongs in the extension and does not move into the territory of RRA.  When to use and not to use the extension along with the properties to pass in the extension is not an ICANN policy topic but is a protocol topic.  Why would the server not validate the properties passed by the client against the active policies (phase or object type)?

--

JG

James Gould

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

Date: Tuesday, April 2, 2013 10:56 AM

James,

Rubens

Rubens,

--

JG

James Gould

703-948-3271 (Office)
12061 Bluemont Way
Reston, VA 20190

James,

Rubens

Seth,

Thanks,

--

JG

James Gould

703-948-3271 (Office)
12061 Bluemont Way
Reston, VA 20190
VerisignInc.com<http://VerisignInc.com/>

--

JG

James Gould

703-948-3271 (Office)
12061 Bluemont Way
Reston, VA 20190
VerisignInc.com<http://VerisignInc.com/>

Cheers,

Ben

-----Original Message-----
From: Gould, James [mailto:[email-masked]<mailto:[email-masked]>]
Sent: Thursday, March 28, 2013 9:21 AM
To: Ben Levac; EPP Provreg ([email-masked]<mailto:[email-masked]>)
Subject: Re: [provreg] Launch Phase EPP Extension Version 08

Ben,

--

JG

James Gould

703-948-3271 (Office)
12061 Bluemont Way
Reston, VA 20190
VerisignInc.com<http://VerisignInc.com/>

---

From: Klaus Malorny <[email-masked]>
Date: Wed, 03 Apr 2013 14:18:20 +0200

On 02/04/13 14:32, Gould, James wrote:
> Rubens,
>
> Are you saying that the server should not be required to validate the properties
> passed or that the server should not require the extension?  The options that we
> have been discussing thus far include:
>
>      1. Option 2b – Option 2 plus the server is required to validate what is passed
>  4. Option 4 – The extension is optional when the mark and notice is not
>     required, but may be required based on registry policy.
>      1. Option 4b - Option 4 plus the server is required to validate what is passed
>
> I added an Option 4 and Option 4b if we cannot come to consensus on the server
> behavior.  Which option do you support or do you have any more options for
> consideration?
>
> --
>
> JG

Hi James, all,

hard to catch up with all the e-mails sent the last days... To add my two cents, 
if anyone is interested in: My concern is that a registrar issues a normal 
domain:create request without any (launch phase) extensions and does not get 
what he expects, namely an application for a domain instead of a domain 
registration. The matter is hereby less whether the registration is pending or 
immediate, but whether there is a potential contention between this request and 
other requests for the same name (which will be eventually resolved by some 
means, e.g. auctions), whether there might be a different price tag attached to 
the operation and whether there are suddenly other obligations to the registrar 
or registrant (e.g. participating in the mentioned auctions). The operation 
should IMHO be predictable, a mere change of the domain name (e.g. using a newly 
introduced IDN character) should not determine whether this is a registration or 
application.

Insofar, to support applications without the need of the submission of trademark 
data, I tend to prefer option 3.

In respect of changing the number of occurrences of the <choice> element to 
zero, one could consider to add a element wildcard to the choice (i.e. e.g. <any 
namespace="##other" process-contents="strict">), just to allow other data as 
well. Currently, we do not have a use case for this, but we don't know whether 
we will have one sometime in the future, and maybe other registries have a use 
case right now.

Regards,

Klaus

---

From: "Gould, James" <[email-masked]>
Date: Wed, 3 Apr 2013 12:57:11 +0000

Klaus,

Thanks for your feedback.  It's great to get so many different
perspectives on this topic.  The feedback has been a mix of all three
options, so I do not believe we can use the MUST word but have to soften
it to a SHOULD where applicable. If there is any other feedback on this
from the community, please let us know so that we can take it into account
in updating the draft.

What is the goal of using the wildcard in the choice?  There is
extensibility already built into the extension to support custom marks and
signed marks based on substitution for the <mark:abstractMark>,
<smd:abstractSignedMark>, or <smd:encodedSignedMark> elements defined in
draft-lozano-tmch-smd-01.  Is there the need to add more generic
extensibility within the extension and if so for what purpose?

Thanks,  

-- 
 
JG

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

On 4/3/13 8:18 AM, "Klaus Malorny" <[email-masked]> wrote:

>>  1. Option 1  Leave it as is, meaning the extension can only be passed
>>when the
>>     mark or notice is required.
>>  2. Option 2  The extension is optional when the mark and notice is
>>not required
>>      1. Option 2b  Option 2 plus the server is required to validate
>>what is passed
>>  3. Option 3  The extension is required for all non-open phases and
>>the server
>>     is required to validate what is passed
>>  4. Option 4  The extension is optional when the mark and notice is not

---

From: Klaus Malorny <[email-masked]>
Date: Wed, 03 Apr 2013 17:18:02 +0200

> extensibility within the extension and if so for what purpose?

Hi James,

yes, you are right, I missed this substitution group feature of XML Schema that 
has been used there, which allows own XML structures.

Regards,

Klaus

---

From: Ben Levac <[email-masked]>
Date: Mon, 8 Apr 2013 09:51:23 -0700

James,

Sorry I was not available to follow up last week on this thread.

We've already voiced our preference for option #3, but since there are registries that do not want to make the extension mandatory, I think option #4 would allow registries to make the extension mandatory or not based on policy.  We had ruled this option out earlier in this thread because it means diverging behavior between registries, but I think it might be a good compromise to allow us to move forward.

As for making the <choice> element have a minOccurs of 0 as discussed by Klaus, I think this is required for cases where no extra information is required such as a landrush where the registry is accepting applications.

Cheers,

Ben

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Gould, James
Sent: Wednesday, April 03, 2013 5:57 AM
To: Klaus Malorny; [email-masked]
Subject: Re: [provreg] Launch Phase EPP Extension Version 08

Klaus,

Thanks for your feedback.  It's great to get so many different perspectives on this topic.  The feedback has been a mix of all three options, so I do not believe we can use the MUST word but have to soften it to a SHOULD where applicable. If there is any other feedback on this from the community, please let us know so that we can take it into account in updating the draft.

What is the goal of using the wildcard in the choice?  There is extensibility already built into the extension to support custom marks and signed marks based on substitution for the <mark:abstractMark>, <smd:abstractSignedMark>, or <smd:encodedSignedMark> elements defined in draft-lozano-tmch-smd-01.  Is there the need to add more generic extensibility within the extension and if so for what purpose?

Thanks,

--

JG

James Gould

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

On 4/3/13 8:18 AM, "Klaus Malorny" <[email-masked]> wrote:

>> Are you saying that the server should not be required to validate the
>>properties  passed or that the server should not require the
>>extension?  The options that we  have been discussing thus far
>>include:
>>
>>  1. Option 1  Leave it as is, meaning the extension can only be
>>passed when the
>> I added an Option 4 and Option 4b if we cannot come to consensus on
>>the server  behavior.  Which option do you support or do you have any
>>more options for  consideration?
>>
>> --
>>
>> JG
>
>
>Hi James, all,
>
>hard to catch up with all the e-mails sent the last days... To add my
>two cents, if anyone is interested in: My concern is that a registrar
>issues a normal domain:create request without any (launch phase)
>extensions and does not get what he expects, namely an application for
>a domain instead of a domain registration. The matter is hereby less
>whether the registration is pending or immediate, but whether there is
>a potential contention between this request and other requests for the
>same name (which will be eventually resolved by some means, e.g.
>auctions), whether there might be a different price tag attached to the
>operation and whether there are suddenly other obligations to the
>registrar or registrant (e.g. participating in the mentioned auctions).
>The operation should IMHO be predictable, a mere change of the domain
>name (e.g. using a newly introduced IDN character) should not determine
>whether this is a registration or application.
>
>Insofar, to support applications without the need of the submission of
>trademark data, I tend to prefer option 3.
>
>In respect of changing the number of occurrences of the <choice>
>element to zero, one could consider to add a element wildcard to the
>choice (i.e.
>e.g. <any
>namespace="##other" process-contents="strict">), just to allow other
>data as well. Currently, we do not have a use case for this, but we
>don't know whether we will have one sometime in the future, and maybe
>other registries have a use case right now.
>
>
>Regards,
>
>Klaus
>
>
>
>
>
>
>
>