Hi Andy,
Thanks for putting down this draft. A method for the client to signal
supported or wanted extensions is really needed.
A remark to the Section 3: I think all cases should be covered by this
section. Currently I'm missing, the case when the server would support
more extensions than requested/understood by the client. I think it
would be good to make a recommendation for the server implementation
what is the desired behavior in such case. My suggestion is the server
SHOULD respond with no additional extensions as far as the server
capable of doing so (e.g. can render dynamic responses). It may be
relevant for the cases where the extensions define not only JSON
structures, which in general should not be an issue for the client
receiving an unsupported extension, but also define a response profile
which not necessarily have to be compatible with each other.
Another remark to the media type. RFC7480 specifies the usage of
'application/json', 'application/rdap+json' or both. Why the draft
changes the requirement to require only 'application/rdap+json'? Is this
change required to achieve the objectives of this draft?
rfc9110 defines all media types as the same preference if having the
same weight. Wouldn't it be more appropriate to indicate
'application/json' and or 'application/rdap+json' with different (lower)
weight than 'application/rdap-x+json' to indicate the clients' preference?
To the design considerations I am missing a bit whether usage of custom
http header has been considered by the authors. The usage of "Accept"
header with a new media type, where in fact the responses are of the
same media type is a bit of misuse of this header, so I understand there
are good reasons for choosing this way.
The last question to the discovery part. Shall client have a possibility
to find out support for this extension prior to a real request, for
example by OPTIONS http request? I understand this is not a real
extension, so it would not appear in RDAP conformance when requesting
/help path.
Kind Regards,
Pawel
Am 22.05.23 um 04:36 schrieb Andrew Newton:
Hi all,
Jasdip and I have put together a draft for a new RDAP media type. This
allows clients to signal their supported extensions. By using a media
type, this signaling survives redirects and is backward compatible
with the RDAP RFCs and the currently deployed RDAP ecosystem.
We even have some demo code to show how it works:
https://github.com/anewton1998/draft-regext-ext-json-media-type/tree/main/demo
-andy
---------- Forwarded message ---------
From:<internet-dra...@ietf.org>
Date: Sun, May 21, 2023 at 10:26 PM
Subject: New Version Notification for
draft-newton-regext-rdap-x-media-type-00.txt
To: Andy Newton<a...@hxr.us>, Jasdip Singh<jasd...@arin.net>
A new version of I-D, draft-newton-regext-rdap-x-media-type-00.txt
has been successfully submitted by Andy Newton and posted to the
IETF repository.
Name: draft-newton-regext-rdap-x-media-type
Revision: 00
Title: An RDAP With Extensions Media Type
Document date: 2023-05-21
Group: Individual Submission
Pages: 10
URL:
https://www.ietf.org/archive/id/draft-newton-regext-rdap-x-media-type-00.txt
Status:
https://datatracker.ietf.org/doc/draft-newton-regext-rdap-x-media-type/
Html:
https://www.ietf.org/archive/id/draft-newton-regext-rdap-x-media-type-00.html
Htmlized:
https://datatracker.ietf.org/doc/html/draft-newton-regext-rdap-x-media-type
Abstract:
This document defines a media type for RDAP that can be used to
describe RDAP content with RDAP extensions. Additionally, this
document describes the usage of this media type with RDAP.
The IETF Secretariat
_______________________________________________
regext mailing list
regext@ietf.org
https://www.ietf.org/mailman/listinfo/regext
_______________________________________________
regext mailing list
regext@ietf.org
https://www.ietf.org/mailman/listinfo/regext
