Two points in this email:
* one related to the on a comment that I made at the mic during the 30
March meeting at IETF 116; and
* one higher level issue that came up during Yet Another Read of the draft
Point One:
Section 5: Not sure about whether paragraph 3 of section 5 should have
Mario,
I have an option 3, which is to leverage the help response to signal what is
supported and what the policy is of the server instead of overloading the
purpose of the rdapConformance and notices for the transition signaling. Look
at section 6.2 "versioning-help" Member of
Mario,
Thank you for posting the options to the list. I'll mirror the preference that
I stated at the REGEXT meeting, which is option 2 "Making uid optional in RDAP
and then redacting by Removal method".
Thanks,
--
JG
James Gould
Fellow Engineer
jgo...@verisign.com
703-948-3271
Hi Marc,
thanks for your quick reply.
Think it's always better to reduce the response payload when you can
through a low implementation effort. But it's just my opinion.
So now we have 3 proposals on the table :-))
Best,
Mario
Il 30/03/2023 13:09, Marc Blanchet ha scritto:
Le 30 mars
> Le 30 mars 2023 à 19:47, Mario Loffredo a écrit :
>
> Hi folks,
>
> this is a post to resume the discussion about how to execute the transition
> from jCard to JSContact.
>
> Up to now, there are two approaches on the table:
>
>
> 1) Returning JSContact in place of jCard (current
Hi folks,
this is a post to resume the discussion about how to execute the
transition from jCard to JSContact.
Up to now, there are two approaches on the table:
1) Returning JSContact in place of jCard (current proposal)
Until transition is ended, a server returns one of the two formats by
Hi folks,
this is a post to resume the discussion about how to redact JSContact
uid in RDAP.
The goal is to reach consensus or majority on one of the following
solutuions:
1) Redacting by Empty Value method
2) Making uid optional in RDAP and then redacting by Removal method
3) Recommending
Chair hat off.
Thank you Tom for this document and your presentation. I like it a lot.
I have read this draft, and have some comments/requests as discussed during our
IETF 116 meeting session.
Most of my remarks are about section 4, Link Relations:
1. Suggest to replace “operator” with “server
Gavin,
Upon my first review, I find the extension to be an interesting aggregation
concept. I’m not exactly sure why the client wouldn’t just make separate calls
to get the same information. With that, I have the following feedback:
1. I don’t see the purpose of the child element of the
