Re: New 2822upd-04 - obs-NO-WS-CTL

"Frank Ellermann" <[email protected]>
Newsgroups gmane.ietf.rfc822
Organization <http://purl.net/xyzzy>
Message-ID <[email protected]>
Pete Resnick wrote:

> Try this instead:

Thanks.  As soon as an I-D is available on the Tools server
the "diff" links in the HTML output can compare N+1 and N.
 
> If you want the comparison to 2822 itself, try this:

For now I consider -03 as "known good", and try to figure 
out if -04 is "better".  Points as I see them (top down):

* 3.2.2
  <ctext> is supposed to be VCHAR minus "(", ")", and "\",
  the syntax says decimal 33..39 and 93..126.  Please add
  41..91 again.

* 3.4.1
  <quoted-pair> in <dcontent>, compare Charles' and Ned's
  comments.  As far as this allows for \[, \\, and \] in a
  <domain-literal> I'm not aware of any case (incl. MIXER)
  where this is needed.  If this allows any <quoted-pair>,
  because that's as it was in RFC 2822 I'm curious what an
  "interop" report will say (good, bad, or ugly).  Outside
  of a Message-ID I'm not very hot about it.

  <obs-dtext> is harmful, there are no domain literals with
  NO-WS-CTL, please kill this obscenity or show me where it
  was needed. 

* 3.5, 3.6.2, 3.6.3, 3.6.5
  Missing blank lines between prose and syntax.  I never
  got that effect with xml2rfc, your figure-artwork-ABNF
  magic must be different from what I use.

* 3.6.4
  "Though optional, every message SHOULD" [...].  Please
  remove "though optional", an unqualified SHOULD already
  takes care of obsolete implementations.  

  Why are In-Reply-To and References simultaneously 
  recommended (SHOULD), how about limiting the In-Reply-To
  SHOULD to messages without References ?  Nothing's wrong
  if a message has only References, or is it ?

| later in this section, the use of a domain name or 
| literal Internet address is RECOMMENDED for the [RHS]

  "Recommending" a domain literal is not what RFC 822 did:
     THE USE OF DOMAIN-LITERALS IS STRONGLY DISCOURAGED.
  At least for a Message-ID a domain literal can be a bad
  idea, IMO it's a last resort before trying random garbage.

  For <no-fold-literal> see above, no <quoted-pair>, please.

  <obs-id-right> points back to <domain>, that forward to
  <obs-domain>, back to dot-separated <atom>s with <CFWS>,
  shudder.  But you got rid of obs-NO-WS-CTL in <dcontent>,
  good.  Maybe move <obs-id-right> from 4.5.4 to 4.4, ditto
  <obs-id-left>, historically that's where they belong to.

[I ignore further missing empty lines between prose + ABNF]

* 3.6.8 (matter of taste)
  You could now write 'VCHAR excl. ":"' in the <ftext>
  comment, or 'printable US-ASCII excluding ":"' similar
  to what you have for <qtext>.  It's not more necessary
  to mention that <ftext> can't contain SP and control.

* 4.1
  <obs-NO-WS-CTL> also doesn't include NUL, fortunately.
  How about dropping the obs- prefix from obs-NO-WS-CTL ?
  It's anyway not used outside of the the obs-chapter 4.

  Oops, 4234bis "forgot" to define NUL forcing you to say
  %d0.  But 4234bis mentions NUL in a comment.  Maybe NUL
  could be still added in AUTH48 to 4234bis (?)
 
  <obs-qp> boils down to "CTL minus HTAB", maybe note it
  as ABNF comment.  The full syntax is necessarily clumsy.

  You got rid of <obs-text>, now that surprises me.  It
  was used in <text>, indirectly <quoted-pair> (killed),
  indirectly <body> (???), and <obs-utext>.

  The bare CR or bare LF magic went from <obs-utext> to
  <obs-unstruct>, that should be okay.  But <VCHAR> in
  <obs-utext> is wrong, it's covered by <unstructured>.

  I think you have lost NO-WS-CTL in <obs-body>, I fear
  you need it, as soon as you have NUL anything goes :-(

4.5.4
| Semantically, none of the optional CFWS surrounding the
| local-part and the domain are part of the obs-id-left
| and obs-id-right respectively.

  Ditto CFWS within <obs-domain>, see comment for 3.6.4.

Thanks, great progress wrt NO-WS-TL.  And yes, I think
that the NetNews "magic SP" should be limited to NetNews.

 Frank
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.