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.
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...
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.
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
- 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.
Thanks for your consideration.
--
Patrick Mevzek
p...@dotandco.com
_______________________________________________
regext mailing list
regext@ietf.org
https://www.ietf.org/mailman/listinfo/regext
