Re: quoted-pair in dcontent / Space after colon (Was: New 2822upd-04 - obs-NO-WS-CTL)

With reference to:
   http://www.imc.org/ietf-822/mail-archive/msg06171.html

I was asked to comment.  I've reviewed the ensuing thread, but am not fully 
aware of all prior discussion.


Pete Resnick wrote:
> [On quoted-pair in dcontent...]
> 
> 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.
> 
> My personal opinion: #2 makes me queasy and I will argue tooth and nail 
> against it. If people are heavily in favor of #1, I won't raise a stink, 

The coder in me would prefer (1) that escaping be applied consistently 
*everywhere* in a message header, or (2) applied in as few different places as 
possible.

Since (1) is a long gone option [*], I'd favour #1 in the absence of any 
compelling reason to retain the escape chars in domains or message ids.  I've 
scanned the thread forward from this message and in a fair amount of discussion 
have not seem any reason to keep these escapes.  If not applied consistently per 
option (1), escaping in message ids seems like a particularly poor option, 
complicating as it does the very notion of identity comparison.

cf.
   http://resnick1.qualcomm.com/draft-resnick-2822upd-04.html#addrspec
   http://resnick1.qualcomm.com/draft-resnick-2822upd-04.html#ident

I agree with other comments that limiting to escapes to \[, \\, \], or simply 
allowing \ as a non-escape character are not desirable options.  The former 
created yet another special case, and the I think latter has the potential for 
great nasty surprises - the use of \ as an escape in this context is, I think, 
just too deeply ingrained.

[*] Question for the reader:  Is this still an implementation choice?  I parse 
headers by first running an unescaping pass over the entire header, then parsing 
the resulting tokenized stream, I know I'll accept some headers that are 
strictly incorrect, but do I end up mis-interpreting or rejecting any valid 
headers?  I'd like the answer to be No.


> [On space after the ":"...]
> 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.

I agree that it's not necessary, but non-normative text is OK.

Reading this thread, it seems to me that this is a news/mail gateway issue and 
not really applicable 'within the framework of "electronic mail" messages' (cf. 
abstract), and as such the information might better belong in a separate 
informative document about implementing mail/news gateways, which could do more 
justice to a range of issues in this area.

cf.
   http://resnick1.qualcomm.com/draft-resnick-2822upd-04.html#fields
   http://resnick1.qualcomm.com/draft-resnick-2822upd-04.html#fielddefs

#g

-- 
Graham Klyne
For email:
http://www.ninebynine.org/#Contact