Hi, Inline 2 comments on problem to solve and query params vs. headers.
On Mon, Nov 18, 2024 at 1:14 PM Gould, James <jgo...@verisign.com <mailto:jgo...@verisign.com>> wrote:2. In section 1, the sentence on RDAP conformance values is misleading. I propose: OLD: The RDAP Conformance values are identifiers with no standard mechanism to support structured, machine-parseable version signaling by the server. NEW: The RDAP Conformance values are identifiers that are by default opaque in nature. [JG] I believe it's important to leave this sentence as is. The language is based on the chairs proposal on slide 6 ofhttps://secure-web.cisco.com/1koiI5WyX_hZHcVm3IdqFWND-OqAVTD7peEsW4eAJ1P1v0eo-dDA7OVmhmvUS1UWMrmaxWoBs6AoPn9x2FgeEyWfVg-XI_hnWExm6Y7CVkeyIFk4P-GPCTYBiOUB1EvpvlWtDzmUokeQJ7pBiel93RCZAAWQ59fj2OjmpB_WRgBMj084nzJKlWIYl0qr4278dulNIV0NMWQQ4wA6FH4VFPXlRSnXFiwjRbqj-aM9_RUD4wt0MK_RhY7eGERSkU14rts6-yHNRs_9IgX0ext2VhzgCyUpT3DGY6k4cI3fCo-w/https%3A%2F%2Fdatatracker.ietf.org%2Fmeeting%2F114%2Fmaterials%2Fslides-114-regext-rdap-extension-identifier-and-rdapconformance <https://secure-web.cisco.com/1koiI5WyX_hZHcVm3IdqFWND-OqAVTD7peEsW4eAJ1P1v0eo-dDA7OVmhmvUS1UWMrmaxWoBs6AoPn9x2FgeEyWfVg-XI_hnWExm6Y7CVkeyIFk4P-GPCTYBiOUB1EvpvlWtDzmUokeQJ7pBiel93RCZAAWQ59fj2OjmpB_WRgBMj084nzJKlWIYl0qr4278dulNIV0NMWQQ4wA6FH4VFPXlRSnXFiwjRbqj-aM9_RUD4wt0MK_RhY7eGERSkU14rts6-yHNRs_9IgX0ext2VhzgCyUpT3DGY6k4cI3fCo-w/https%3A%2F%2Fdatatracker.ietf.org%2Fmeeting%2F114%2Fmaterials%2Fslides-114-regext-rdap-extension-identifier-and-rdapconformance>, where "explicit support for version is not an integral part of the extension mechanism" and "Certainly, you can choose to include version inside the specification for your extensions, but in the context of the base protocol an extension is either supported or its not, and when supported it simply means there is a shared understanding of what is to be done between the client and server". We need to clear the issue the versioning extension is addressing, which is to provide support for a structured, machine-parseable version signal.I don't see the connection between your text and those slides. But your text does not accurately describe the issue. rdapConformance is a JSON array of JSON strings, where each string contains an extension identifier. That array and those strings are machine parsable and it is easy for a client to distinguish one string from another. There is no structure to the value of those strings making them opaque, but a client can certainly distinguish one from another meaning a client can know the difference between "foo0" and "foo99". [JG2] - You are correct that a client can parse the extension identifiers in the rdapConformance, but there is no structured, machine-parseable version signal in the extension identifier values. The chairs proposal supported that versioning is not an integral part of the extension mechanism, which is what the versioning extension is looking to solve. Versioning is not explicitly signaled via the rdapConformance, so we need to be clear about the purpose of the versioning extension.
[PK] The only problem that we are solving is the situation where a server would implement a new version of an extension which is not known to the client but compatible with the version supported by the client.
Without versioning signal - the client will see "foo99" and would not be able to tell that it is a new back-compatible version of "foo0" which it understands.
In any other case there is no difference.If "foo0" and "foo99" are incompatible - the client would need to abort - no matter if versioning information is available or not. It can tell it also based on rdapConformance.
If the client supports both "foo0" and "foo99" then it also does not matter. The client knows the logic behind and the relation of the 2 extension version.
[JG] I don’t agree with including a preference between the two methods. The extension supports both with a requirement for the server to implement both and the client to choose what best meets their requirements. I don’t believe the versioning extension should replicate the reason for the X-Media extension considering that the X-Media extension is a normative reference.Are you saying client implementers should not be given notice that one of these methods has potential problems? And shouldn't the one with problems be depreffed in favor of the other? [JG2] The X-Media extension is a normative reference, so client implementers should be fully aware of what is described in there. I don't believe there is any need to provide a preference for one of the options. There is plenty of use of the query parameters in RDAP. The clients will be made aware of the negatives of query parameters in the extensions draft and the X-Media drafts, which are both normative references in the versioning draft.
[PK] We are discussing in other thread about downsides of forwarding or not (unknown) query parameters. The fact how the servers behave today (not adding maybe needed parameters) is a self-made problem of Section 4.3 of [RFC7480] which we have a chance to fix in Extensions draft, which should be out before this one and before X-Media. If this is fixed X-Media and query parameters will have the same properties.
Just on a side note, also HTTP Headers pose the same information leakage risk as query parameters, if forwarded. If client implementations do it behind the scenes then it may be even more dangerous. Hopefully no sane implementation would forward Authorization header but my quick research tells there is no normative document telling that rather just an implementation practice which only applies to this one header.
Kind Regards, Pawel
smime.p7s
Description: S/MIME Cryptographic Signature
_______________________________________________ regext mailing list -- regext@ietf.org To unsubscribe send an email to regext-le...@ietf.org
