Subject: [regext] Comments about draft-gould-casanova-regext-unhandled-namespaces

From: "Patrick Mevzek" <[email-masked]>
Date: Sun, 06 Jan 2019 23:01:55 -0500

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
  [email-masked]

---

From: "Gould, James" <[email-masked]>
Date: Mon, 7 Jan 2019 14:33:34 +0000

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
[email-masked]

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" <[email-masked] on behalf of [email-masked]> wrote:

    Hello James and Martin,

    §3 says:

    

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).  

    

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.  

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.  

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).

    

    

    

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.

    -- 
      Patrick Mevzek
      [email-masked]
    
    _______________________________________________
    regext mailing list
    [email-masked]
    https://www.ietf.org/mailman/listinfo/regext

---

From: Martin Casanova <[email-masked]>
Date: Mon, 7 Jan 2019 17:11:34 +0100

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

/ /

-- 
--- 
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
[email-masked], www.switch.ch 
 
Working for a better digital world

---

From: "Patrick Mevzek" <[email-masked]>
Date: Fri, 11 Jan 2019 02:37:57 -0500

> Hello James and Martin,

Thanks for your attention and comments to my email.
I see that we are in disagreement, so I think it is not useful for me to go again over all points.

My opinion still remains that at this stage the draft abuses RFC 5730 too much and needlessly because I believe there are other options that makes it more in line with RFC 5730 spirit.

In fact I believe that in its current form it will create an interoperability problem
and hence it lowers its chance to be implemented by a huge range of registrars.

It is not a problem for registries of course because on server side it is just the matter
of creating some new nodes at some location in the frame.

But a registrar has to handle many different EPP servers, some will have implemented this extension, some not.

And hence why it does create an interoperability problem?
Because:
1) if this extension is not explicitely announced at greeting time by the server
(something you seem to be very much against)
2) and if you continue to use extValue/value + reason, the latter being for human consumption but you add a format in it with a SHOULD and opening problem with the lang attribute
3) THEN a client (registrar) CAN NOT depend on the reason content to find out about the namespace concerned (because the reason content is only a SHOULD and the specification does not deal with a lang different than "en" ... all points showing again that you should not abuse a human targeted field to put machine readable data in it)
so it can instead just parse the content of <value> and take the first namespace it sees there
BUT it has no idea if the content of <value> is something coming from your extension or something completely different (coming from the initial definition of <value> in RFC5730)
so it will need to use heuristics instead of relying on determinism, or just drop all of it and not caring at all.

It is important for a client to understand if what comes back in value/extValue is due to what it has sent (original description of the fields in RFC 5730) or something completely different as in your extension. In its current form your extension leaves no way for a registrar to know without doubt in which case it is.

I think that creating this interoperability problem just adds one more problem on top of the problem of handling unknown namespaces.

Hence I will not be in favor of this extension going forward in its current shape.

-- 
  Patrick Mevzek
  [email-masked]

---

From: "Gould, James" <[email-masked]>
Date: Fri, 11 Jan 2019 21:50:13 +0000

Patrick,

I provide responses to your feedback below, prefixed with "JG - ".
  
—
 
JG

James Gould
Distinguished Engineer
[email-masked]

703-948-3271
12061 Bluemont Way
Reston, VA 20190

On 1/11/19, 2:38 AM, "regext on behalf of Patrick Mevzek" <[email-masked] on behalf of [email-masked]> wrote:

    

JG - We will agree to disagree on this one.

    

JG - How does announcing something in the greeting help out here, which at most would be a single namespace?  By including a namespace in the greeting, what is expected if the client does not include that namespace in the login services?  This represents a chicken and egg situation.  The namespace does not define exactly which extensions and for what type of responses the server will apply draft-gould-casanova-regext-unhandled-namespaces to.  That is why the policy of the implementation of draft-gould-casanova-regext-unhandled-namespaces is best suited in a policy extension of the Registry Mapping, where policy information can be made much clearer.  We discussed creating an extension to communicate the unhandled namespaces issue at the REGEXT meeting, which was quickly eliminated because of the chicken and egg situation.  There is a further issue that the BCP of draft-gould-casanova-regext-unhandled-namespaces does not fit any type of existing EPP extension (object, command / response, protocol) that would be communicated in the greeting.  I don't believe the EPP greeting should be used to communicate a BCP or a policy.  

JG - Why is providing a recommended formatted human readable reason in the draft considered an interoperability problem?  Having a consistent reason for the inclusion of the <extValue> element will provide clarity and should help with interoperability.  If the lang attribute is causing concern, text can be added to also recommend using the default "lang" attribute value of "en".  Since the draft has this defined as a SHOULD, a server implementer can choose to use a different reason in a different language. 

JG - This reason is meant by RFC 5730 and by draft-gould-casanova-regext-unhandled-namespaces to be human readable and is not meant in any way for a software client to parse it and depend on it.  There is absolutely nothing wrong with recommending a more consistent and more human readable reason in the draft.

    

JG - I don't view the points that you raised as interoperability problems as noted above.  I hope that I can change your mind in the future, since many options have been considered to address the unhandled namespace issue, and the approach in draft-gould-casanova-regext-unhandled-namespaces is the best of the options in my opinion.  
    
    -- 
      Patrick Mevzek
      [email-masked]