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

From: "Patrick Mevzek" <[email-masked]>
Date: Mon, 27 Apr 2020 00:07:17 -0500

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

---

From: "Gould, James" <[email-masked]>
Date: Mon, 27 Apr 2020 13:02:19 +0000

Patrick,

Thank you for your review and feedback.  I provide answers to your feedback below.

-- 
 
JG

James Gould
Fellow Engineer
[email-masked] <applewebdata://13890C55-AAE8-4BF3-A6CE-B4BA42740803/[email-masked]>

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

Verisign.com <http://verisigninc.com/>

On 4/27/20, 1:08 AM, "regext on behalf of Patrick Mevzek" <[email-masked] on behalf of [email-masked]> wrote:

    
    Rationale:

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

JG - Providing an explicit reason as defined in the draft will enable the client to monitor for an unhandled namespace.  In the Verisign EPP SDK, I was able to leverage the preformatted reason to easily pull out the namespaces that are unhandled in a utility method.  I realize that the reason is meant to be human readable, but in this case it helps the client software to monitor for unhandled namespaces.  By including the XML of the unhandled namespace in the <value> element, it provides the option for the client to record the unhandled information for later processing.  Including additional XML around the unhandled XML doesn't really help the client.  I found it extremely straight forward to filter the unhandled namespace XML for poll messages and for regular responses, and identifying the processing the unhandled namespaces in the client.  I recommend that you try creating a client utility method for unhandled namespaces in your Perl EPP SDK to see how straight forward it is.  Hopefully we can discuss your proposal at the WG meeting today.  

    I think so.

JG - Agreed

    
JG - The only other option is to create an extension to serve the purpose of BCP signaling, but I believe the use of the login and greeting services meets the need.

JG - Agreed

JG - The bcp namespace in the URI is used to put the namespace URI in an appropriate category, which in this case is for EPP BCPs.  If and when the BCP changes materially, the <version> will change in the URI.  I updated the drafts with the following IANA URI registrations:

urn:ietf:params:xml:ns:epp:bcp:unhandled-namespaces-0.1
urn:ietf:params:xml:ns:epp:bcp:secure-authinfo-transfer-0.1

If there is a material change to the drafts, the version will be bumped up to 0.2, and so forth.  Once the drafts make it past WGLC, the version will be bumped up to 1.0.  The scheme to use will be discussed during the WG meeting.   
    
    -- 
      Patrick Mevzek
      [email-masked]
    
    _______________________________________________
    regext mailing list
    [email-masked]
    https://secure-web.cisco.com/1PMmzE4sHShzbKuL_EXUWqSC_QxkcDWvlM-Tk56--L4aV_dm4ocjqrL8-a0oFf0_v9A9F6ME0GtBZgcg5_7cst45bMqG72i9lOtG2lOxm5UtGj4FhY2zscg4JMynPQApfhCCtnHJEOrsObvM5pcDgiaj0A2GulS7cQFivv3-Y-Wrw02gKYjGakpP53TwoN7Oib1AgGQ0uZUgeKfivWKwTm-tkxv3uz3cyPCMCYUJK0SbP50qfDlcWYp2OwrLKkjJGSkIcKqpJJ0IY_dsV3LoxcJqQSBtX0KZCPWDLnkek1pg/https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fregext