[Top] [All Lists]

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

2008-01-16 18:25:50

On 1/17/08 at 12:09 AM +0100, Frank Ellermann wrote:

* 3.2.2

Yup, Charles mentioned. Fixed.

* 3.4.1
  <quoted-pair> in <dcontent>

I'll let this discussion play out.

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

See my response to Charles regarding obs- items in general. This was (syntactically) allowed in previous versions. I don't see how continuing to give fair warning in the "you might have to interpret this" section is problematic. And you ought not be writing code that simply crashes if you encounter one of these. What's the gain in ditching it?

* 3.5, 3.6.2, 3.6.3, 3.6.5
  Missing blank lines between prose and syntax.

Yes. I mentioned that in my initial message. Will fix before release.

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

I wasn't refering to anything obsolete here. How about, "Though listed as optional in the table in section 3.6..."?

  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 ?

(Scraping the bottom of my memory...) I believe the point was that (a) some implementations might depend on In-Reply-To and (b) In-Reply-To was necessary if a reply was to multiple messages. Personally, I only know one independent implementation of (b), and I'm not sure about (a). The conservative move seems to me to keep the language as-is.

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

  "Recommending" a domain literal

How about, "later in this section, the use of a domain identifier is RECOMMENDED...."? Avoid the issue. I don't want to overly obfuscate the point here.

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

Again, I'll let that discussion play out.

  <obs-id-right> points back to <domain>, that forward to
  <obs-domain>, back to dot-separated <atom>s with <CFWS>,

Life's tough all over.

  But you got rid of obs-NO-WS-CTL in <dcontent>,

Nope. <dcontent> has <dtext> which has <obs-dtext> which is obs-NO-WS-CTL.

Maybe move <obs-id-right> from 4.5.4 to 4.4, ditto
  <obs-id-left>, historically that's where they belong to.

I like it where it is.

* 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.

Will do.

* 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.

I like everything in section 4 to start with obs-. A stylistic thing.

  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 (?)

That's up to Dave and Paul. It makes little difference to me, but I'll use it if it's there.

  <obs-qp> boils down to "CTL minus HTAB", maybe note it
  as ABNF comment.  The full syntax is necessarily clumsy.

(*Shrug*) Doesn't seem all that informative to me since quoted-pair, which is the only place that obs-qp appears, already has HTAB.

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

Since body is now the only place text is used, and we've got to have an obs-body, there was no longer a need for obs-text.

  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>.

No, VCHAR is required there. obs-utext is not a alternative for utext. There is no utext. obs-unstruct is an alternative for unstructured, and in that alternative, a string of bare LFs and or bare CRs can be followed by a VCHAR. I could make obs-unstruct:

obs-unstruct    =   *((*LF *CR *((%d0 / obs-NO-WS-CTL / VHAR) *LF *CR)) / FWS)

and ditch obs-utext entirely, but then I'd have to break obs-unstruct over two lines. If that makes it clearer, I could do that.

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

text already contains everything from obs-NO-WS-CTL.

| 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.

How about, "Semantically, none of the optional CFWS in the local-part and the domain..."?

Thanks for the comments.

Pete Resnick <>
Qualcomm Incorporated - Direct phone: (858)651-4478, Fax: (858)651-1102