> On Nov 30, 2017, at 7:34 PM, Gould, James <[email protected]> wrote: > > Ben, > > It comes down to one issue with the ”A client (MUST|SHOULD) NOT pass the > extension on an EPP <update> command to a server that does not support launch > applications”. How about taking a different approach on this one, since I > don’t want to start down the slippery slope of defining server policy > discovery in the draft? > > The intend of this sentence is to simply state “An EPP <update> command with > the extension sent to a server that does not support launch applications will > fail. A server that …”. There is no MUST NOT or SHOULD NOT language for the > client and it defines the expected behavior in the protocol. > > Thoughts?
I think that’s a good solution (although since it is a complete removal of a normative statement late in the process, please consult with Adam on how to proceed.) Thanks! Ben. > > Thanks, > > — > > JG > > > > James Gould > Distinguished Engineer > [email protected] > > 703-948-3271 > 12061 Bluemont Way > Reston, VA 20190 > > Verisign.com <http://verisigninc.com/> > > On 11/30/17, 4:05 PM, "Ben Campbell" <[email protected]> wrote: > > Replies inline. I removed sections that don’t seem to need further > discussion. > > Thanks! > > Ben. > >> On Nov 30, 2017, at 5:58 PM, Gould, James <[email protected]> wrote: >> >> Ben, >> >> Thanks, my replies are below. >> >> > > […] > >>> >>>> >>>> >>>> -2.4, 3rd to last paragraph: >>>> Why does the custom status value exist if the server should not use it? Are >>>> there cases where a client uses it? >>>> >>>> The custom status value is defined to support corner cases and is not >>>> recommended using SHOULD NOT of RFC 2119? >>> >>> Are there corner cases you have in mind? As written, that seems to say >>> “here’s an extension point, but we hope you won’t use it”. Is the point >>> that people SHOULD NOT use it for cases where an existing status value >>> would be appropriate? >>> >>> We believe that the set of statuses will meet the needs for launching a >>> TLD, but we don’t want to limit the use of the launch phase extension. It >>> is important to have a concrete set of statuses along with an extension >>> point. The guidance is that use of the extension point should be avoided >>> if possible. >> >> I think it woujld be clearer say that you SHOULD use one of the defined >> statuses if appropriate, rather than SHOULD NOT use the custom status. >> >> Ok, how about changing “The server SHOULD NOT use the "custom" status >> value.” to “The server SHOULD use one of the non-“custom” status values”? > > WFM > >> >>> >>>> >>>> >>>> -3.4, 2nd paragraph, first sentence: Is a client expected to know in >>>> advance >>>> whether the server supports launch applications? If so, how? >>>> >>>> The client is expected to know based on either an out-of-band mechanism, >>>> or an in-band mechanism that is being discussed now within the REGEXT >>>> working group. >>> >>> It would help to say something to that effect in the text. >>> >>> I believe the mechanism of communicating the policy of the server is >>> out-of-scope for the launch phase extension. The extension defines what is >>> expected from the client (MUST NOT) and the server (return a 2102 error) to >>> match the server policy. This is a slippery slope, since there are other >>> server policy elements (e.g., mark validation models, check forms, create >>> forms) defined in the extension that the client needs to know out-of-band >>> currently and in-band in the future. >> >> The problem is that the current text has a MUST NOT that is difficult or >> impossible to honor without such a mechanism. That effectively implies a >> requirement to know in advance whether the server supports launch phase. >> Would it make sense to soften that to say MUST NOT (or SHOULD NOT) if it >> has knowledge that the server does not support the policy? >> >> Ok, let’s change the MUST NOT to SHOULD NOT, so the sentence in 3.4 will >> read “A client SHOULD NOT pass the extension on an EPP <update> command to a >> server that does not support launch applications”. Does that work for you? > > It helps—but it still creates an implied requirement, although now at the > SHOULD level. If the intent is to create a MUST or SHOULD requirement for the > client to have an (out of band or otherwise) mechanism to learn the server’s > policies, it would be better to state that explicitly. > > OTOH, I’d even be okay with a MUST NOT, as long it was qualified to apply > to clients that have that advance knowledge. > > > > >> >> >> >> >> >> > > >
signature.asc
Description: Message signed with OpenPGP
_______________________________________________ regext mailing list [email protected] https://www.ietf.org/mailman/listinfo/regext
