Trimming to just one potentially problematic suggestion...

On Wed, Oct 31, 2018 at 10:25:42AM +0800, Linlin Zhou wrote:
> 
> Linlin Zhou
> ----------------------------------------------------------------------
> DISCUSS:
> ----------------------------------------------------------------------
[...]
> [Linlin] Our proposal is to add the lead-in bolded text to match the existing 
> EPP RFC's to the Organization mapping. There has been no issues with the 
> interpretation of the statuses with the EPP RFCs, so it's best to match them 
> as closely as possible. In section 3.4,

[bold does not work super-well in text/plain mail, but
https://www.ietf.org/mail-archive/web/regext/current/msg01912.html can show
it]

> An organization object MUST always have at least one associated status 
> value. Status values can be set only by the client that sponsors an 
> organization object and by the server on which the object resides. A 
> client can change the status of an organization object using the EPP 
> <update> command. Each status value MAY be accompanied by a string 
> of human-readable text that describes the rationale for the status 
> applied to the object. 
> 
> A client MUST NOT alter status values set by the server. A server 

This seems overly zealous to the point of being harmful.  For example, if a
server sets the status to "ok", a client cannot replace it by
clientLinkProhibited?

-Benjamin

> MAY alter or override status values set by a client, subject to local 
> server policies. The status of an object MAY change as a result of 
> either a client-initiated transform command or an action performed by 
> a server operator.
> 
> Status values that can be added or removed by a client are prefixed 
> with "client". Corresponding status values that can be added or 
> removed by a server are prefixed with "server". The "hold" and 
> "terminated" status values are server-managed when the organization 
> has no parent identifier [Section 3.6] and otherwise MAY be client- 
> managed based on server policy. Status values that 
> do not begin with either "client" or "server" are server-managed.
> 
> Take "clientUpdateProhibited" for example. 
> If status value "clientUpdateProhibited" is set by a client 
> then <update> command is not allowed to perform by a client 
> If status value "clientUpdateProhibited" is removed by a client or a server 
> then no limitation of performing EPP commands 
> 
>  
> 
>  

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

Reply via email to