On Thu June 30 2005 15:15, Frank Ellermann wrote:
Bruce Lilly wrote:
the only issue appears to be that some UAs (no other
software has need to parse a References field) are not
compliant with the specifications
That's not exactly the point:
A few of these "UAs" can be Web interfaces trying to display
some sort of "threads" using (among others) the References.
Some of these broken UAs can mangle the References in wild and
wonderful ways causing more wonderful side effects with other
UAs, which can normally handle all syntactically well-formed
References.
Do you mean when creating a f^H(avoiding controversial term) response?
If so, and the UA/posting agent/(controversial word) agent generates
invalid syntax, then the injection agent ought to reject that response
article, avoiding damage. If not, then how does such mangled content
get from one UA to another?
I believe that rejecting invalid articles at the injection agent is
consistent with WG consensus, though USEPRO section 7.2 doesn't
actually say that an injection agent may reject a non-conforming
article, even though it is tasked with ensuring conformance.
Perhaps forwarding to a moderator (permitted as the sole alternative
to injection)... but I digress.
We are after all talking about parenthesized comments, which
have always been part of RFC 822 syntax and aren't exactly rocket
science.
that isn't an interoperability problem of the sort described
in BCP 14.
If one UA gets it wrong and that causes another UA to crash it
is only a SNAFU. But if the crshing UA is a Web interface or
another piece of software running in unattended mode it's bad.
I think the answer is to reject non-articles at the earliest
opportunity (injection agent). I.e. prevent the rogue UA/posting
agent/whatever from causing damage; the injection agent enforces the
syntax rules.
s/cause interoperability problems/be misinterpreted by
non-conforming parsers/ would be more accurate
IBTD, it's about conforming parsers confronted with the invalid
input caused by another non-conforming parser elsewhere.
In that hypothetical case, it's not the comment that's causing a
problem, it's something else. So it would be incorrect to say
that the comment(s) "cause interoperability problems". The
"something else", whatever that might be, either results in a
syntactically valid field or not. If not, then it along with
the article containing it is rejected (or forwarded to some
moderator) instead of being injected. If the field is
syntactically valid, what is the problem?
If
what you said boils down to a "don't replace the SHOULD NOT
by a MUST NOT" I'd support it.
What it boils down to is: "interoperability problems" implies "MUST NOT".
The original suggestion was to therefore replace SHOULD NOT with MUST
NOT. If (and only if) I can be convinced that there really is an
interoperability problem caused by a mere comment, I'll support that
change. I don't see such an interoperability problem, so my counter-
proposal is to avoid the conflict by replacing "interoperability
problems" with something more accurate, and I have suggested *specific*
text for that replacement, with some sort of relevant argument to
support that suggestion (the argument is NOT "because unripe bananas
are green"). I'm ambivalent about leaving the "SHOULD NOT"; comments
are for human consumption, and few people care about reading
References fields, even if their UA displays them -- of course adding
human-readable comments that are unlikely to be read isn't a great
idea. For that matter, the entire text could be elided; lots of
non-conforming UAs will misparse lots of things causing no perceptible
problems elsewhere (provided injection agents reject invalid syntax
that such a UA might generate in a response) -- if we add text to cover
every such possibility we'll be back to 115 pages, at least if the WG
stays active for another 8 years so any masochists with the stomach for
it can do so...
I guess we have at least the following options:
1. no change
2. s/SHOULD NOT/MUST NOT/
3. s/cause interoperability problems/be misinterpreted by non-conforming
parsers/
4. elide the entire text
Although I suggested the third option, on further consideration I'd like
to switch to the fourth (with the third as a fallback)