[regext] Review of draft-ietf-regext-rdap-extensions-04

[Pawel Kowalik]

Hi,


I took it for a more detailed review. Sorry it is quite long.


the threads I believe.

As extensions draft is the first to get through the WG doors and dependency for others If responding to a particular issue, I would appreciate separate email threads with distinct subject if the issues are not related. This would help to follow and response Formatting and structure done with https://github.com/larseggert/ietf-reviewtool.

-------------------------------------------------------------------------------
DISCUSS
-------------------------------------------------------------------------------

Section 2.1.1, paragraph 1
>    While the RDAP extension mechanism was created to extend RDAP queries
>    and/or responses, extensions can also be used to signal server policy
>    (for example, specifying the conditions of use for existing response
>    structures).  Extensions that are primarily about signaling server
>    policy are often called "profiles".


For a profile extension it is needed to define what is it supposed to do.
Here some initial list of what such list might consist of:
- mark some specific extensions (and versions thereof) as required
- mark some specific optional fields/url segments/object classes as required

etc.)

increases technical interoperability.
Interesting aspect is, whether a profile may be an alias for a certain

would define it requires extension foo to be supported and included in the

property if a list of extensions (and their versoins) defined in a profile
would be long.
Finally it would be worth mentioning if it's either/or between profile
extensions and regular extensions or it is OK for a regular extension
to define profile as well (with all the properties explained above).

