Hi
I have no objections to this document being published.
tim
On Thu, Mar 23, 2023 at 3:17 AM Mario Loffredo
wrote:
> Hi Andy,
>
> Il 22/03/2023 22:37, Andrew Newton ha scritto:
> > I have read the draft again and support it.
> >
> > That said, is there a plan to add this equivalent from
Since it appears that code changes will need to be done for JContact, the
simpler proposal will be number 3.
Bytes are less expensive than making additional requests. (for the most
part)
tim
On Fri, Mar 31, 2023 at 9:03 PM Rick Wilhelm wrote:
> I think that I’m leaning towards Andy’s
I think that I’m leaning towards Andy’s approach, but I haven’t soak this
thinking for very long.
Perhaps it’s useful to go back to one of the original motivations for the draft.
As I recall, programmers, especially client-side, have been known to have
difficulty with JCard (for various
If the uid can be free text according to JSContact, why do we need to
override that? RDAP servers can just put random text in that field,
which has the same effect of the UUID URN.
That said, I like Gavin's idea. I could live with Option 4 or Option 3.
-andy
On Fri, Mar 31, 2023 at 11:52 PM
I really don't understand this decision tree. JCard is in the standard
today while JSContact is not. Any transition that aims to be as
non-disruptive as possible would need to start at serving JCard today,
serving both JCard and JSContact, and then phasing out JCard.
-andy
On Thu, Mar 30, 2023
Comments in-line:
On Thu, Mar 30, 2023 at 5:38 PM Antoin Verschuren
wrote:
>
> 2. With regards to the hierarchy itself, there are 2 use cases that can be
> served better:
> Most common use cases are:
>
> -Where is address space used when querying an IP address or prefix
> Usually, this is the
Hi Scott,
Il 31/03/2023 14:32, Hollenbeck, Scott ha scritto:
-Original Message-
From: regext On Behalf Of Mario Loffredo
Sent: Friday, March 31, 2023 7:45 AM
To: regext@ietf.org
Subject: [EXTERNAL] [regext] Redacting JSContact uid in RDAP - Updated
Caution: This email originated from
> Le 31 mars 2023 à 08:32, Hollenbeck, Scott
> a écrit :
>
>> -Original Message-
>> From: regext On Behalf Of Mario Loffredo
>> Sent: Friday, March 31, 2023 7:45 AM
>> To: regext@ietf.org
>> Subject: [EXTERNAL] [regext] Redacting JSContact uid in RDAP - Updated
>>
>> Caution: This
> -Original Message-
> From: regext On Behalf Of Mario Loffredo
> Sent: Friday, March 31, 2023 7:45 AM
> To: regext@ietf.org
> Subject: [EXTERNAL] [regext] Redacting JSContact uid in RDAP - Updated
>
> Caution: This email originated from outside the organization. Do not click
> links
>
Hi folks,
just reported below all the options (including Gavin's proposal) and the
preferences given thus far.
Please, express your preference(s).
Thanks a lot in advance.
1) Redacting by Empty Value method
2) Making uid optional in RDAP and then redacting by Removal method
- J.Gould
3)
Sorry, forgot to reply to all.
Messaggio Inoltrato
Oggetto:Re: [regext] Redacting JSContact uid in RDAP
Data: Fri, 31 Mar 2023 13:14:50 +0200
Mittente: Mario Loffredo
A: Gavin Brown
Hi Gavin,
Il 31/03/2023 12:48, Gavin Brown ha scritto:
Ciao Mario,
Ciao Mario,
Can I propose an alternative?
Since (IIRC) a UID can be a URN, and IANA maintains its own URN namespace,
could we register a URN that would be used to redact the UID? Something like
"urn:ietf:params:json:rdap+jscontact:uidRedacted"?
Servers could publish this value in the UID of a
12 matches
Mail list logo
