[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: New 2822upd-04 - obs-NO-WS-CTL
On 1/17/08 at 12:09 AM +0100, Frank Ellermann wrote:
Yup, Charles mentioned. Fixed.
<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
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
* 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.
"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
| 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.
<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 <http://www.qualcomm.com/~presnick/>
Qualcomm Incorporated - Direct phone: (858)651-4478, Fax: (858)651-1102