Re: CPIM and URIs

At 04:00 PM 5/28/02 -0400, John D. Ramsdell wrote:
> > You've lost me now.  The syntax I mentioned allows exactly one '@' in
> > an im: URI.
>
>I was worried about URIs that contain the string "%40", the escaped
>version of '@'.  The point I tried to make is that with your syntax,
>one cannot make use of a generic URI scheme specific part decoder.
>This is because '@' and "%40" both translate into the same code, so
>that '@' no longer can be relied on to separate the local part from
>the domain.  Java provides the java.net.URI class that includes a
>method which supplies the decoded scheme specific part, the string
>that results after replacing each escaped sequence with its ASCII
>value.

I understand that %-escaping in URLs is commonly used to hide the special 
meaning of characters like '/', so I'd apply a similar principle to 
'@'.  That means replacing some escape sequences with their ASCII 
equivalent might be problematic.  RFC2396 section 2 says:
[[
    Within a URI, characters are either used as delimiters, or to
    represent strings of data (octets) within the delimited portions.
    Octets are either represented directly by a character (using the US-
    ASCII character for that octet [ASCII]) or by an escape encoding.
    This representation is elaborated below.
]]
Note that %-escaping is not extended here to characters used as 
delimiters.  Also, in RFC 2396 section 2.2:
[[
2.2. Reserved Characters

    Many URI include components consisting of or delimited by, certain
    special characters.  These characters are called "reserved", since
    their usage within the URI component is limited to their reserved
    purpose.  If the data for a URI component would conflict with the
    reserved purpose, then the conflicting data must be escaped before
    forming the URI.

       reserved    = ";" | "/" | "?" | ":" | "@" | "&" | "=" | "+" |
                     "$" | ","
]]

I could go on, but I recommend reviewing all of RFC 2396 sections 2.*

There is also currently some discussion about URI I18N proposals (IRIs, 
etc) that generally recommends any conversion of URI form (e.g. of 
%-escapes) be left as late as possible in the processing;  e.g. if URIs 
contain Unicode characters in their "original character sequence" form, to 
delay conversion to hex-encoded-UTF8 form until the "URI character 
sequence" is actually needed, such as for retrieving the document at a 
URI.  (See RFC 2396, section and 2.1)

#g

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



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