Pete Resnick wrote:
See my response to Charles regarding obs- items in general. This
was (syntactically) allowed in previous versions.
For a DS it has to be implemented and needs to be interoperable in
some way, and "breaks in NetNews" would be suspicious, UAs for mail
and news likely support only one approach where possible.
I don't see how continuing to give fair warning in the "you might
have to interpret this" section is problematic.
UAs have to interpret any stream of random octets without crashing,
you could mention this in the prose if you think it helps. That's
not the same as "MUST accept NUL" (etc.) in odd places, where the
UA might need to talk with other software (e.g. address books).
It would be also confusing if we end up with an 2822upd Message-ID,
where the LHS is a proper subset of NetNews, and the RHS a superset.
Ideally you arrive at something that can be copied "as is" to the
NetNews RFC replacing what it says now in AUTH48. For that it has
to get rid of NO-WS-CTL (done, "obs" is by definition not allowed
in NetNews) and <quoted-pair> (not done, <dcontent> allows it).
Alternatively you could limit <quoted-pair> in the RHS to three
"necessary" cases (necessary for the hypothetical domain literals
"needing" \[, \\, or \] for some reason). If you do nothing it's
not good enough for the canonical Mesage-IDs needed in NetNews:
The Message-ID <local(_at_)[who\knows]> with \k is bad for a simple
comparison with <local(_at_)[whoknows]>. Don't ask me what a domain
literal [whoknows] is, you want it, IMO adopting the <IP-literal>
syntax from STD 66 (adding IPv4 of course) would be better.
If folks insist on using random garbage as RHS they don't need
to put it in square brackets to make it more interesting. For
some peculiar effects see the news: URL draft (that's also one
reason why I favour to adopt STD 66 syntax for domain literals).
What's the gain in ditching it?
Simpler parsers. MIME boundaries and RFC 2231 are another dark
corner, where syntax going to the limits can result in "let's
forget it and find a good heuristics". One of my scripts does
this, bad... :-(
* 3.6.4
[...]
How about, "Though listed as optional in the table in section
3.6..."?
+1 Looking for the table in the wrong direction I stumbled over
the IANA consideratins, I think you could trim the header field
registrations: IANA only has to update the existing pointers to
2822upd. Mentioning the status and the change controller once
in 2822upd should do. It's no exercise in bureaucracy, it's for
header field registry users looking for a relevant specification.
An exception is the obsolete Resent-Reply-To, IANA has to flag it
as obsolete. IANA set the initial pointers *to* RFC 4021 instead
of the specifications and status listed *in* RFC 4021 ;-)
Back to your table, it doesn't say "optional", it says "0*" with
a note "SHOULD be present - see 3.6.4". The lower case optional
makes me nervous, it could be confused with a 2119 OPTIONAL.
[In-Reply-To]
The conservative move seems to me to keep the language as-is.
Okay, let's say that a news2mail gateway is a good excuse to
ignore this SHOULD, trying to derive In-Reply-To from References
would be a bad idea.
How about, "later in this section, the use of a domain
identifier is RECOMMENDED...."?
+1
Avoid the issue. I don't want to overly obfuscate the point
here.
Somewhere you have to say that domain literals are generally a
bad idea, I don't find this statement at the moment in 2822upd.
It's so fundamental that a verbatim copy from 822 would be fun:
THE USE OF DOMAIN-LITERALS IS STRONGLY DISCOURAGED.
But you got rid of obs-NO-WS-CTL in <dcontent>, good.
Nope. <dcontent> has <dtext> which has <obs-dtext> which is
obs-NO-WS-CTL.
Kill it, take no "obs" prisoners. "Strongly discouraged" plus
"obs" plus "never used" is a clear kill. If the interop report
says that NO-WS-CTL in domain literals is precisely what e-mail
needs in 2008 you can simply reinsert it, but I guess it won't.
The <dcontent> also affects 2821bis. The last state I know is
to introduce a special <SMTP-dcontent> without (obs-) NO-WS-CTL
for SMTP's variant of "IPvFuture" - of course different from
the "IPvFuture" in STD 66, confusing implementors... <sigh />
I like everything in section 4 to start with obs-. A stylistic
thing.
Squeezing obs-NO-WS-CTL into 69 columns for the ABNF is tricky,
my own style requires all "=" in the same column. "Beautiful"
ABNF tends to convince me that it can't be completely wrong ;-)
Just explaining why I proposed to drop the "obs" in this case,
if you don't run into length issues or just use other stylistic
priorities it's of course okay.
(*Shrug*) Doesn't seem all that informative to me since
quoted-pair, which is the only place that obs-qp appears,
already has HTAB.
Yes, I thought that the <obs-qp> syntax isn't obvious for the
purpose to enumerate CTL minus HTAB, no important point, just
what I saw top down.
<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.
Right, I first wrote utext, found that it's gone, and replaced
it by unstructured. Missing that the "bare-magic" must also
work for VCHAR.
If that makes it clearer, I could do that.
No, future readers won't know what <utext> used to be, the
<obs-utext> syntax is clear as is, my bad.
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.
%d6 :-)
How about, "Semantically, none of the optional CFWS in
the local-part and the domain..."?
+1
Frank