This ACTION REQUEST is now closed.
The Chairs see two take-aways from this working group discussion.
1. We still have support for “jscontact” and we have support for the
Experimental track. However, we don’t believe we are ready to publish yet.
2. While the concepts of signaling vs extension
Mario,
On Thu, Nov 16, 2023 at 9:28 AM Mario Loffredo
wrote:
>
>
> Also, since you (and JG) have been arguing vehemently on your
> position, did you find a technical flaw in the rdap-x draft? Have you
> found a scenario where it does not work?
>
> [ML] Am not "arguing vehemently", I'm quietly
Hi Andy,
please find my comments inline.
Il 15/11/2023 14:41, Andrew Newton ha scritto:
Mario (and JG),
On Wed, Nov 15, 2023 at 5:17 AM Mario Loffredo
wrote:
[ML] About preserving query parameters in HTTP redirection, my opinion
is that it depends on each application protocol built over
Mario (and JG),
On Wed, Nov 15, 2023 at 5:17 AM Mario Loffredo
wrote:
>
> [ML] About preserving query parameters in HTTP redirection, my opinion
> is that it depends on each application protocol built over HTTP.
>
> There are a ton of protocols on the web preserving query parameters in
>
Hi Andy,
please find my comments below.
Il 14/11/2023 14:38, Andrew Newton ha scritto:
On Tue, Nov 14, 2023 at 2:53 AM Mario Loffredo
wrote:
The technical problems with the signaling have been discussed at
length on this mailing list. A better and more generic solution has
been proposed in
Andy,
I don't believe that RDAP was designed just for redirection services, and I
simply don't understand why the redirection services can't preserve the query
parameters. Section 5.2 of RFC 7480 makes no mention of query parameters and
states that the server "is to hand back a complete URL",
On Tue, Nov 14, 2023 at 3:00 PM Marc Blanchet wrote:
>
> The fact that some people are willing to provide services in addition to the
> standard track RFCs for bootstrapping RFC9224) does not mean that it should
> influence how we design our protocols. I have a hard time thinking that we
> are
> -Original Message-
> From: regext On Behalf Of James Galvin
> Sent: Monday, November 13, 2023 10:53 AM
> To: Registration Protocols Extensions
> Subject: [EXTERNAL] [regext] ACTION REQUESTED: split draft-ietf-regext-
> rdap-jscontact
>
> Caution: This email
> Le 14 nov. 2023 à 13:52, Andrew Newton a écrit :
>
> On Tue, Nov 14, 2023 at 9:02 AM Gould, James wrote:
>>
>> Andy,
>>
>> I recommend covering the use of query parameters in RDAP in the
>> draft-newton-regext-rdap-extensions, since it's unclear and deserves
>> discussion on the mailing
On Tue, Nov 14, 2023 at 9:02 AM Gould, James wrote:
>
> Andy,
>
> I recommend covering the use of query parameters in RDAP in the
> draft-newton-regext-rdap-extensions, since it's unclear and deserves
> discussion on the mailing list. I personally don' t see how the use of query
> parameters
Andy,
I recommend covering the use of query parameters in RDAP in the
draft-newton-regext-rdap-extensions, since it's unclear and deserves discussion
on the mailing list. I personally don' t see how the use of query parameters
would not be compatible in RDAP, since RDAP is simply a REST
On Tue, Nov 14, 2023 at 2:53 AM Mario Loffredo
wrote:
>
> > The technical problems with the signaling have been discussed at
> > length on this mailing list. A better and more generic solution has
> > been proposed in the rdap-x-media-type draft. We never really
> > discussed signaling during the
Hi Andy,
Il 13/11/2023 19:30, Andrew Newton ha scritto:
On Mon, Nov 13, 2023 at 12:28 PM wrote:
Hi James,
Likely I missed this part about splitting in the meeting - sorry for
that. Can you be more specific? It is the mechanism described in 4.
Transition Considerations? Shall it be only
Speaking as co-Chair and including the responses by Jim Gould and Andy Newton
under separate cover in this thread, I would say these are excellent questions
and they should be resolved by the working group as it considers how to move
forward the functionality described in Section 4.
For the
On Mon, Nov 13, 2023 at 12:28 PM wrote:
>
> Hi James,
>
> Likely I missed this part about splitting in the meeting - sorry for
> that. Can you be more specific? It is the mechanism described in 4.
> Transition Considerations? Shall it be only referring to jscontact or
> contact representation or
We also implemented the signal in section 5 of
draft-gould-regext-rdap-versioning, using the "versioning" query parameter. We
intend to make draft-gould-regext-rdap-versioning more generic to support
opaque versioning (use of extension identifier only) and semantic versioning
(extension
Hi James,
Likely I missed this part about splitting in the meeting - sorry for
that. Can you be more specific? It is the mechanism described in 4.
Transition Considerations? Shall it be only referring to jscontact or
contact representation or to any transition of output representations?
Following up from last week’s REGEXT meeting, there was consensus in the room
that the document:
https://datatracker.ietf.org/doc/draft-ietf-regext-rdap-jscontact-16/
Should be split into two documents: the signaling function and the extension.
The signaling function draft would be put on the
18 matches
Mail list logo
