RE: Proposed disposition of Stuart Williams' comments on Metadata in URI 31

Marty,

The examples below that involve inferring information from a particular
URI prefix certainly sound like they could also be achieved by use of a
specialized http URI prefix like "http://xri.example?" (as described in
[1]) instead of a URN subscheme like "urn:xri".   Right?

[1] http://dbooth.org/2006/urn2http/

David Booth, Ph.D.
HP Software
dbooth@hp.com
Phone: +1 617 629 8881
  

> -----Original Message-----
> From: www-tag-request@w3.org [mailto:www-tag-request@w3.org] 
> On Behalf Of Schleiff, Marty
> Sent: Thursday, September 28, 2006 3:34 PM
> To: Mark Baker
> Cc: www-tag@w3.org
> Subject: RE: Proposed disposition of Stuart Williams' 
> comments on Metadata in URI 31
> 
> 
> Hi Mark,
> 
> > On 9/27/06, Schleiff, Marty <marty.schleiff@boeing.com> wrote:
> > > By "scheme-type information" I mean the type of 
> information we can 
> > > recognize in a URI based on its scheme. Examples might include:
> > >
> > >  - which protocol to use (like ftp)
> > >  - allowed and disallowed characters (like IRIs - I think)
> > >  - meaning of positional query string parameters (like ldap 
> > > attributes, scope, and filter)
> > >  - whether or not it is intended as a persistent identifier 
> > (like urn)
> > >  - whether or not it is even dereferencable (like urn)
> > >  - whether or not to use SSL (like https)
> > >  - on-click behavior (like mailto - bring up a mailer)
> > >  - scheme-specific normalization and comparison rules
> > 
> > Ok, so going back to your question, which was;
> > 
> 
> Mark said: 
> > Most of the information you list above is available via 
> > either the URI generic syntax, or a scheme specific syntax.  
> > The exceptions would be;
> 
> I think that's the point I'm trying to make. An application 
> can look at
> a URI's scheme to help it figure out how to deal with the URI (it
> probably has different click behavior for ldap:// vs mailto: vs
> http://).
> 
> Mark said:
> > I'd be interested in your thoughts on the value of presenting 
> > information via the URI itself, versus in the data returned 
> > by dereferencing the URI.
> 
> I think that would be VERY valuable. A URI's scheme has traditionally
> been used to convey some of this kind of information. I think URN
> subschemes are also used to convey such information. Part of the XRI
> work is also focussed on conveying such information. Here's a couple
> examples of how such information could be usefull to a 
> company like mine
> is increasingly relying on federation capabilities:
> 
> 1) When receiving assertions (e.g., SAML, X.509 certs) from 
> outside the
> company, it would be nice to know whether or not the asserted 
> identifier
> is a one-time pseudonym or not. If it's a one-time pseudonym, 
> then we'll
> never see it again in another assertion, so we wouldn't even bother to
> set up a user profile for that user.
> 
> 2) When receiving assertions (e.g., SAML, X.509 certs) from 
> outside the
> company, we'd like the assertion source to have a conventional way to
> express a claim that the identifier will never be reassigned 
> to another
> principal/entity. If an identifier is reassignable, we have to be
> extra-vigilant about managing the privileges we assign to that
> identifier (or perhaps even refuse to assign privileges). 
> Otherwise when
> the identifier gets reassigned to some new entity, there's a high
> liklihood the new entity will mistakenly inherit the 
> privileges intended
> for the prior entity.   
> 
> I think dereferencing is really nice for obtaining information about a
> named entity, especially information that can change. When information
> about a named entity changes, it's nice to be able to update the
> dereferencable information without having to rename the 
> entity. However,
> metadata about the identifier itself should be built into the
> identifier.
> 
>

Received on Friday, 29 September 2006 04:05:10 UTC