Hi Julien,
Answer embedded.
Am 16.01.23 um 20:33 schrieb Julien Bernard:
- section 4.1
I'm not that familiar with OIDC and that's might be the issue but I
don't really understand the need for
additionalAuthorizationQueryParams. Is there a way to clarify this or
a reference that would help?
tocol.
Let's wait for a response and then we'll be able to make a definitive
proposal about this matter.
Meantime, thanks everyone who has joined the discussion thus far.
Best,
Mario
Il 16/01/2023 23:33, Marc Blanchet ha scritto:
Le 16 janv. 2023 à 16:18, Pawel Kowalik a é
Hi,
Am 26.01.23 um 20:33 schrieb Jasdip Singh:
[SAH] Thanks for the feedback, Mario. I still don't think this is a good idea,
but if mine is a minority opinion I'll update the text to remove the MUST and
include config info so a server can describe the type(s) of clients it
supports. Please folk
Hi Scott,
It looks good, I have few minor points:
1. The new paragraph in Section 3 uses a term "bearer token". I suggest
to use "Access Token" as a defined term (same in 6.2).
Also the "session" in this case can go beyond the lifespan of the Access
Token if token refresh is possible.
2. I
Hi Scott,
Feedback inline.
Am 02.02.23 um 13:56 schrieb Hollenbeck, Scott:
Also the "session" in this case can go beyond the lifespan of the Access Token
if
token refresh is possible.
[SAH] Yes, the concept of the session is directly related to the existence and
validity of an Access Token,
+1
Am 20.03.23 um 14:40 schrieb James Galvin:
The document editors have indicated that the following document is ready for
submission to the IESG to be considered for publication as a Proposed Standard:
Registration Data Access Protocol (RDAP) Reverse Search
https://datatracker.ietf.org/doc/d
+1
Am 17.04.23 um 15:27 schrieb Antoin Verschuren:
The document editors have indicated that the following document is ready for
submission to the IESG to be considered for publication as a Proposed Standard:
Redacted Fields in the Registration Data Access Protocol (RDAP) Response
https://data
+1
I support the publication of the document.
Kind Regards,
Pawel
Am 26.06.23 um 16:02 schrieb James Galvin:
The document editors have indicated that the following document is ready for
submission to the IESG to be considered for publication as a Proposed Standard:
Federated Authentication
Hi Andy,
Just to be sure - the comments refer to
draft-newton-regext-rdap-extensions-00, not to
draft-newton-regext-rdap-x-media-type-00, right?
I just got confused as the comment are in the thread of the latter.
Kind Regards,
Pawel
Am 26.06.23 um 15:32 schrieb Gould, James:
Andy,
Thank
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 r
Hi Andrew,
Answers inline.
Am 12.07.23 um 16:12 schrieb Andrew Newton:
/help is used by humans, if at all.
-andy
If there are valid use cases, I'd like to hear them. But computing
history is full of discovery failures up and down the stack. CORBA.
UDDI. DDDS.
RDAP OpenID is one of promine
Hi Andrew,
Answers inline.
Am 12.07.23 um 15:35 schrieb Andrew Newton:
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
Hi,
> Am 17.07.2023 um 17:32 schrieb Jasdip Singh :
>
> [JS] This is a fair point, Pawel. Would you suggest considering the latter
> method (query parameters) as well, given it may not survive a redirect?
Not really. Too much hassle and complexity just to support a de facto non RDAP
client. RD
Hi,
Reading the feedback from John Klensin again, the main problem seems to
be that only 1 address does not leave any room for policy choices by all
actors in the chain (mainly registries and registrars) whether to
support a "backup" all-ASCII address or not. This is a fair point.
Now, if we
l for entity contact data using basic JSON values, objects,
and arrays. The data model defined by this document is purposefully
limited to the data in-use by Internet Number Registries and Domain
Name Registries and does not attempt to model the full data-set that
can be expressed with other
Hi,
Some comments below.
Am 31.08.23 um 19:56 schrieb Andrew Newton:
On Thu, Aug 31, 2023 at 1:05 PM Mario Loffredo
wrote:
AFAIU, the definition of a standard JSON data description language has been a
controversial matter for long. To my knowledge, the only DDL published as RFC
that could
Hi Andy,
Am 25.09.23 um 16:04 schrieb Andrew Newton:
I disagree
with wrapping name and role in the postal information as those
elements are used for non postal reasons and there are definitely
non-EPP registries that do not model this the same way.
[PK] Makes sense to me to be able to have
I copy on that. It was a topic of wider interest during the last CENTR
Tech meeting and it would be good to have a wider IETF community view on
this in terms of standards.
Kind Regards,
Pawel
Am 20.10.23 um 10:13 schrieb Maarten Wullink:
Andy,
Thank you for your kind offer to give up your a
Hi Gavin,
Am 20.10.23 um 14:23 schrieb Gavin Brown:
Hi Pawel,
On 19 Oct 2023, at 06:04, Pawel Kowalik wrote:
Hi Gavin,
Am 18.10.23 um 13:57 schrieb Gavin Brown:
Question on 2.2 element. Why is this element not OPTIONAL? What am I
overseeing by thinking it should be optional, as is with
issue to proceed let’s discuss what is the best way to
address it. I am still of an opinion that this WG is the best group of people
with the right expertise to move this topic forward.
Kind regards
Pawel Kowalik
> Am 22.03.2024 um 01:18 schrieb Maarten Wullink
> :
>
>
> RFC5
Hi,
Thank you for a valuable feedback in the session in Vancouver on Domain
Connect.
As mentioned there is a renewed draft. I would appreciate more feedback
from the working group on the content of the document itself, even if
not adopted.
https://datatracker.ietf.org/doc/draft-kowalik
is no obligation for id to match.
[1] https://datatracker.ietf.org/doc/draft-sanz-openid-dns-discovery/
[2] https://datatracker.ietf.org/doc/draft-bertola-dns-openid-pidi-architecture/
Kind Regards,
Pawel Kowalik
Expert Domain Processes and Identity
Domain Services
1&1 IONOS SE | Hinterm Hauptbahnh
Hi Scott,
Responses inline below.
> > 3.1.2. Overview
[...]
> [SAH] I'm open to specific suggestions when you say "make /session/login a
> fully interactive flow for humans, without any RESTful elements, or make it
> fully RESTful without the interactive part". However, I believe that some
>
On Tue, 12 Apr 2022 at 15:09, Hollenbeck, Scott
wrote:
>
> > -Original Message-
> > From: Pawel Kowalik
> > Sent: Tuesday, April 12, 2022 3:32 AM
> > To: Hollenbeck, Scott
> > Cc: regext@ietf.org
> > Subject: [EXTERNAL] Re: [regext] Feedback t
Hi Scott,
> [PK] sure, not insisting on dynamic registration. How do you want to
> proceed
> > with drafting the text update?
> > Do you maintain the test somewhere on github or alike where I could chip
> in
> > a proposal?
>
> [SAH] Please send proposed text to the list. I'm still doing this draf
On Mon, 25 Apr 2022 at 14:09, Hollenbeck, Scott
wrote:
> Thanks, I’ll take a look. One question, though: why keep the “id” query
> parameter? If used, we’re always going to have to do issuer discovery. It
> may be simpler to just not use that parameter.
>
>
[PK] in case "remote_iss" is specified,
> Personally, I'm not in favor of the exact match between all the
aforementioned names and in a
> previous mail I had expressed my opinion about excluding the version
information from that match.
> It seemed to me that such approach could result in better versioning the
RDAP extensions,
> especial
Hi Andrew,
On 12.02.25 15:09, Andrew Newton (andy) wrote:
On Wed, Feb 12, 2025 at 1:42 AM Pawel Kowalik wrote:
[PK] I am typically of an opinion that simple is better than complicated.
In this case however I have my concerns that even though new rules would be
defined
the specifications not
Hi,
As a preliminary work for analysis of commonly used EPP elements and
extensions we launched a TLD registry survey over CENTR and other ccTLD
organisations to get some quantifiable insights.
Just in case you are not aware of if so far, I forward it here as well,
so you may provide your in
Hi,
As extensions draft is the first to get through the WG doors and
dependency for others
I took it for a more detailed review. Sorry it is quite long.
If responding to a particular issue, I would appreciate separate email
threads
with distinct subject if the issues are not related. This wou
Hi,
Thinking of interactions between the client and server that versioning
draft assumes I think we are heading towards 2-RTT model for every request.
Step 1: The client makes an HTTP GET request to the /help endpoint of
the RDAP server.
Step 2: The response is processed to extract rdapConfo
Hi,
I am not against adopting this document on the merits of it. Especially
if there would be folks joining the WG to support its progress.
On the other hand I am concerned the WG has still a lot of WIP drafts,
which are having moderate traction. We agreed to have "Extension" draft
out of th
Hi Andy,
On 12.02.25 17:06, Andrew Newton (andy) wrote:
Allowing bare identifiers still leave the choice open for extensions which have
a potential of generic use.
Why does requiring a prefix preclude generic use?
Of course technically nothing, because syntactically a prefixed
identifier is
Hi Andy,
On 05.02.25 21:41, Andrew Newton (andy) wrote:
Hi all,
We, the author team, have posted a new version of this draft. This
reflects 22 closed issues from the tracker, and these are noted in the
draft text with an aside.
All that said, I think our efforts to do carve-outs based on exist
Hi Andy,
On 31.03.25 16:50, Andrew Newton (andy) wrote:
Hi all,
At IETF 122, Pawel brought up the lack of time to discuss the
simplification of the extension rules as outlined in the email below.
From what I can tell, the working group agrees with the simplification
of rules on writing RDAP
Hi,
After the AD decision not to proceed with the domain connect draft as
AD-sponsored the preferred way forward seems to be forming a working
group tasked with this work.
Orie asked me to propose a charter text and initiate the discussion here.
I kept the charter in a very narrow scope, so
ng guidance, would it be more productive if we held an interim
> meeting before the next IETF to focus on ironing out any disagreements,
> especially the one about bare identifiers?
>
> Jim/Antoin/Orie, please advise on this matter.
>
> Thanks,
> Jasdip
>
>
>
Hi Andy,
On 02.04.25 16:31, Andrew Newton (andy) wrote:
[...]
In fact "the rules" set in 2.1 of RFC9083 are no rules, but a
recommendation (SHOULD) itself. So I argument actually to keep the
status quo of RFC9083 as opposed to defining new rules as now the
change of -05 proposes.
I agree t
one
about bare identifiers?
Jim/Antoin/Orie, please advise on this matter.
Thanks,
Jasdip
*From:* Pawel Kowalik
*Date:* Tuesday, April 1, 2025 at 12:11 PM
*To:* Andrew Newton (andy) , regext@ietf.org
*Subject:* [regext] Re: simplifying the extensions rules
,
Pawel
On 12.02.25 18:14, kowa...@denic.de wrote:
Hi Scott,
On 12.02.25 18:06, Hollenbeck, Scott wrote:
*From:* Pawel Kowalik
*Sent:* Wednesday, February 12, 2025 11:59 AM
*To:* Andrew Newton (andy)
*Cc:* regext@ietf.org
*Subject:* [EXTERNAL] [regext] Re: I-D Action:
draft-ietf-regext-rdap
I don't think extension draft is the right place for this.
If we ever think this is an important problem so solve we should update
9083.
Kind Regards,
Pawel
On 21.05.25 21:31, Andrew (andy) Newton wrote:
Hi,
Sorry for the multiple threads, but I don't want to conflate multiple
issues.
I
+1, but I don't think extension draft is enough. It will cover only
extension identifiers, object class names, and JSON property names of
future extension. Adding it to extension draft is easy and likely not
harmful in any way though.
Much more interesting would be indeed the string values in
I would also not put too much value to prefixes. Typically the
frameworks require full name anyway to access the object or to map it to
a programming language representation.
Actually I would be in favour of restoring the text of -04 2.4.5 with an
explicit update to RFC9083 allowing the bare i
Hi Andy,
On 02.06.25 16:48, Andrew (andy) Newton wrote:
On 6/2/25 03:43, kowa...@denic.de wrote:
Hi,
[PK] I'm not happy with "technical solution cannot otherwise be
defined" as this is a condition likely impossible to fulfil or proof,
as there will be always some solution possible. This a
We may have more extensions that would want to add media type
parameters, so the problem space is the same. (Potential) conflicts
occur on the specification level, not in runtime where for all cases
(media type parameters, url path segments, JSON names, query parameters)
the server will by natu
Hi Jasdip,
On 18.06.25 19:43, Jasdip Singh wrote:
Hi Pawel,
Totally agree with being consistent prefixing-wise for query requests
and responses in RDAP extensions!
But afraid, we might be overlaying this prefixing concept on to the
media type space unnecessarily. If another RDAP extension
Hi Andy et al.,
First thanks to the editors to incorporate clearly in the draft that
there is no consensus yet on this point.
I see 3 issues with the current text that I would like to bring up.
1) Suggestive, one sided text in the alternatives
I am not fully happy that the text in the option
Hi Mario,
Thanks for this update. The use of profiles would really make use of
JSContact more feasible.
After reviewing the document I have few remarks, as indicated in today's
IETF 123 WG session:
1) Some fields in the profile seems duplicated to other fields and I am
not convinced we nee
Hi Mario,
On 24.07.25 14:24, Mario Loffredo wrote:
Hi Pawel,
please find my comments inline prefixed with [ML].
Il 22/07/2025 18:23, Pawel Kowalik ha scritto:
1) Some fields in the profile seems duplicated to other fields and I
am not convinced we need them at all:
components Name
Kowalik wrote:
- If identifiers are registered with IANA, the risk of naming
conflicts is eliminated, making prefixes for identification purposes
redundant.
- Mandatory prefixes make the protocol less readable and can lead to
awkwardly long or abbreviated identifiers, degrading the protocol&#
Hi Andy,
Verification timestamp is not bound to lifecycle of the entity object.
As results the timestamp of verification of the subject may be prior to
the creation of the object. Putting this in the events stream may be
confusing imho.
There will be also potentially more data than just time
Hi Gavin, Hi Andy,
On 14.07.25 18:03, Andrew (andy) Newton wrote:
On 7/14/25 11:38, Gavin Brown wrote:
Thanks Jorge!
IMHO, the document is pretty much where I wanted to get it, but
Maarten did raise this point:
i would like to see some changes to the data format if possible, now
there ar
101 - 152 of 152 matches
Mail list logo
