Re: [regext] Signaling BCP support in EPP for draft-ietf-regext-secure-authinfo-transfer and draft-ietf-regext-unhandled-namespaces

[Patrick Mevzek <[e-mail]>]

On Mon, Mar 16, 2020, at 09:28, Gould, James wrote:
>  
> One question that was raised by Patrick Mevzek on the mailing list was 
> associated with signaling the implementation of a BCP by the server 
> that I believe would also apply to the client. This question applies to 
> the two REGEXT BCP drafts draft-ietf-regext-secure-authinfo-transfer 
> and draft-ietf-regext-unhandled-namespaces.

Aside, for this last one that is using extValue I think the extValue should
be more properly categorized to be related to this extension.

Rationale:
1) even if you put a message in <reason>, this part is clearly for humans,
so no software should have to rely on this content
2) extValue can be used for many things. In fact the way the draft is using it
is kind of violating what RFC 5730 says about it:
"A <value> element that identifies a client-provided element
            (including XML tag and value) that caused a server error
            condition."

What will now be put there is NOT client-provided but server-provided.
Which is also one of the reason why I have mixed feelings to handle
unhandled namespaces that way even if there are no other proposals.

So at least maybe something like:
<extValue>
<value xmlns:unhandled="....">
<unhandled:content>

(here would appear the XML part that the server wants to give but can't 
because the associated namespace was not selected by client at login)

</unhandled:content>
</value>
</extValue>


Introducing new content can break existing client without proper signalling.
You might say that if clients have to be updated to do that, they might as well
be updated to correctly handle the unhandled namespace part, but as discussed
previously already, things are not so simple in real life.

> The only existing signaling 
> mechanism in EPP is the use of the greeting and login services. A 
> namespace URI could be assigned for each BCP draft that is included as 
> an <objURI> or an <extURI> in the greeting to inform the client of the 
> support of the BCP by the server, and in the login command to inform 
> the server of the support of the BCP by the client. Between the two 
> options, I prefer the use of the <extURI>. The questions for the 
> working group include:
> 
> 
>  1. Is signaling needed in EPP for the implementation of BCPs?

I think so.

>  2. If signaling is needed:    1. Will the existing signaling mechanism 
> in EPP with the greeting and login services meet the purpose?

There is currently no other option.
Contrary to TLS handshake for example where each part is able to offer
details on its capabilities before deciding to pursue the exchange or not,
in EPP the client has to accept what the server says, or do nothing.

>    2. Of the two service URIs <objURI> and <extURI>, which is the 
> preferred URI to use?

extURI is the only one matching semantically.
RFC 5730 says:
" One or more <objURI> elements that contain namespace URIs
         representing the objects that the server is capable of
         managing. "


If the namespace URI is not about an object, then it shouldn't be
an objURI.

>    3. What URI scheme should be used? 
> i. One proposal is to include bcp in the namespace, such as 
> “urn:ietf:params:xml:ns:epp:bcp:secure-authinfo-transfer-<version>” and 
> “urn:ietf:params:xml:ns:epp:bcp:unhandled-namespaces-<version>”. The 
> <version> would be updated based on material updates to the BCP draft 
> and bumped to 1.0 after WGLC. 

I am not sure of what I think, but I am not immediately a huge fan of 
putting bcp in the namespace. I do not know if there are other examples
in other working group/the IETF, but the main problem I see is that
BCPs can change during time, and you won't be able to change the namespace
once it has this in its name.

-- 
  Patrick Mevzek
  [e-mail]