Hi Andy,
please find my responses below.
Il 10/04/2023 15:32, Andrew Newton ha scritto:
Comments below.
On Fri, Apr 7, 2023 at 4:16 AM Mario Loffredo <mario.loffr...@iit.cnr.it> wrote:
Hi Andy,
Il 06/04/2023 16:36, Andrew Newton ha scritto:
On Thu, Apr 6, 2023 at 9:56 AM Mario Loffredo<mario.loffr...@iit.cnr.it> wrote:
[ML] Sorry for the delay in replying and thanks for this.
Really there are some documents under discussion that would be
eventually affected.
But I wonder where it's stated that query parameters should/must not be
preserved in redirections.
Do you refer to a generally adopted practice or to an IETF document ?
I took a look at RFC 9110 and didn't find specific statements about that.
Because unless the server issuing the redirects explicitly preserves
the query parameters in the new URL, they will not be preserved. My
quick glance of 9110 does not say that query parameters are preserved
so I don't know how a conclusion can be drawn that they are. But we
don't have to be so theoretical about it. We can just try it:
$ curl -vhttps://rdap-bootstrap.arin.net/bootstrap/autnum/2830?someparam=foo
* Trying 199.212.0.160:443...
* Connected to rdap-bootstrap.arin.net (199.212.0.160) port 443 (#0)
* ALPN, offering h2
* ALPN, offering http/1.1
* successfully set certificate verify locations:
* CAfile: /etc/ssl/cert.pem
* CApath: none
* (304) (OUT), TLS handshake, Client hello (1):
* (304) (IN), TLS handshake, Server hello (2):
* (304) (IN), TLS handshake, Unknown (8):
* (304) (IN), TLS handshake, Certificate (11):
* (304) (IN), TLS handshake, CERT verify (15):
* (304) (IN), TLS handshake, Finished (20):
* (304) (OUT), TLS handshake, Finished (20):
* SSL connection using TLSv1.3 / AEAD-AES128-GCM-SHA256
* ALPN, server did not agree to a protocol
* Server certificate:
* subject: C=US; ST=Virginia; L=Chantilly; O=American Registry for
Internet Numbers, Ltd.; CN=*.arin.net
* start date: Aug 4 00:00:00 2022 GMT
* expire date: Sep 4 23:59:59 2023 GMT
* subjectAltName: host "rdap-bootstrap.arin.net" matched cert's "*.arin.net"
* issuer: C=US; O=DigiCert Inc; CN=DigiCert TLS RSA SHA256 2020 CA1
* SSL certificate verify ok.
GET /bootstrap/autnum/2830?someparam=foo HTTP/1.1
Host: rdap-bootstrap.arin.net
User-Agent: curl/7.79.1
Accept: */*
* Mark bundle as not supporting multiuse
< HTTP/1.1 302
< Date: Thu, 06 Apr 2023 14:23:33 GMT
< Server: Apache/2.4.6 (CentOS) OpenSSL/1.0.2k-fips
< Location:https://rdap.db.ripe.net/autnum/2830
< Content-Length: 0
< Access-Control-Allow-Origin: *
<
* Connection #0 to host rdap-bootstrap.arin.net left intact
-andy
[ML] AFAIU from RFC 9110, removing the query part from the target URI is
a misinterpretation of redirection .
If the original target URI includes the query part, it should be
preserved in the new target URI similarly to the path part.
I'm not sure how such a conclusion can be made especially given
current deployment of the technology does not support it.
[ML2] For some reasons:
- it seems to me there is no syntactical constraint preventing from
including the query in URIs used in redirection. If it's allowed, why
should the query be omitted ?
- searching on the web, I found that preserving the query in
redirection depends on implementations
- some official documents, such as RFC 6749 and OpenID Connect Core,
present URIs used in redirection including query parameters
Furthermore, URI's are about identifying resources. RFC 3986 notes
this about query parameters:
"The query component contains non-hierarchical data that, along with
data in the path component (Section 3.3), serves to identify a
resource within the scope of the URI's scheme and naming authority
(if any)."
[ML2] Don't think this case is different. There are resources providing
the contact information in jCard and resources providing the contact
information in JSContact.
What would be the difference if the server allowed to request for
JSContact through an optional path segment instead of a query parameter
? (e.g. https://example.com/rdap/domain/{domain name}[/jscard])
The query parameter can be used in both lookups and searches, and
doesn't require to introduce new path segments.
Besides, the use of the jscard query parameter is preferrable as it can
be propagated to the possible related links included in the RDAP response.
Finally, some documents in discussion in this WG and already published
as RFC envisage the use of query parameters and don't see drawbacks in
keeping this way.
A redirect indicates that one resource defined by a URI can be found
by using another URI. Path and query help identify a resource and
there is no defined preservation of either.
[ML2] Think that servers should preserve the original request. If, as
you wrote, path and query contribute to identify a resource, removing
the query would alter the original request.
Anyway, if needed, rdap-jscontact could include text stating that the
jscard parameter must be preserved in redirections as well as in links.
What you want to do here is accept JSContact content instead of JCard
content. That is content negotiation, and Section 12 of RFC 9110
clearly references the usage of HTTP headers for doing that.
[ML2] Don't understand which negotiation field you refer to. Guess the
Accept header but RDAP already has its own media type.
JSContact has its own media type too but it's just for exchanging
JSContact Cards; can't be used to accept JSContact inside RDAP.
In addition, if I correctly understood RFC 7484 , the RDAP bootstrap
method consists in replacing only the base RDAP URL of the URI.
RFC 7484 is silent on the subject as the purpose is to find the
authoritative server. That said, the concept of redirect servers was
well known at the time as they are mentioned in Section 8. There was
even a draft specifically about them that never progressed
(https://datatracker.ietf.org/doc/html/draft-ietf-weirds-redirects-04).
Neither mention preservation of query parameters. Given this and
current deployments of the technology, it is unsafe to assume that
query parameter preservation is a common practice.
Also, redirects in the RDAP ecosystem can be found beyond the
bootstrapping system.
For the purposes of this draft, it is probably best to drop the query
parameters especially as they aren't needed to move the draft forward.
[ML2] Keep thinking that the jscard query parameter should be used to
accomplish the most efficient approach to the transition from jCard to
JSContact.
Obviously I'll respect the WG decision on this matter but can't disagree
about duplicating contact information and removing jCard by mandate.
Best,
Mario
-andy
--
Dott. Mario Loffredo
Technological Unit “Digital Innovation”
Institute of Informatics and Telematics (IIT)
National Research Council (CNR)
via G. Moruzzi 1, I-56124 PISA, Italy
Phone: +39.0503153497
Web: http://www.iit.cnr.it/mario.loffredo
_______________________________________________
regext mailing list
regext@ietf.org
https://www.ietf.org/mailman/listinfo/regext
