Re: quoted-pair in dcontent / Space after colon

["Frank Ellermann" <nobody@xxxxxxxxxxxxxxxxx>]

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.

 Frank