On Tue, 01 Nov 2005 02:21:31 -0700 Duncan <[EMAIL PROTECTED]> wrote:
| I'd suggest we preemptively incorporate an ENewsVersion or similar
| field as well, to be 1.0, with this proposal, but should the format
| ever need changed, that would allow for a format version 1.1 or 2.0
| or whatever.  As the GLEP suggests that future GLEPs may add new
| headers, this would allow them to update this version field as
| necessary, presumably using the familiar minor version = backward
| compatible, major version if not backward compatible, versioning
| scheme.

Sounds reasonable.

| One other niggle.  The encoding is specified as UTF-8, but then the
| format is specified as RFC-822 (7-bit ASCII, pre-i18n) compatible.
| I'm not up on i18n specs, but presumably there's a newer RFC that
| specifies how internationalized internet messages are handled in an
| RFC-822 backward compatible way? If so, it may make more sense to
| reference that specific RFC, which presumably deals with UTF-8
| instead of specifying 7-bit ASCII as does 822. Alternatively,
| MIME/Quoted-printable could be specified, which would allow for
| escaped 8-bit chars, as I'd /assume/ UTF-8 requires, given the -8.
| (I /said/ I'm not up on that!)

Hrm. The "RFC-822 like" phrase is used in various places (for example,
the GLEP specification) to describe the structure of the header
section. I don't think it precludes us also specifying UTF-8.

-- 
Ciaran McCreesh : Gentoo Developer (Vim, Shell tools, Fluxbox, Cron)
Mail            : ciaranm at gentoo.org
Web             : http://dev.gentoo.org/~ciaranm

Attachment: pgpF68FABHDWY.pgp
Description: PGP signature

Reply via email to