Section 2.4.3, paragraph 3
>    It is RECOMMENDED that object class names comprise lowercase ASCII
>    characters, and that the "_" (underscore) character be used as a word
>    separator.  Though "objectClassName" is a string and [RFC9083] does
>    define one object class name with a space separator (i.e. "ip
>    network"), usage of the space character or any other character that
>    requires URL-encoding is NOT RECOMMENDED.  When object class names
>    are also used in URLs, extensions MUST specify that the names are to
>    be URL-encoded as defined in [RFC3986] if the object class names
>    contain any characters requiring URL-encoding.


I don't think we need such recommendation.
First: why only lowercase with underscore? There does not seem to be any

of underscore being a separator between extension identifier and name,
usage of underscore in name itself is even counterproductive.
Actually if the extension indentifier would contain underscore
and the name would contain underscore and the separator will also be
underscore it will be impossible to figure out which part is which.
Second: mandating extensions to say something already defined by http
(URL-encoding of path segments) on one side not needed on the other side

it. It is not required in JSON values for example
(or in other words JSON defines its own encoding for certain characters).

Section 2.4.4, paragraph 1
>    As described in [RFC9082] and Section 2.3, an extension may define
>    new paths in URLs.  If the extension describes the behavior of an
>    RDAP query using the path to return a new RDAP search result, the
>    JSON name of the search result MUST be prepended with the extension
>    identifier (to avoid collision with search results defined in other
>    extensions).  If the search result contains object class instances


I think this requirement is harmful for the protocol. Let's say I want to

Let's call it fuzzySearch. I would define a new query parameter "fuzzy"
and append it to a path segment according to the object class I would like
to search through. So if I query /domains?fuzzy=foo I expect as a client

JSON element rather than special handling for fuz_domainSearchResults.

Section 2.5, paragraph 2
>    RDAP extensions not defined by the IETF MUST use the extension
>    identifier as a prefix in accordance with this document, [RFC7480],


I'm not very much convinced if this requirement is practical.

scrutiny of IETF review and change control?
2. what about a general purpose extension which won't get defined by IETF
and would like to approach it later?
3. would it not be just enough to have a proper review on IANA level when
identifiers are being registered to assure no general terms are being
overloaded by a specifix extension or no conflicts between the extensions?

Section 3.1, paragraph 1
>    account for transfers of resources between RIRs.  Section 4.3 of
>    [RFC7480] instructs servers to ignore unknown query parameters.  As
>    it relates to issuing URLs for redirects, servers MUST NOT blindly
>    copy query parameters from a request to a redirect URL as query
>    parameters may contain sensitive information, such as security
>    credentials, not relevant to the target server of the URL.  Following


The issue with this recommendation is that "unknown query paramater" is also
 undefined. I think there is a difference between unknown and unsupported

 extension.

or prefixed with register extension identifiers would be safe to forward
unless the nature of the parameter is either confidential or only related
to the context of the origin server. An example for the latter could be

extension identifiers would specify if they are safe to be forwarded with
redirect. This would also solve the issue with versioning eventualy.


Section 3.1, paragraph 0
>    the advice in [RFC7480], servers SHOULD only place query parameters
>    in redirect URLs when it is known by the origin server (the server
>    issuing the redirect) that the target server (the server referenced
>    by the redirect) can process the query parameter and the contents of
>    the query parameter are appropriate to be received by the target.


As far as this may seem to be a valid recommendation I'm having hard time
to see how it would be practically implementible if the target of a redirect
is an RDAP server in other authority domain. Does it mean that the origin
server would have to negotiate between what the client requested
and what the target server can support in terms of extensions etc. in order
to generate a valid request with the query parameters that the server can
process?
Or, as consequence of 7480 4.3 shall we assume that the target server
MUST ignore any unknown parameter so it is safe to assume that any parameter
can be actually safely forwarded, even if related to unsupported extension?

Section 4.3.2, paragraph 1
>    With the current extension model, an extension with a backwards-
>    incompatible change is indistinguishable from a new, unrelated
>    extension.  Implementers of such changes should consider the
>    following:


This might be true for now, but with the versioning (see my comment to 4.3)
it won't be true in all cases. Assuming Semantic Versioning there might
be a major version of same extension which per definition would be
backwards incompatible.

Section 5, paragraph 9
>    Client authors should be aware that responses that make use of these
>    extensions may require special handling on the part of the client.
>    Also, while these extensions will be retained in the registry, future
>    extensions that are similarly non-compliant will not be registered.



platformNS_level_0 and regType_level_0? It could be done with this draft as
IANA action. The registry seems to be fully additive, so no risk of this
getting out of sync.

band?

-------------------------------------------------------------------------------
COMMENT
-------------------------------------------------------------------------------

Section 2.1, paragraph 2
>    When in use in RDAP, extension identifiers are prepended to URL path
>    segments, URL query parameters, and JSON object member names (herein



usage of extension identifiers in query paramaters is undefined.

Section 2.1, paragraph 2
>    The main purpose of the extension identifier is to act as a
>    namespace, preventing collisions between elements from different
>    extensions.  Additionally, implementers and operators can use the


Checking through 7480, 9082 and 9083 it does not really have a notion
of namespace. The purpose of registered extension identifier is to avoid
conflicts between extensions (and also with protocol core)
by either reserving names (bare identifiers) or prefixes, which can be used
as namespace reservation.

Section 2.1.1, paragraph 1
>    Some extensions exist to denote the usage of values placed into an
>    IANA registry, such as the IANA RDAP registries, or the usage of
>    extensions for specifications used in RDAP responses, such as
>    extended vCard/jCard properties.  Such extensions exist to "mark"
>    these usages and are often called "marker" extensions.


Do we really need 2 terms here? profile and marker seem to me very similar
in nature of what they are doing. There is also no reference to any of those
terms in any other place of the document, so this difference does not seem
to matter.

Section 2.1.2, paragraph 1
>    Extension specifications have customarily defined only one extension
>    identifier.  However, there is no explicit limit on the number of
>    extension identifiers that may be defined in a single extension
>    specification.  The main reason for defining multiple identifiers is
>    to reserve multiple namespaces in URLs or responses: see e.g.
>    [I-D.ietf-regext-rdap-rir-search].


Is it good or bad? Do we need some normative SHOULD/SHOULD NOT to tell more

Shall the draft doing it explain why it is required?

Section 2.2, paragraph 3
>    RDAP extensions MUST NOT define an extension identifier that when
>    prepended to an underscore character may collide with an existing
>    extension identifier.  For example, if there were a pre-existing
>    identifier of "foo_bar", another extension could not define the
>    identifier "foo".  Likewise, if there were a pre-existing identifier
>    of "foo_bar", another extension could not define the identifier
>    "foo_bar_buzz".  However, an extension could define "foo" if there
>    were a pre-existing definition of "foobar", and vice versa.


The normative part needs to be revised. The second example would not match
the given MUST NOT. "foo_bar_buzz" prepended to an underscore would render

way.
So it needs to be also forbidden for an extension identifier to collide with
any existing extension identifier suffixed with an underscore.
The term "collide" is also undefined. In my interpretation it means that
it is a substring match in the beginning of a string, correct?

Section 2.2, paragraph 4
>    [RFC7480] does not explicitly state that extension identifiers are
>    case-sensitive.  This document updates the formulation in [RFC7480]
>    to explicitly note that extension identifiers are case-sensitive, and
>    extension identifiers MUST NOT be registered where a new identifier
>    is a mixed-case version of an existing identifier.  For example, if
>    "lunarNIC" is already registered as an identifier, a new registration
>    with "lunarNic" (note the lowercase if "ic" in "Nic") would not be
>    allowed.


In the first reading of it, it seems inconsistent why one would want to
have case-sensitive handling and on the other side forbid registering
case-insensitive variants.

and if yes state it here.
Then forbidding registration of case-insensitive variants would only

any technical rationale. Technical systems deal with it pretty well to make
a difference and none of the places where extension identifiers are used

nature.

like re-thinking the naming strategy of the same extension from lunarNIC to
lunarNic? Then maybe worth softening MUST NOT to SHOULD NOT?

Section 2.3.2, paragraph 4
>    not required.  In this situation, the URL path operates as a
>    namespace for the query parameters, so there is no risk of collision
>    with parameters defined elsewhere.


There is a potential of collision with a scopeless paramater of another
existing or future extension. Say an extension would define a local search

I don't think there is a good way preventing that from happening other than

bad). Maybe a suggestion to register such identifiers in case very generic
terms are used?

Section 2.4.5, paragraph 1
> 2.4.5.  Bare Extension Identifiers
>
>    Some RDAP extensions define only one JSON value and do not prefix it
>    with their RDAP extension identifier, instead using the extension
>    identifier as the JSON name for that JSON value.  That is, the
>    extension identifier is used "bare" and not appended with an
>    underscore character and subsequent names.


I fully support defining and allowing Bare Extension Identifiers.
For document readibility it would be better to define both Bare Extension
Identifiers and Extension Prefixed Identifiers (a name I just minced)
as terms somewhere after defining the syntax in 2.2.
All the sections between 2.2 and this point do not have a notion of
Bare Extension Identifiers - not in text or examples. The reader has
an impression that prefixing with extension identifier and appending a name
to it is the only allowed method.

Section 2.4.5, paragraph 3
>    Usage of a bare extension identifier contravenes the guidance in
>    [RFC9083].  This document updates [RFC9083] to explicitly allow this
>    pattern.


If we are updating RFC9083 I would expect more normative text,
which would tell which normative text of RFC9083 is void and what is
the replacement.

Section 2.4.5, paragraph 3
>    Along similar lines, an extension may define a single new object
>    class, and use the extension's identifier as the object class name.


This is too vague and as it also belongs to updates of RFC9083 I would
expect a very specific normative text.

Section 2.4.7, paragraph 1
>    The styling convention used in [RFC9083] for JSON names is often
>    called "camel casing", in reference to the hump of a camel.  In this
>    style, the first letter of every word, except the first word,
>    composing a name is capitalized.  This convention was adopted to
>    visually separate the namespace from the name, with an underscore
>    between them.  Extension authors SHOULD use camel casing for JSON
>    names defined in extensions.



this recommendation?
Also This is somehow inconsistent when 2.4.3. is actually reccomending the
opposite when it comes to object class name.

Section 2.5, paragraph 0
> 2.5.  Identifier Omission




Section 2.5, paragraph 1
>    [RFC9082], and [RFC9083].  RDAP extensions defined by the IETF SHOULD
>    use the extension identifier as a prefix or as a bare extension
>    identifier (see Section 2.4.5).  IETF-defined RDAP extensions that do
>    not follow this guidance MUST describe why it is not being followed.


I'm confused. The text in the beginning suggests it causes no harm
if tere is no prefix. Here it recommends to use the prefix addind a hurdle
if someone would like to do it.

Section 4.1, paragraph 4
>    In general, extension authors should be mindful of situations
>    requiring clients to directly handle redirects at the RDAP layer.


I think if such dependency exist the best way would be to define link

needed to request RDAP resource from another server.
Maybe even structured redirect information would be needed, where server,

the client to digest it from the URL.
This would be a bigger change by defining all rdap specific web link types.

Section 4.2, paragraph 3
>    Extensions MUST explicitly define any required behavioral changes to
>    the processing of referrals.  If an extension does not make any
>    provision in this respect, clients MUST assume the information
>    provided by referrals requires no additional processing or
>    modification to use in the dereferencing of the referral.



the link target.
An alternative scenario would be if media type application/rdap+json
is an indicator of RDAP resources and in this case the responsibility
shall be put on client to construct a valid RDAP request compatible with
the target server and client's capabilities. In this case one would need
to define this default processing expected from the client.

Section 4.3, paragraph 2
>    If a future RFC defines a versioning scheme, an RDAP extension
>    definition MUST explicitly denote its compliance with that scheme.


I think this one must be more specific. "Future RFC" is vague enough
as missing the reference point. Future to the reader is not the same

Also here we need to be specific what kind of RFC. That the RFC must be RDAP
related is kind of implicit. But then, would it mean it has to be a core

only one?
Is this point meant to make versioning obligatory for all extensions?

Section 4.4, paragraph 3
>    2.  Normative references, i.e. references to materials that are
>        required for the interoperability of the extension, should be
>        stable and non-changing.


Isn't this what rfc3967 actually defines, so basically stating the obvious?
For extensions defined by RFC this requirement seems to be not needed.
For others I would reverse this sentence that the specification
shall use normative references as per rfc3967 whereever it is required

Section 4.4, paragraph 2
>    3.  Extension specifications should strongly consider making the use
>        of HTTPS with RDAP mandatory if appropriate.


rfc7480 Section 7 mandates https supported by the server.

I would suggest to rephrase this part to say: Extension specifications
SHOULD be very clear whether RDAP requests and responses related to the
extension can be exchanged over an unencrypted http connection.

if unencrypted http data exchange would pose security or privacy risks.
But maybe a reference to rfc7481 is just enough.

Section 5, paragraph 9
>    To avoid any confusion with the operation of the existing entries, an
>    extension registration that attempts to use one of the RDAP
>    conformance values given in this section as an extension identifier
>    (and so as an RDAP conformance value also) will be rejected.


This one looks like not normative, for sure not for IANA.
This exclusion list should be then included in the IANA considerations
which in fact would have the same effect as registering these names
as mentioned above.

-------------------------------------------------------------------------------
NIT
-------------------------------------------------------------------------------

Section 1, paragraph 1
-    The Registration Data Access Protocol (RDAP) defines a uniform means
-                                                         --

Section 2.3.2, paragraph 4
-    When an RDAP extension defines query parameters to be used with a URL

+                                                    +++++

Section 4.3, paragraph 1
>    As stated in Section 2.1, RDAP extensions are opaque, and they


It's not extensions which are opaque, but the identifiers.

conformance strings are opaque, ...

Kind Regards,

Pawel

- limit value space of specific fields (for example enumeration of values or a pattern for a text field, narrowed down enum, value range for numeric fields I would also not mention "server policy" as in the end such profile puts down certain technical requirements on a server which a client can rely on. So it configuration of extensions when doing requiests. So for example if profile1 answer, then would it be enough for the client to request profile1 and be sure that extension foo is always included in the response? It may be an interesting explanation. URL path segments are case-sensitive. Especially with the notion even harmful in the current version. Here it does not tell where to URL-encode create extension "fuz" that would offer a new way of searching through objects. to still be able to process the response as per rfc7483 from domainSearchResults 1. what about the specifications, which are work in progress and not yet under  paramaters. A paramater included in the RDAP Extensions Registry may be known  to server and still can be unsupported if the server does not implement given Following this line all parameters which are registered extension identifiers page/sort/cursor from the rfc8977. It would be even better if registration of How about registering missing identifiers fred_version_0, artRecord_level_0, Or can RFC mandate IANA to take this action with the original requesters off "are prepended" seems to exclude bare identifiers. Also as stipulated in 2.3.2. when this is a good thing to do and when the extension would rather not do it? "foo_bar_buzz_" which does not stay in conflict with "foo_bar" in an obvious It would be good to consider if defining them case-insensitive makes any harm have a meaning of avoidance of potential miscommunication, but not necessarily (JSON elements, path segments, quety paramater names) are case-insensitive in And if only human communication is concerned, the question remains why someone sane would ever try to do it. And if he tries maybe the reasons are valid ones, parameter that some other extension would define as applicable to all searches. either prefixing all parameters no matter at which level (which would also be Why is it recommended and what are the negative consequences of not following What is a practical difference between this case and a registered bare identifier in 4.5? referrals rather than redirects. The client can be very aware of the processing object class and name are broken down in explicit way rather than relying on Similar to the comment in 4.1 the same applies here. If the referral is to be treated as redirect, so that no processing of href is expected from the client, then anything in the href must fulfill the same requirements as redirect URL. In this case it is up to the server to assure compatibility of the request with as future at the time of writing and also diffrent to the time of publication. protocol update level of RFC or enough to have an extension RFC? Would there be So basically it is about effectively forbidding unencrypted HTTP in some cases. Extension specification MUST mandate use of HTTPS in its Security Considerations +    When an RDAP extension defines query parameters only to be used with a URL Suggested text: As stated in Section 2.1, RDAP extension identifiers and RDAP

OpenPGP_0xABB62115F7BCDB04.asc
Description: OpenPGP public key

OpenPGP_signature.asc
Description: OpenPGP digital signature

_______________________________________________
regext mailing list -- regext@ietf.org
To unsubscribe send an email to regext-le...@ietf.org