Subject: ManageSieve: allowed characters in script names

From: Alexey Melnikov <[email-masked]>
Date: Tue, 08 Apr 2008 16:00:41 +0100

draft-martin-managesieve-08.txt [currently expired], section 1.7 says:

    Sieve script names may contain any valid UTF-8 characters, except
    for NUL, CR or LF. Names MUST be at least one octet long. Zero
    octets script name has special meaning (see SETACTIVE command
    section). Servers MUST allow names of up to 128 Unicode characters
    in length, and MAY allow longer names.

Is this reasonable? I think we should at least prohibit other ASCII 
control characters.

Isode's implementation is even more restrictive, as it disallows ¬, :, 
/, etc. Should they be allowed?

---

From: Jeffrey Hutzelman <[email-masked]>
Date: Tue, 08 Apr 2008 11:17:30 -0400

> Is this reasonable? I think we should at least prohibit other ASCII

There are probably a number of unicode characters we should prohibit.
Take a look at the tables in the stringprep document, but bear in mind that 
current thinking seems to be that such prohibitions should be based on 
unicode character properties rather than on explicit lists.

It may be appropriate here to apply stringprep to script names, but it may 
also not be necessary.

> /, etc. Should they be allowed?

There are certainly some classes of characters, such as letters and digits, 
that all implementations should accept.  But there also should be some 
flexibility; for example, some implementations may find it useful to 
disallow some subset of [][/\\:;,] or other characters, depending on the 
underlying OS.

-- Jeff

---

From: Kjetil Torgrim Homme <[email-masked]>
Date: Wed, 09 Apr 2008 14:28:35 +0200

On Tue, 2008-04-08 at 11:17 -0400, Jeffrey Hutzelman wrote:
> Alexey Melnikov <[email-masked]> wrote:

I think it is reasonable to require the character to be printable.
e.g., we don't want Unicode BOM in there, either.

> disallow some subset of [][/\\:;,] or other characters, depending on the 

please let us not go down that route, the list of potentially
problematic characters is endless.  an implementation can easily use,
say, a URL-style encoding if it uses a filesystem as its store.

I'm in favour of setting aside one character for hierarchy purposes
though, e.g. "/", even if it has no meaning today.

-- 
Kjetil T.

---

From: Arnt Gulbrandsen <[email-masked]>
Date: Wed, 9 Apr 2008 15:04:53 +0200

> e.g., we don't want Unicode BOM in there, either.

Agree.

> though, e.g. "/", even if it has no meaning today.

If / is reserved, then I suggest that U+2044 ⁄ and U+2215 ∕ should be 
forbidden. Otherwise one clever client will substitute ⁄ for / when 
uploading a script, and wen the types / into another client, that other 
client can't download the script.

Yes, I know visual similarity is a big issue. Dealing with all of it is 
not worth it. Dealing with just this little bit is, IMO.

Arnt