John Merrells wrote:

I think most of this comment was based on your misunderstanding above... so no silos....

My misunderstanding is based on the fact that the sxip attributes are in the document yet apparently only sxip.net can supply the values (no matter where they are stored).

In that case I don't understand

a) why they are documented since there does not appear to be point of interoperability (these are for your website?),

b) why a homesite would need to explicitly "support" the sxip#1 capability and advertise that support, since for the homesite they are opaque attributes and it can either choose to allow the storage of opaque random attributes or not, and any one user either has those attributes or not - or is this a crude form of access control for homesite storage?, where is the capable in capability?

and c) what exactly is the homesite expected to do to "tailor its response" when presented with the dix:/membersite-accept when it has no real knowledge of the attributes involved beyond what they are called (and presumably the membersite requests only what it does understand.)

Sorry to bang on about this, but I am actually trying to cut code here :)

I would rather see a property type schema where the source of the property is not tied down, only its meaning. The source of the property can be disclosed (as a signature) for those membersites that care, then user supplied attributes may simply not be signed. In fact, in many common cases the source _will_ be the user anyway.


That's exactly what I think we need and what I believe dmd1 enables.

What I mean by "meaning" is really the "universally understood meaning" - not one meaning that only one entity understands . Without universally understood meanings for a set of defined attributes dix would merely be a means to use somebody elses hard drive for data storage. There may be value in that for all parties, but the greater value is when everyone talks the same language, not just the same protocol.


There are various social models for working out agreements for the names of things.

None of which work terribly well once you switch on the computer, but I'll agree not to mention it again until you buy me a pint.

--
Pete

Attachment: smime.p7s
Description: S/MIME Cryptographic Signature

_______________________________________________
dix mailing list
[email protected]
https://www1.ietf.org/mailman/listinfo/dix

Reply via email to