Subject: RE: Web Character Model and IRI spec (Re: FW: character encoding.)

From: "Larry Masinter" <[email-masked]>
Date: Sat, 27 Jul 2002 09:17:32 -0700

I think that it would be great if the WebDAV spec
could be clear about encodings in URIs, and the
relationship between the HTTP URIs used in the protocol
and the XML strings used in enumerations of collections.
I'm not sure you need to make a normative reference to
either the IRI spec or CHARMOD to do so, if you're concerned
about establishing an unnecesary schedule dependency.

This is because the IRI spec doesn't actually say the
things that WebDAV needs to say in order to get interoperable
implementations -- what is the expected behavior of
WebDAV user agents when showing strings to the users?

This has been an issue in interops already, not just
for I18N, but also for simple URL encoding, e.g., of
file names with spaces in them.

Larry

---

From: "Julian Reschke" <[email-masked]>
Date: Mon, 29 Jul 2002 12:49:22 +0200

> From: [email-masked]
> [mailto:[email-masked]]On Behalf Of Larry Masinter
> Sent: Saturday, July 27, 2002 6:18 PM
> To: [email-masked]
> Cc: 'Webdav WG (E-mail)'
> Subject: RE: Web Character Model and IRI spec (Re: FW: character
> encoding.)
>
>
>

OK, what do we need to specify:

1) display of member names in collections: take the last URI segment, then
URL-unescape, then UTF-8-decode

2) creation of new resources:

2a) all URI segments MUST be UTF-8-decodable after URL-unescaping
2b) if the "local display name" (for instance document name when typing into
file selector box) contains non-ASCII characters, it MUST be UTF-8 encoded
then URL-escaped.

3) Forbid member names in collections that aren't Unicode-normalized after
URL-de-escaping and UTF-8-decoding.

Opinions?

Julian

---

From: Taisuke Yamada <[email-masked]>
Date: Tue, 30 Jul 2002 22:46:23 +0900

> 1) display of member names in collections: take the last URI
>    segment, then URL-unescape, then UTF-8-decode
>
>   2b) if the "local display name" (for instance document name when
>       typing into file selector box) contains non-ASCII characters,
>       it MUST be UTF-8 encoded then URL-escaped.
>
> 3) Forbid member names in collections that aren't
>    Unicode-normalized after URL-de-escaping and UTF-8-decoding.

Yes, these should cover most of the requirements. But rather than
specifying each case separately, it might be easier to say all
strings derived from, or related to resource URI to fullfill
following requirements:

  - All URI segments MUST be URL-escaped after converted into
    "normalized form" of UTF-8 string.

  - Each implementation MUST do the necessary conversion between
    above form and "local representation" of the resource (name
    typed in selector box, name stored on client/server filesystem, etc.).

For 2b, you don't need to handle ASCII/non-ASCII cases separately
since UTF-8 covers ASCII.

Also, adding notes on several HTTP headers such as Destination:
and Status-URI: might be needed as they seem to be protocol-specific
headers.

Regards,
--
Taisuke Yamada <[email-masked]>
Internet Initiative Japan Inc., Technical Planning Division