Date: Wed, 6 Mar 1996 13:20:36 -0800 (PST)
From: Mark Crispin <MRC@Panda.COM>
Sender: Mark Crispin <mrc@Ikkoku-Kan.Panda.COM>
Subject: re: Message format document outline
To: John Gardiner Myers <jgm@cmu.edu>
Cc: drums@cs.utk.edu
In-Reply-To: <Pine.LNX.3.91.960306153951.348A-100000@laptop79.ietf.interop.net>
Message-Id: <MailManager.826147236.7721.mrc@Ikkoku-Kan.Panda.COM>
Mime-Version: 1.0
Content-Type: TEXT/PLAIN; CHARSET=US-ASCII

On Wed, 6 Mar 1996 15:47:54 -0500 (EST), John Gardiner Myers wrote:
>   Canonical encoding model (822 3.4.10)
>     unix-style is an encoding of message format where CRLF encoded as LF

Other than to document this, what is the purpose of this?  I would prefer that
we not get into the newline rathole.

>   Specify precedence of operators.  Unary prefixes highest,
>   concatination lower, alternatives lowest.

Agreed, with caveat that whenever possible, parenthesis grouping or use of
additional rules is preferable to using precedence for disambiguating syntax.
Otherwise, it quickly becomes unreadable.

>   Add new ABNF notation:
> 	a ::+ b
> 	a ::+ c
> 	a ::+ d
>   is equivalent to:
> 	a ::= (b) / (c) / (d)

What is this for?  Document revisions?  I think this should be banned from any
base documents, although supplemental or revision documents may find it
useful.

> 	field           ::=  field-name ":" [LWSP-char] [ field-body ] CRLF
> 				; any single LWSP-char after ":"
> 				; is not part of the field-body
>       field-name	::=  1*<any CHAR, excluding CTLs, SPACE, and ":">
> 	field-body	::=  field-body-contents
> 		             [CRLF LWSP-char field-body]
> 	field-body-contents ::=
>                    <the ASCII characters making up the field-body, as
>                     defined in the following sections, and consisting
>                     of combinations of atom, quoted-string, and
>                     specials tokens, or else consisting of texts>
> 		; XXX above definition needs to be fixed
> 		; XXX prohibit NUL, CR, and LF
				; is not part of the field-body

I have a problem with this.  I know what you're trying to say here, and it
makes sense in context, but someone is going to be confused when he encounters
a field-name followed by an LWSP-char and thinks that this syntax bans it.
It's also much too complicated.

Better would be to require field-body-contents to begin with non-LWSP,
something like:
	field           ::=  field-name ":" [ field-body ] CRLF
	field-body	::=  ptext *text [CRLF field-body]
	ptext		::= <any text excepting linear-white-space>

The issue of prohibiting NUL, CR, and LF is separate and I would rather have
it be treated separately.  Let's agree upon these rules first, then deal with
NUL/CR/LF separately.

>        New requirement: continuation line must contain non-whitespace
>	 character

I have a problem with this.  I know why it's here (broken software) but it
causes interoperability problems with compliant software.  I would prefer that
it be brought up for discussion.

> FIELD DEFINITIONS
> 	fields		::= [ trace ]                  ; net traversals
> 			    orig-date                  ; Creation time,
> 			    source                     ; author id required
> 	                    *destination               ;
> 	                    *optional-field            ;
> 			    *resent		       ;
> 	; XXX fix dangling nonterminal "optional-field"

This comes about since you renamed optional-field to reference fields.

I would like to see Message-ID and Subject be required.


>   Originator (Like term "author" better)
> 	source		::= originator                 ; original mail
>
> 	originator	::= authentic                  ; authenticated addr
> 		             [ "Reply-To"   ":" 1#address] )
>
> 	authentic	::=   "From"       ":"   mailbox  ; Single author
>                  / ( "Sender"     ":"   mailbox  ; Actual submittor
>                      "From"       ":" 1#mailbox) ; Multiple authors
>                                                  ;  or not sender

Let me be make a radical proposal: simplify all of this to be:
	source		::= "From" ":" 1#address
			    ["Sender" ":" 1#address]
			    ["Reply-To" ":" 1#address]

The rules for when you can have multiple entities, and when you can have an
address and when it must be a mere mailbox, are just too complicated.  I know
what they are trying to do, but it isn't worth it.  Nobody really believes
that the "Sender" is authentic, and the address vs. mailbox dichtomy is more
than a little bit silly.

>   Resending

Should have ReSent-Subject.

> 	local-part	::=  quoted-string
> 			     / (atom *("." atom))
> 						; uninterpreted
>                                                 ; case-preserved
>
> 	domain		::= (atom 1*("." atom)) / domain-literal
> 		; XXX 1* is a change
> 		; Note no trailing dot.
> 				;; no free insertion of whitespace
>
> 	domain-literal	::=  "[" (atom 1*("." atom)) "]"
> 		; XXX perhaps use "[" 1*DIGIT 3*("." 1*DIGIT) "]"
> 				;; no free insertion of whitespace
>     Single space exists between contiguous words in phrase (3.4.4 prgh 2)
> 	phrase		::=  word *( (SPACE / [ [SPACE] "." [SPACE] ]) word)
> 						; Sequence of words
> 		;; XXX Note relaxation to permit unquoted "."
> 		;;     Check for consensus

Ugly!!!!!!!!!!!!!!   See radical suggestion below.

> 	specials	::=  "(" / ")" / "<" / ">" / "@"  ; Must be in quoted-
> 	                 /  "," / ";" / ":" / "\" / <">  ;  string, to use
>         	         /  "." / "[" / "]"              ;  within a word.

Radical suggestion: remove ".", "[", and "]" from specials.  Move the
specification of a domain-literal to some other specification.

Huge simplification of the protocol.  There is no need for "." to be a
special.