Re: [Social-discuss] Protocol / Design Considerations.

[Hellekin O. Wolf]

On Wed, Mar 17, 2010 at 12:42:31AM +0200, Petr Viktorin wrote:
> On Wed, Mar 17, 2010 at 00:04, Blaine Cook <address@hidden> wrote:
> > On 16 March 2010 21:16, Melvin Carvalho <address@hidden> wrote:
> >>
> >>> HTTP URLs don't work as addresses *for people*.
> >>
> [snip]
> 
> The fundamental problem, IMO, is that any fully qualified, unique ID
> is just too long.
> 
> I would very much like to see some kind of local aliases. Here's the
> idea (Concrete syntax/terminology might be different of course):
> If I write "@fred", the software knows I want the Fred from my "friend list".
> If I want to reply to someone I don't know, I can use a full URL.
>
*** Using a "universal identifier" in the form address@hidden poses a
serious problem of compatibility with the HTTP URI scheme: in the HTTP
protocol (as well as FTP and probably others), address@hidden refers to
the *authenticating user*, not the user supposedly represented at the
said URI.  In that sense, email and XMPP are exceptions to the rule.

PSYC uses the concept of UNI, for Uniform Network Identifier, which is
basically an URL for humans. It takes the form of
psyc://domain.tld/~user and thus matches the traditional HTTP or IMAP
URI for a user (see examples in RFC5092).

RFC2396 says however that: 

  The tilde ~ character was added to those in the "unreserved" set,
  since it is extensively used on the Internet in spite of the
  difficulty to transcribe it with some keyboards.

Yes, PSYC UNIs are long. But (1) it's mostly for programs to talk to
each other and (2) people can use aliases, and maybe pass this
alias<->UNI correspondance along with the message, so that other
people know what Fred you're talking about.

On the other hand, using a shortcut such as address@hidden doesn't scale
across protocols, and still require marking the JID, er Email?, with
the appropriate protocol. See:
http://about.psyc.eu/Jabber#JIDs_aren.27t_flexible_enough for more
arguments against using that syntax, especiaally in the enlarged
context of multiple protocols talking to each other.

==
hk