Patrick, Thank you for doing a detailed review of draft-gould-casanova-regext-unhandled-namespaces and providing your feedback. I respond to your feedback embedded below with a "JG - " prefix. — JG
James Gould Distinguished Engineer jgo...@verisign.com 703-948-3271 12061 Bluemont Way Reston, VA 20190 Verisign.com <http://verisigninc.com/> On 1/6/19, 11:02 PM, "regext on behalf of Patrick Mevzek" <regext-boun...@ietf.org on behalf of p...@dotandco.com> wrote: Hello James and Martin, While implementing this specification, the following occured to me: §3 says: <reason>: A formatted human-readable message that indicates the reason the unhandled namespace data was not returned in the appropriate location of the response. The formatted reason SHOULD follow the Augmented Backus-Naur Form (ABNF) grammar [RFC5234] format: NAMESPACE-URI "not in login services", where NAMESPACE-URI is the unhandled XML namespace like "urn:ietf:params:xml:ns:domain-1.0" for [RFC5731]. However RFC5730 §2.6 defines the <reason> node as such: A <reason> element containing a human-readable message that describes the reason for the error. The language of the response is identified via an OPTIONAL "lang" attribute. If not specified, the default attribute value MUST be "en" (English). It is then my opinion that the following would be technically allowed: <extValue> <value> ... </value> <reason lang="fr"> urn:X not in login services </reason> </extValue> Which is kind of strange because "urn:X not in login services" is certainly not in a French language. Or at least there should be a mention in the specification to explicitely forbid that. But more globally, the problem comes from the fact that <reason> is supposed to be human-readable message and as such should not convey a format for machine readable content. JG - The reason is not meant to be machine readable in draft-gould-casanova-regext-unhandled-namespaces, but provides the recommended format, via the SHOULD, to make it easier for the client to identify the root cause for the movement of the information. In this case, it is meant to make the human readable content more readable. If the server does define a different language for the reason, then certainly the "not in login service" text should be translated to the specified language (e.g., French). In fact, reading above in RFC5730 yields: A <value> element that identifies a **client-provided** element (including XML tag and value) that caused a server error condition. I emphasized the **client-provided** which is not the case in all examples of your draft since all content there are coming from the server directly. Note that the "top" <value> (outside of <extValue>) is defined slightly differently because it is: Zero or more OPTIONAL <value> elements that identify a client- provided element (including XML tag and value) or other information that caused a server error condition. Note the: **or other information that caused a server error condition**. (even if technically the two <value> nodes are defined by the same type) So in short, while I believe your draft is the best solution on the table for now if we want to do something about unhandled namespaces, I still think that with this form it abuses RFC 5730 a little too much... JG - I agree that RFC5730 defines the use of the <value> to indicate the client-provided element that caused the server error. I would consider draft-gould-casanova-regext-unhandled-namespaces as representing a partial error, where a success is returned and the information is moved, since the client does not support the required service. The problem is most apparent when it comes to the poll messages, since the poll messages are meant to inform the client of something that they need to be aware of, but the information cannot be returned due to the client login services. It is clearly not client-provided elements that caused the inclusion of the <extValue> element in the response, but the use of the <extValue> element was discussed at the REGEXT meeting with no objections raised. I would not classify draft-gould-casanova-regext-unhandled-namespaces as abusing RFC 5730, but instead classify it as leveraging the elements defined within RFC 5730 to help define a practice that solves a protocol issue that RFC 5730 did not envision. Also, since the client may need to be able to detect this case, I would recommend that support for this way of handling unknown namespaces is exposed at greeting time by a specific namespace. Otherwise the client has to use a regular expression on the reason. JG - This can be handled by defining a unhandled namespace policy extension of the Registry Mapping (draft-gould-carney-regext-registry), since the policies for draft-gould-casanova-regext-unhandled-namespaces go beyond the definition of a single namespace in the greeting. Where is the unhandled namespace practice used by the server? Is it used for poll messaging (object extension, command response extension, or both), is it used for general responses and if so which ones, or is it used for both? We could also add the policy on the format of the reason. For all the above reasons, I would recommend the following changes to the specification: - the server has to specify his support for this extension in <greeting>, by a specific namespace JG - draft-gould-casanova-regext-unhandled-namespaces does not define an XML namespace and the policy for draft-gould-casanova-regext-unhandled-namespaces is best handled in a policy extension of the Registry Mapping (draft-gould-carney-regext-registry). - instead of using <extValue> and abusing its <reason> part, I advise the following: 1) either use 2 <value>, one with what you put currently in <reason>, the other with the current <value> 2) or use a single <value> but with such a structure (to be refined with a proper namespace) <value> <unhandledNamespace xmlns="..."> <namespace>urn:ietf:params:xml:ns:secDNS-1.1</namespace> <content> <secDNS:infData xmlns:secDNS="urn:ietf:params:xml:ns:secDNS-1.1"> .... </secDNS:infData> </content> </unhandledNamespace> </value> 3) or simplifying things with an attribute: <value unhandledNamespace="urn:ietf:params:xml:ns:secDNS-1.1"> <secDNS:infData xmlns:secDNS="urn:ietf:params:xml:ns:secDNS-1.1"> .... </secDNS:infData> </value> (use namespaceNotInLogin instead of unhandleNamespace or anything else, if prefered) This is based on the fact that <value> is defined as such: <complexType name="errValueType" mixed="true"> <sequence> <any namespace="##any" processContents="skip"/> </sequence> <anyAttribute namespace="##any" processContents="skip"/> </complexType> I kind of prefer the last version as it is the simpler one, but option 2 could fit too. Option 1 seems clunky because it hardcodes dependency between two <value> nodes. Using a "top" <value> instead of inside <extValue> also solves the problem above of the fact that they are defined differently and the value inside of extValue should convey only client-provided content, while the "top" value can be more freeform. JG – I don’t see an issue with the use of <extValue> to include the <value> along with a more human readable <reason>. Option 1 is not helpful since it splits the data from the reason with no additional value, and option 2 and 3 are simply more complex approaches to what is currently defined within draft-gould-casanova-regext-unhandled-namespaces. There is absolutely no need to define a new XML namespace and structure to include the unhandled extension information in the response. I view draft-gould-casanova-regext-unhandled-namespaces as being as simple as you can get, by moving the unhandled extension XML block under a <extValue><value> element and adding a pre-formatted reason based on the XML namespace of the unhandled extension. I prefer keeping it simple. Thanks for your consideration. -- Patrick Mevzek p...@dotandco.com _______________________________________________ regext mailing list regext@ietf.org https://www.ietf.org/mailman/listinfo/regext _______________________________________________ regext mailing list regext@ietf.org https://www.ietf.org/mailman/listinfo/regext
