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
pgpF68FABHDWY.pgp
Description: PGP signature