[regext] draft-ietf-regext-epp-fees-02.txt: currency error handling, command wildcard

[Thomas Corte]

Hello,

I've noticed two more issues with the latest EPP fee extensions draft,
detailed below.

Generally, I wonder if this mailing list is the right place to report
such issues. Should I rather contact the authors directly, or is there a
bug tracker set up for this purpose?


Issues:

1) There seem to be contradictory requirements regarding the handling of
invalid currency codes. In section 3.2, the draft says:

  "Servers SHOULD NOT perform a currency conversion if a client uses an
   incorrect currency code.  Servers SHOULD return a 2004 "Parameter
   value range" error instead."

However, in 5.1.1, it says:

 "An OPTIONAL  element.  If the server does not
  support  value, it MUST return a 2306 error
  response;"

Further below, the draft offers a third option:

  "The  element also has an OPTIONAL "avail" attribute
   which is a boolean.  If the value of this attribute evaluates to
   false, this indicates that the server cannot calculate the relevant
   fees, because the object, command, currency, period or class is
   invalid according to server policy."

So this would indicate that an invalid currency in a  should
not result in an EPP error at all, but merely cause a non-available fee
check result (an option which I would prefer).

I believe this requires some unification, or clarification as to when to
use which code (in the responses to transform commands at least), or when
to use avail="false".


2) In the description for the  response, the draft says:

 "If a  element in the client command contains no
   element the server SHOULD return a 
  element for each server billable transaction combination of the
  ."

However, such a case cannot occur since the definition of the
"objectCheckType" complex type currently requires at least one
 element (minOccurs is not set and defaults to 1).
This should be changed in the schema so that the intended "command
wildcard" option becomes available.

Best regards,

Thomas

-- 
TANGO REGISTRY SERVICES® is a product of:
Knipp Medien und Kommunikation GmbH
Technologiepark Phone: +49 231 9703-222
Martin-Schmeisser-Weg 9   Fax: +49 231 9703-200
D-44227 Dortmund   E-Mail: supp...@tango-rs.com
Germany

___
regext mailing list
regext@ietf.org
https://www.ietf.org/mailman/listinfo/regext

Re: [regext] draft-ietf-regext-epp-fees-02.txt: currency error handling, command wildcard

[Alexander Mayrhofer]

Hello Thomas,

> Generally, I wonder if this mailing list is the right place to report
> such issues. Should I rather contact the authors directly, or is there a
> bug tracker set up for this purpose?

(Disclaimer: I'm not a WG chair, personal opinion)

Generally, yes, as the document is a working group item, i would say the 
mailing list is the right place to send comments for the draft. The IETF works 
in an open manner, so sending out comments to the group instead to the authors 
directly is preferred. 

While there is actually a Tracker supplied for IETF working groups and 
documents on http://tools.ietf.org/, it's not being used in all groups. As you 
might have seen, we will have a dedicated "working session" on this (and other) 
documents next week, where we try to resolve all the issues received. We might 
decide at that meeting that we use the tracker.

So, summary - yes, please send the issues to the list.

best,
Alex

___
regext mailing list
regext@ietf.org
https://www.ietf.org/mailman/listinfo/regext

Re: [regext] RDAP questions

[Bernhard Reutner-Fischer]

Hi!

3) missing normative reference to IANA, "RDAP JSON Values" ?

https://tools.ietf.org/html/rfc7483#section-10.2.2
mentions
---8<---
... have been registered in the "RDAP JSON Values"
   registry:
---8<---

But there is no reference (rendered?) to rdap-json-values in
https://tools.ietf.org/html/rfc7483#section-14.1

where i would have expected to find something like:
   [rdap-json-values]
  IANA, "RDAP JSON Values",
  .

I do not know where the source for the rfc is so cannot say if this is
an omission or a rendering-bug.

https://tools.ietf.org/html/rfc7480#section-8.1
might have the same problem

At first glance this omission makes it unclear if a compliant server
should emit an extension entry in the 'rdapConformance' array when
using values defined in rfc8056

thanks,

___
regext mailing list
regext@ietf.org
https://www.ietf.org/mailman/listinfo/regext