- From: Kingsley Idehen <kidehen@openlinksw.com>
- Date: Tue, 03 Jan 2012 21:39:12 -0500
- To: public-xg-webid@w3.org
On 1/3/12 8:27 PM, Mo McRoberts wrote: > On 4 Jan 2012, at 00:56, Kingsley Idehen wrote: > >> Use a Name to do things that fit the Name Role. Don't use was many think is an Address as a Name, certainly not at first blush irrespective of deeper prowess. Use an Address for functionality folks intuitively associate with addresses e.g., data access. Use Names to Identity things. > I a feeling this paragraph is meant to be fundamental to your point, but I honestly can't make head nor tail of it. Use a Name to Name things. Does an HTTP URI instinctively come across to the typical Web Developer as a Name? It doesn't. It comes across an an Address. The level of indirection is no more than 1. > > It's probably not worth the hassle of point out that both DN and subjectAltName are called “names” in X.509. You have a generic Name and a function specific Name (e.g. an Address). In the CN examples I've given you have examples of two address types i.e., http: scheme and mailto: scheme. The intuition of "Address" is there. Likewise, the intuition of a generic name re. Subject Alternative Name. > Only one (and even then, only parts of it) — the DN — is readily presented in interfaces, and where it is, it’s done so as a label. That isn't my the core issue here. Basically, the use as label doesn't determine its semantics. Why are there examples of CN's with URLs all over the place then? > The subjectAltName is an implementation device, unlike host-meta is or the Link HTTP response header. It's a slot for Names in the generic sense. You can use URIs as well as other identifiers in this slot. Also please remember a URI != HTTP URI, solely. [SNIP] -- Regards, Kingsley Idehen Founder& CEO OpenLink Software Company Web: http://www.openlinksw.com Personal Weblog: http://www.openlinksw.com/blog/~kidehen Twitter/Identi.ca handle: @kidehen Google+ Profile: https://plus.google.com/112399767740508618350/about LinkedIn Profile: http://www.linkedin.com/in/kidehen
Received on Wednesday, 4 January 2012 02:39:41 UTC