Hiya,
On 10/10/2019 03:52, Martin Thomson wrote:
> There's an interesting (web-only) effort looking at a similar
> problem: https://github.com/krgovind/first-party-sets There, the
> goal is to establish commonality for the purposes of sharing state
> (and fate).
Yes, I saw that recently. I agree there's a partial overlap
in goals.
> A great counter-example in that case is the relationship between
> github.com and github.io, which are administratively the same, but
> purposefully distinct from the perspective of web state.
Sure.
>
> All this makes me wonder what your intent is with respect to
> semantics.
My goal is to define a mechanism with minimal semantics but
that is extensible. (To be open about why - I think efforts in
this space have partly foundered because they've started out
too ambitious, so I figure a more modest starting point may
work out better.)
> o 0: states that no relationship exists between the domains
>
> o 1: states that some relationship exists between the domains
>
> That's incredibly vague.
Nope, it's minimal:-)
Again, that is intentional.
To take the web example you started with, if someone wanted to
use RDBD as a part of that, then I guess it'd mean defining a
new rdbd-tag value (call it "W") and its related semantics, e.g.
if an RDBD RR with a tag W is published at example.com saying
that example.net is related, that might mean that a TLS server
cert ought exist that covers both at once before a client would
be willing to consider shared state for those names (or whatever
else is required to implement the web semantics for W).
The definition of W is envisaged to be in some other spec, with
whatever IANA registry rules would be adopted for rdbd-tag code
points. (Parts of that 16 bit space could be FCFS too of course
but I'd guess spec required might be most useful.)
> If you consider the possibility of there being richer expressions of
> semantics, this starts to look a bit like link relations at the DNS
> layer: https://tools.ietf.org/html/rfc8288
I think the better approach, if expressing relationships in DNS,
is likely to be to encode those down to rdbd-tags or similar. At
least, that's the approach we're espousing here.
Cheers,
S.
>
> On Tue, Oct 1, 2019, at 07:17, Stephen Farrell wrote:
>>
>> Hi all,
>>
>> As per discussion at IETF 105, Alex and I did some more work on the
>> RDBD draft (lots of text edits and a bit of prototyping) and have
>> posted a new version. [1]
>>
>> We'd be very interested in folks' opinions.
>>
>> Thanks, Stephen & Alex.
>>
>> [1] https://tools.ietf.org/html/draft-brotman-rdbd-03
>>
>> ___ DNSOP mailing list
>> DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
>>
>> Attachments: * 0x5AB2FAF17B172BEA.asc * signature.asc
>
> ___ DNSOP mailing list
> DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
>
0x5AB2FAF17B172BEA.asc
Description: application/pgp-keys
signature.asc
Description: OpenPGP digital signature
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
