Re: CPIM and URIs

Graham Klyne <[email protected]> writes:

> But I'm worried that this is making a simple thing complicated, or at
> least difficult to follow for people who aren't familiar with the
> other related specs.  Maybe, instead, we could just define a syntax
> for an im: URI, and leave it at that?

I think the definition I gave should be abandoned for two reasons.
One is that I like your suggestion better, but the other reason is
that the definition I gave was ambiguous.  There was no way to
identify the '@' character that separates the local part from the
domain.  After removing the invisible characters from the following
two examples, tell me how to separate the local part from the domain.

     a@[@\[@]

     "a@]"@[@]

> E.g. something like this
> 
> [[
>     Inboxes are named using URIs with the following ABNF syntax:
> 
>         ;; Domain is defined in [RFC2821], either a FQDN or a literal
>         inbox       = "im:" local "@" Domain
> 
>         local       = address [ "/" subaddress ]
> 
>         address     = token
> 
>         subaddress  = token
> 
>         ;; all non-control characters, excluding "/" and "@" delimiters
>         token       = 1*(%x20-2E / %x30-3F / %x41-7E / UTF-8) ;; [RFC2044]
> 
>     URI character escaping (%hh) is used as necessary when presenting the
>     URI to an environment that expects a US-ASCII URI character sequence
>     to be used [RFC2396, section 2.1].
> ]]
> 
> (This was adapted from email addresses, but is not identical to
> RFC2821/2 syntax.)

The one pain in the neck about this is one cannot use Java 2 Standard
Edition 1.4's java.net.URI class to do the work for you since you have
to keep track of which '@' separates the local part and the domain.
Maybe the scheme specific part should simply be an encoding of the
external representation of an Email address.

  URI u is an instant inbox URI if and only if all of the following
  are true:

        * The scheme of u is the string "im".

        * The decoded scheme specific part of u is an addr-spec as
          defined by the non-obsolete productions given in RFC 2822.

        * The fragment part of u is absent.

On the other hand, writing a parser for your productions seems
straightforward.

John


  [reminder: [email protected] for non-technical discussions, please]