Re: Last Call: 'The Codecs Parameter for "Bucket" Media Types' to Proposed Standard

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Mon March 14 2005 18:29, The IESG wrote:
> The IESG has received a request from an individual submitter to consider the 
> following document:
> 
> - 'The Codecs Parameter for "Bucket" Media Types '
>    <draft-gellens-mime-bucket-03.txt> as a Proposed Standard
> 
> Although this document is a submission to the IETF from an individual
> it received review in the AVT working group and the IETF-types
> mailing list.
> 
> The IESG plans to make a decision in the next few weeks, and solicits
> final comments on this action.  Please send any comments to the
> iesg@xxxxxxxx or ietf@xxxxxxxx mailing lists by 2005-04-11.

Here are comments sent separately to the authors prior to the
Last Call announcement:
---------
The draft refers to RFC 2045 ("MIME-format") but does not
reference either the RFC-Editor errata page
(http://www.rfc-editor.org/cgi-bin/errata.pl) or RFC 2231.
RFC 2231 amends RFC 2045 in several relevant ways; RFC 2231
is amended by errata (there is also a pending erratum for
RFC 2045 which is expected to be published soon).

The encoding method presented in the draft appears to
interact poorly with the established mechanism in RFC 2231;
perhaps it would be best to specify use of that mechanism
for values which contain tspecials (RFC 2045 as amended)
or which are long enough to warrant splitting, dropping
the separately-specified encoding.
---------

To which I would add that the RFC 2231 (as amended by errata)
mechanism is specifically intended for use with the
Content-Type field parameters (as well as for the field
Content-Disposition).  I believe the omission of consideration
of relevant amendments to RFC 2045 via RFC 2231 and errata
constitutes a "known technical omission" (RFC 2026).  While
the "no known technical omissions" requirement can be waived,
in this case I believe that interoperability would best be
served by having syntax compatible with the general parameter
syntax (which may well be used with other parameters in the
same field) rather than (as at present) requiring special-case
syntax for this one specific parameter.  I believe that the
ABNF and references can be made to conform to the (2231, errata)
amended parameter syntax without affecting the intended use,
etc.

_______________________________________________

Ietf@xxxxxxxx
https://www1.ietf.org/mailman/listinfo/ietf

[Index of Archives]     [IETF Annoucements]     [IETF]     [IP Storage]     [Yosemite News]     [Linux SCTP]     [Linux Newbies]     [Fedora Users]