Pete Resnick wrote:
I'm separating out these two issues, as I want to hear yeas and nays
(and explanations) from people other than Charles and Frank.
So, there are two forms to this request:
1. Remove quoted-pair entirely from dcontent in the generate syntax
(meaning "[", "]", and "\" may never appear in dcontent).
> 2. Only allow the quoted-pairs "\[", "\]", and "\\" in dcontent in the
> generate syntax.
> Of course, quoted-pair would be in the obs- (interpret) syntax.
+1 for #1. I agree with removing these from the generate syntax. I see
no need for us to ever generate them in a domain address literal.
[On space after the ":"...]
[Charles originally wanted:]
Although in all header fields the CFWS following the colon is
optional, it is customary to place at least one SP there; moreover
such a SP is mandatory in some related protocols (notably
[NETNEWS]). In order to facilitate interoperability with such
related protocols, that SP SHOULD normally be present.
Although all message header fields allow either [FWS] or [CFWS] after
the colon, it is customary to place at least one white space
character after the colon. In NetNews articles [RFC xxxx] it's
mandatory to use a space character after the colon, and in order to
faciliate interoperability implementors might wish to separate the
header field name plus colon from the header field body by a space in
all Internet messages.
But if we can agree that a wording of some form along the lines of
what I and Frank are suggesting, then the exact wording can be worked
on by further discussion. As I said, either wording is netter than
My personal feeling on this is again it is not necessary, and that a
gateway should be dealing with this anyway. But if people want text, I
would be OK with a non-normative note in either 2.2 or 3.6. (Anything
with a SHOULD I will make a stink over.) As editor, I'd want specific
text agreed to and instructions on where to put it.
Requiring a SP character after the : is a non-starter for me. I've used
a number of systems that use TAB instead of SP; they're still out there
and should not be considered invalid.