[Top] [All Lists]

Re: quoted-pair in dcontent / Space after colon

2008-01-22 05:23:22

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.

 [magic SP]
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.