Patrick, Thanks from my side too for having implemented and put thought into this draft! Here is my reply about the topics you brought up.
Reason: "not in login services" could be translated to French in the lang="fr" case. (Does anyone know of an implementation other than English ?!?) ABNF: I think the ABNF for the reason is a "nice to have" but not really needed since the whole extValue Element is not meant to be machine readable. However there is written SHOULD so I guess its up to the implementer to decide this. The reason should give humans a hint to why the Response is rendered in this unusual form and what should be done to correct the suboptimal situation (include extension in login services) Value: /result/value instead of result/extValue/value: Good point! I agree that the location /result/value would be better than result/extValue/value in terms of compliance to RFC-5730 because of the "or other information that caused a server error condition" which makes the usage of /result/value broader. The reason why I suggested extValue was because it gives the possibility to add a reason which is bound to the value. It's a trade off.. I believe that the usage of result/extValue/value is still matches the intent of RFC-5730 and would be accepted by the group?One could also argue if the condition is a server error condition... after all the response Code is 130x and not 2xxx. Your ideas Option 2 and 3 of the own namespaces look elegant to me however there are 2 drawbacks to me: - more complicated to implement since own namespace is needed. Wouldn't this new namespace need to be configured at login to be compliant which kind of defeats the whole purpose of the unhandled namespaces draft? - no reason so one would have to read the draft before understanding whats going on ... Regards Martin / / On 07.01.19 15:33, Gould, James wrote: > 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 -- --- SWITCH Martin Casanova, Domain Applications Werdstrasse 2, P.O. Box, 8021 Zurich, Switzerland phone +41 44 268 15 55, direct +41 44 268 16 25 martin.casan...@switch.ch, www.switch.ch Working for a better digital world
_______________________________________________ regext mailing list regext@ietf.org https://www.ietf.org/mailman/listinfo/regext
