Re: CPIM and URIs

At 08:45 AM 5/24/02 -0400, John D. Ramsdell wrote:
>Graham Klyne <[email protected]> writes:
>
> > >In addition, I am unclear about the issue of quoting.  As I understand
> > >RFC 2822 and RFC 2396,
> > >
> > >     "John D. Ramsdell"@mitre.org
> > >
> > >is a valid Email address, but
> > >
> > >     im:"John D. Ramsdell"@mitre.org
> > >
> > >is not a valid URI.  One must write
> > >
> > >     im:%22John%20D.%20Ramsdell%[email protected]
> > >
> >
> > I would then say that the correct form of your example URI should be:
> >
> >      im:John%20D.%[email protected]
> >
> > #g
>
>Just to be perfectly clear, I would like to understand the
>implications of your encoding of an Email address as a URI.
>
>When given an opaque URI, one can compute the decoded scheme specific
>part, which is a string in which all the % escaped characters are
>replaced by their ASCII values.
>
>Given a valid email address, one can also compute a decoded string in
>which all the invisible characters in an email address are removed.
>
>Graham, does the following statement correctly describe the essential
>property of an instant inbox URI encoding you have in mind?
>
>   URI u encodes an email address e as 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 identical to e
>           after all invisible characters in e are removed.
>
>         * The fragment part of u is absent.
>
>If so, I think it would be helpful to spell this out in CPIM.

I think that is about right, but I also think it doesn't really matter.

At the end of the day, an im: URI is just a URI that is used to address an 
instant inbox.

The reference to email address is not intended (as far as I'm aware) to 
create a relationship between email addresses and inbox addresses.  It is, 
as I understand it, an attempt to reuse some piece of design with which 
there is some useful long-term experience.  That was why I argued the case 
for the appropriate URI form with reference to the email specs - given that 
there's something that *looks* an email address, trying to arrange that it 
*behaves* like an email address;  i.e. trying to minimize surprises.

#g

-------------------
Graham Klyne
<[email protected]>



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