From: Bruce Lilly (blilly@erols.com)
Date: Tue Sep 10 2002 - 19:07:36 CDT
Charles Lindsey wrote:
> In <3D792DF2.4EA4DE46@erols.com> Bruce Lilly <blilly@erols.com> writes:
>
>
>>I'd prefer that the "SHOULD NOT" in 4.2.2 be changed to
>>"MUST NOT". [re. "parameters" for headers standardized
>>before the draft (I refer specifically to RFC 2822
>>headers Date, Message-ID, Keywords, Sender, and
>>References (and also implicitly any MIME headers which
>>do not permit parameters).
>
>
> Well rather than MUST NOT, one would remove it from the syntax in those
> places.
Perhaps that would be best -- there's no guarantee that those
(IETF-822 group) responsible for those headers will ever extend
the syntax to allow such parameters, and even if they do, they
might choose a somewhat different syntax. I still think 4.2.2
may need to be clarified.
> In fact we already removed it from From-, Reply-To-, Mail-Copies-To- and
> Complaints-To-headers, and you could argue that Sender should have been
> included in that batch (the reason it was not is that the parsing
> ambiguity does not apply there, and there is no great requirement to take
> a Sender and turn it automatically into a To for reply purposes).
Having done some extensive parsing work, I can state that there's
no parsing ambiguity. There should be no problem with Complaints-To
or Mail-Copies-To -- those are newly defined in the Usefor draft, so
they could include MIME-style parameters if there were a need to do
so.
But headers defined in other RFCs should not be [re]defined incompatibly
in our draft. Requirements such as space-after-colon don't cause
incompatibilities, since space is permitted by the syntax defined
in the other standards, but as there is no provision in the defining
syntax for MIME-style parameters in (most of) those headers which are
defined in other standards, that *is* an incompatibility.
The incompaibility arises whenever such a header might be injected
into its native domain, viz. email. I mentioned three such
mechanisms earlier, and I now add a fourth; the four are:
1. post-and-mail
2. incoming gateways from email (also when a proto-article is sent
to a moderator via email w/o encapsulation)
3. outgoing gateways
4. via intermediate files. A usenet article may be saved as a file
and subsequently forwarded as email (or some software (e.g. combined
news reader/email program) might do so w/o an intermediate file)
In case 1 (post-amd-mail), section 6.9 of the draft requires that
these headers be identical in the posted and mailed versions, therefore
those headers which are defined in email-related RFCs must comply
with the relevant syntax for email as well as meeting the syntax
restrictions (e.g. space-after-colon) imposed by our draft -- and
that means no MIME-style parameters unless explicitly permitted by
the email-related RFCs which define those headers. Usefor-specific
headers such as Complaints-To are undefined in the context of email;
they are permitted so long as they comply with the RFC-2822 rules
for extension headers (which means using the specific permitted
subset of 7-bit codes, etc., and I beieve that in most cases the
draft has provisions for that).
In case 2, obviously email is being used, and the headers must
therefore be compliant with the relevant email RFCs, as above. In
the case of mail to a moderator, it might be possible for the
responsible software to encapsulate or "fix" email-defined headers,
but I suspect that it's best for the proto-article to be generated
with compatible headers in the first place, as that will be required
for the post-and-mail case anyway.
Likewise for outgoing gateways -- email-defined headers could be
transformed, but it's simplest for all if they're compatible from
the moment of generation. Note that that's a separate issue from
transformations to Usefor-specific headers such as Newsgroups, which
need to be transformed to comply with RFC 2822 extension header rules.
Case 4 is likely to present some problems w.r.t. Newsgroups etc.
as mailing from a file might not cause non-RFC 2822 headers to be
made compliant. But at least the email-defined headers ought to
be compatible.
> So there is an arguable case for Sender.
Sender is defined in RFC 2822, section 3.6.2.
> We have already removed it from Message-ID.
Hmmm. In response to a request for the full draft, Charles wrote
(on Aug 2):
> > Is this draft available in full somewhere?
>
>
> I had thought it sufficient to show the diffs, since most of the changes
> are niggles/typos and the one change that people would need to read
> carefully is fully apparent from the diffs. However, just to remove any
> doubt, you should now find it at
> http://www.landfield.com/usefor/drafts/draft-ietf-usefor-article-07.03.unpaged
That document (which, in spite of the URI, says
"<draft-ietf-usefor-article-08.txt>") has, in section 5.3
Message-ID-header = "Message-ID" ":" SP Message-ID-content
*( ";" other-parameter )
which looks like the MIME-style parameters are still there.
> There is an arguable case for Date.
Date is defined in RFC 2822 section 3.6.1.
> I am not convinced there is a serious problem wuth Keywords.
Keywords is defined in RFC 2822 section 3.6.5.
> And I am not convinced about References.
References is defined in RFC 2822 section 3.6.4.
And Supersedes is defined in RFC 2156, and has no provision
for MIME-style parameters. The Usefor syntax for Supersedes
(excepting the paramters) is a subset of what 2156 permits --
if parameters are removed from the specification in the draft
there won't be any problems in cases 1 and 3 (and presumably
incoming gateways and injection agents will deal with any
email-originated Supersedes headers which have multiple msg-ids).
> My understranding is that it is already not allowed for CTE and any other
> MIME headers that do not allow it, since we simply incorporate the
> relevant MIME documents, modulo various trimmings we explicitly mention.
The text of section 4.2.2 seems to imply that MIME-style parameters
may be added willy-nilly to these headers.
A related concern is that 6.21.1 specifically states that those
headers which *are* defined such as to accept parameters may be
generated in such a way as to be imcompatible with the syntax
in the defining standards (specifically UTF-xtra-chars). That
should not be done, as the MIME RFCs specifically provide a means
of encoding 8-bit characters in parameters (see RFC 2231 and
the RFC errata page at http://www.rfc-editor.org/errata.html).
Re. media type vs "Content-Type":
> I don't think this one causes confusion. People who commonly speak of
> "Content-types" (as the frequently do) probably have no idea what a "media
> type" is, unless they are very familiar with RFC 2045 and friends.
If the editor is happy to field requests for clarification etc.,
he may leave it as is... [I suspect that one who speaks of
"Content-types" but who is not familiar with the RFC 204x series
knows not what he speaks about... but that's another story]
>>Other than that one important issue and one minor
>>quibble -- excellent.
>
>
> Which confirms my view that you basically support the #2 position in the
> vote.
Let me clarify: I feel that the working group should not knowingly
submit a draft which is technically incompatible with established
standards and protocols with which interoperation is expected. That
is why I expressed reservations about submission because of the
above issue, in which the draft requires use of email yet has
incompatibilities with established email RFCs and protocols. And
that is also why I gave a flat "no" response to #4, which (as I
read it) basically implied sending a known incompatible draft to
the IETF.