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