Hi James, On Thu, Nov 08, 2018 at 07:31:21AM +0000, Gould, James wrote: > Benjamin, > > > > How about the following clarifying changes? > > > Client status values that can be added or removed by a client are prefixed > with "client". Corresponding server status values that can be added or > removed by a server are prefixed with "server". > > > > And > > > > A client MUST NOT alter server status values set by the server.
That works for me. Thank you for fine-tuning the wording. -Benjamin > > > — > > JG > > > > > > > > James Gould > > Distinguished Engineer > > jgo...@verisign.com > > > > 703-948-3271 > > 12061 Bluemont Way > > Reston, VA 20190 > > > > Verisign.com <http://verisigninc.com/> > > > > On 11/7/18, 11:43 PM, "Benjamin Kaduk" <ka...@mit.edu> wrote: > > > > [Sorry for the misattribution in the quoting -- the text/plain I'm > > responding to did not indicate any quoting at all and I'd probably mess it > > up if I tried to manually fix it] > > > > On Wed, Nov 07, 2018 at 11:39:40AM +0000, Gould, James wrote: > > > Benjamin, > > > > > > > > > > > > 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? > > > > > > > > > > > > The “ok” status is the default status and not classified as a server > status, since it is not prefixed with “server”. The sentence “A client MUST > NOT alter status values set by the server.” means that the client cannot set > or remove a server status, such as serverUpdateProhibited. I hope this > clarifies what is defined in the EPP RFCs (5730-5733) and > draft-ietf-regext-org. > > > > To be clear, I'm solely commenting on the specific wording -- a "status > set > > by the server" is a different meaning than a "server status". In the > > dumbest possible reading, the server sets the "ok" status at creation, and > > the exact proposed text could be read as denying the client from changing > > it. So, my point is just "be careful about the way you word it". > > > > -Benjamin > > > > > > > > > > > — > > > > > > JG > > > > > > > > > > > > > > > > > > > > > > > > James Gould > > > > > > Distinguished Engineer > > > > > > jgo...@verisign.com > > > > > > > > > > > > 703-948-3271 > > > > > > 12061 Bluemont Way > > > > > > Reston, VA 20190 > > > > > > > > > > > > Verisign.com <http://verisigninc.com/> > > > > > > > > > > > > On 10/31/18, 10:23 AM, "Benjamin Kaduk" <ka...@mit.edu> wrote: > > > > > > > > > > > > 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 regext@ietf.org https://www.ietf.org/mailman/listinfo/regext
