Re: Launch Phase EPP Extension Version 08

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 protected] [mailto:[email protected]] On Behalf Of Gould, James
Sent: Wednesday, April 03, 2013 5:57 AM
To: Klaus Malorny; [email protected]
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
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

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