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 Thursday, 28 September 2006 19:34:51 UTC