Re: 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
Principal Software Engineer
[email protected]
 
703-948-3271 (Office)
12061 Bluemont Way
Reston, VA 20190
VerisignInc.com





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

>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 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
>>     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
>
>
>
>
>
>
>
>
>_______________________________________________
>provreg mailing list
>[email protected]
>https://www.ietf.org/mailman/listinfo/provreg

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