Re: [regext] DOODLE: select your documents

[Gould, James]

I don't view the need for the concrete report formats to be defined as 
standards track RFCs, but instead define an IANA registry for the report 
formats (e.g., common and optionally proprietary) based on a set of underlying 
RFCs (format and report interfaces(s)).  This is similar to what has been done 
with the EPP Extensions registry.  

I'm looking to make the Data Set File Format draft (draft-gould-regext-dataset) 
more generic to support the definition of an extensible set of CSV files, 
including initially bulk operations (current format supported) and reports.  
The goal for reports is to have a separate definition file (.dsf file based on 
draft-gould-regext-dataset) per CSV report that provides the meta-data about 
the report (type, sub-type, date or date-range, duration, data scope, client / 
registrar, etc.), the report file name, report file checksum, and a formal 
definition of the fields and separator(s).  In this case, we leave the 
meta-data out of the file names, we can support the definition of the existing 
reports, and define an IANA registry for the registration of the report formats 
(common and proprietary).  A report consumer can look for all .dsf files for 
processing and leverage the meta-data and the format definition in the .dsf 
files to automate the consumption of the reports.  With the large number and 
variety of registrar reports, I believe the best strategy is to come up with an 
approach that helps define what exists today, that can be leveraged for 
consumption automation, and that supports a lighter-weight mechanism for 
defining and registering the reports formats (common and optionally 
proprietary).   

  
—
 
JG



James Gould
Distinguished Engineer
jgo...@verisign.com

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

Verisign.com  

On 1/3/19, 6:01 AM, "regext on behalf of Tobias Sattler" 
 wrote:

Just to round things up ;-)

We had talked to the registries about our proposals from the beginning. It 
quickly became clear that they would never implement anything that was not RFC. 
Which is why we had to make these submissions at all. It would be a real feat 
to say now that these are still drafts that are not being implemented and, on 
the other hand, to reject standardization.

Anyway, we will see. Just drop a note if we should pursue another way - I 
am okay with that, too.

Cheers,
Tobias

> On 3. Jan 2019, at 11:39, Alexander Mayrhofer 
 wrote:
> 
> Hello Tobias,
> 
> trying to settle that with a few last words: 
> 
>> I think we're more or less on the same page.
> 
> [AM] Good to hear. I do agree that we have the same goal, only our paths 
differ :)
> 
>> Just so we don't misunderstand each other: It's not that we or I don't
>> appreciate the work on policies or even want to deliberately avoid them.
> 
> [AM] I'm with you that some things (such as file formats) are not (much) 
related to policy, and can be agreed on the "more practical" layers.
> 
>> However, they essentially refer to framework conditions only and not to
>> explicit technical implementations. Btw. I don’t think it would be a 
great idea
>> to create ICANN policies on how things have to be technical implemented 
in
>> every detail. But you never know what's to come.
> 
> [AM] I do definitely agree. Policies should cover the high level 
requirements. Implementations are a different story, and happen on a different 
"layer".
> 
>> Of course, as a registrar you could also take the view that you are king 
as a
>> customer. However, it is far from my intention to make demands based on a
>> possible market position. That's not a good style. This is why the way 
via
>> standardisation should be in the common interest, especially since all 
parties
>> can participate in it.
> 
> [AM] As i said, i do believe that if something is good, it will succeed 
naturally. Technical specifications can, of course, never overcome market 
considerations or practical considerations (such as available resources, or 
cost vs. effort considerations). No matter if they're an RFC or any other kind 
of specification. But that goes beyond the discussion on here.
> 
>> Be that as it may, I think we could live without IETF standardization, 
but
>> conversely it would not be fair if this were interpreted against us and 
an
>> implementation will only rejected by registries because our proposals 
are not
>> RFC’s. Funny enough that some registries are working with us on these 
drafts
>> and are not implementing them yet due to the non-standardization.
> 
> [AM] Maybe that's because now that's an internet draft (rather than an 
specification from somewhere else) the following text from RFC2026, page 7 
applies?
> 
>  
>  * 

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

[Gould, James]

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
jgo...@verisign.com

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

Verisign.com  

On 1/6/19, 11:02 PM, "regext on behalf of Patrick Mevzek" 
 wrote:

Hello James and Martin,

While implementing this specification, the following occured to me:

§3 says:
   :  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  node as such:
A  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:


...


urn:X not in login services



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  is 
supposed to be human-readable message and as such should not convey a format 
for machine readable content.

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

In fact, reading above in RFC5730 yields:
A  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"  (outside of ) is defined slightly 
differently
because it is:
Zero or more OPTIONAL  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  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...

JG - I agree that RFC5730 defines the use of the  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  element in 
the response, but the use of the  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.  

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.

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-casanov

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

[Martin Casanova]

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

/ /

On 07.01.19 15:33, Gould, James wrote:
> 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
> jgo...@verisign.com
>
> 703-948-3271
> 12061 Bluemont Way
> Reston, VA 20190
>
> Verisign.com  
>
> On 1/6/19, 11:02 PM, "regext on behalf of Patrick Mevzek" 
>  wrote:
>
> Hello James and Martin,
> 
> While implementing this specification, the following occured to me:
> 
> §3 says:
>:  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  node as such:
> A  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:
> 
> 
> ...
> 
> 
> urn:X not in login services
> 
> 
> 
> 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  is 
> supposed to be human-readable message and as such should not convey a format 
> for machine readable content.
>
> 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).  
> 
> In fact, reading above in RFC5730 yields:
> A  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"  (outside of ) is defined slightly 
> differently
> because it is:
> Zero or more