[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: quoted-pair in dcontent / Space after colon
Charles Lindsey wrote on the 822 list:
>> 2. Only allow the quoted-pairs "\[", "\]", and "\\" in dcontent
>> in the generate syntax.
>> My personal opinion: #2 makes me queasy and I will argue tooth
>> and nail against it.
> Yes, I agree that #2 is a mess.
How on earth did it end up in the NetNews RFC if you agree that
it is messy ? Cc: USEFOR, maybe that is a simple AUTH48 fix (?)
> 3. As an alternative to #2, allow "\" as a character in <dtext>
> in its own right (but with no special semantic interpretation).
> I am not pushing for that
Good, because introducing a new "\"-semantics is even worse. We
are talking about *hypothetical* new domain literals, and there
is no backslash in an STD 66 IPvFuture:
| IPvFuture = "v" 1*HEXDIG "." 1*( unreserved / sub-delims / ":" )
| unreserved = ALPHA / DIGIT / "-" / "." / "_" / "~"
| sub-delims = "!" / "$" / "&" / "'" / "(" / ")"
| / "*" / "+" / "," / ";" / "="
There's also no "[" or "]" within an IPvFuture, it's beyond me
why we need to talk for months in USEFOR (and now again here)
about this cruft.
> it would allow everything that is allowed at present, if
> people care about that.
How could they care about non-existing IPvFuture "features"
not permitted in STD 66 ? Where was <quoted-pair> in <dtext>
ever used outside of theoretical discussions ? Implementors
wishing to ignore a "\" as (an unnecessary) <quoted-pair> in
<dtext> can still do this, even if it's "not allowed".
The opposite approach, "allow" it and then say why it breaks
e.g. octect-comparison of Message-ID, is far more convoluted.
> 4. As an addition to any of #1, #2 or #3, make the change
> only in <no-fold-literal>, leaving <domain-literal> alone.
Good for Message-ID (etc.), but not good enough for 2821bis.
> But of those, my preference would still be for #1, or for
> #1+#4 as second best.
Yes, #1 is KISS, and if the inventors of a new IP version or
another "domain literal" concept really want backslashes or
square brackets *within* their constructs let them "fix" the
relevant RFCs (STD 66, 2822upd, 2821bis, NetNews, ...)
> Every gateway is, in practice, a hand-crafted script
> tailored for its specific purpose.
+1 And gateway operators won't like to "fix" any Message-ID,
there are simpler ways to commit net suicide. I also don't
see how gateway operators are supposed to "fix" or replace
non-existing domain literals in addresses for a peer network,
see 2821bis 3.7.4 for some MUSTard and SHOULDs about this.
> Same answer as regards gateways. People writing ad hoc
> scripts are just not going to bother to check for such
> unlikely circumstances.
The script won't be able to inject any message without the
"magic SP" for critical header fields into NetNews, a "GiGo"
approach won't fly. It's no "unlikely" scenario, a header
field folded immediately after the colon makes sense.
And a field name-colon-space-folding-WSP-body contruct is
not a "magic SP", for NetNews a non-empty part of the body
has to exist in the first line (before the first folding) -
some header fields are better not folded at all in NetNews.