RE: [xri] GCS Characters

["Schleiff, Marty" <marty.schleiff@boeing.com>]

Then 1id.com might have to refund Boeing's purchase of @boeing ;-)

I agree with Victor. If there is a reason for two (= and @), then there
is a reason for more than just two (even though we may not yet have
discovered the reason). And I've always believed that the difference
between individuala and organizations may be difficult to recognize, and
therefore difficult to enforce. When an individual acquires the
"=example" XRI, they also acquire the rights to administer the
"=example" namespace. So if they register an organization in their
namespace, "=example*orgname" then that's an identifier for an
organization under the = space.


Marty.Schleiff@boeing.com; CISSP
Associate Technical Fellow
Information Security Technical Controls
(206) 679-5933

-----Original Message-----
From: Victor Grey [mailto:victor@idcommons.org] 
Sent: Monday, November 24, 2008 10:23 AM
To: John Bradley
Cc: Chasen, Les; Drummond Reed; OASIS XRI TC; David Orchard
Subject: Re: [xri] GCS Characters

The confusion with email addresses, social, technical or otherwise, is
not the only problematic aspect of the @ GCS character.
XMPP addresses take the form of username@host/optional/path. The
username part (known as a JID or Jabber Identifier) has only a very few
disallowed characters, including whitespace and control chars and : / "
' and of course @.

The = and @ GCS characters both denote a reassignable identifier for an
entity, as opposed to + and $ which identify terms.
@ and = also serve as configurable aliases for an XRD discovery function
$f(x), for example $dns(xri.net).

If we didn't have to deal with @, we could define a very simple and
expandable set of transformations for XRD discovery:
Given an abstract ID =drummond with $f(x) configured as $dns (xri.net),
here are some possible discovery transformations:
https		https://xri.net/=drummond
http		http://xri.net/=drummond
xmpp		=drummond@xri.net
mailto	=drummond@xri.net (I think there is an attractive case for an  
XRI aware mailserver that can resolve the XRI and make service
selections based on the XRD and x-headers.)

Other as yet to be invented communication protocols could all be
accommodated with this simple and very abstract spec. We shouldn't let
the current kerfluffle with the W3C derail us into thinking that http is
the whole universe of possibility.

Since @ and = behave exactly the same way, and =ids --can-- be used as
community roots already, I've never really understood any strong
necessity for the overloading of the entity identifier to distinguish
individuals from collections of individuals, and the disregard of the
fact that there could be other kinds of entities besides those two.

So at the risk of making everyone's head explode, I'm proposing that we
deprecate the @ GCS character in XRI 3, and make = the single GCS
character that denotes a reassignable identifier for any kind of entity.
An entity would be defined as anything that can have an XRD.

=vg


---------------------------------------------------------------------
To unsubscribe from this mail list, you must leave the OASIS TC that
generates this mail.  Follow this link to all your TCs in OASIS at:
https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php