Re: [regext] Poll messages with unhandled namespaces (was Re: I-D Action: draft-ietf-regext-change-poll-07.txt)

["Gould, James" <[e-mail]>]

Patrick,

Yes, I believe the idea that Martin came up with to use the <extValue> element with the inclusion of the full unhandled XML block is the best option thus far.  It honors the client login services, it includes all of the XML for later processing, and it does not cause XML parsing failures or marshaling failures.  I implemented each of the discussed approaches using a stub server and a validating client, and this approach works best in my opinion.   
  
—
 
JG



James Gould
Distinguished Engineer
[e-mail]

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

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

On 7/16/18, 12:20 AM, "regext on behalf of Patrick Mevzek" <[e-mail] on behalf of [e-mail]> wrote:

    On Thu, Jun 14, 2018, at 16:04, Gould, James wrote:
    > This approach looks good to me.  It has the advantage of providing the 
    > unhandled information in an element that is meant for machine processing 
    > instead of using the <msgQ><msg> element that’s meant is meant to be 
    > human readable.  The other advantage is that the contents of the <value> 
    > element is not processed by the XML parser (e.g., 
    > processContents=”skip”), meaning it would not cause an XML parser error.
    > 
    > This approach could include the entire unhandled extension block without 
    > causing client-side parsing or unmarshalling issues.
    
    This "could" should be a "must", otherwise a registrar has no way to just download the message for later consumption without having the need to login will all possible extensions. 
    
    Again please take into account this example that exists today:
    some registries restrict the extensions can be used on login, because some may be related to specific accredition, like secdns.
    So some registrars may not even be able to put some extensions there, but may get notifications with messages using these exceptions, as they do not control what kind of messages they get and some may appear due to actions from other parties, like other registrars or the registry itself.
    
    But like I said all of this still quite bends the RFC5730 spirit I think where value/extValue should be mostly for errors and value should reference a client provided element, which is not the case in these examples.
    
    This latest idea from Martin and you is probably the best one we discussed about as of yet, and if I could get convinced to add myself on the consensus for it, I am still uneasy by how it uses RFC5730 structures.
    
    -- 
      Patrick Mevzek
      [e-mail]
    
    _______________________________________________
    regext mailing list
    [e-mail]
    https://www.ietf.org/mailman/listinfo/regext