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
