ietf-822
[Top] [All Lists]

Re: draft-ietf-usefor-article-09

2003-02-26 14:14:36

Charles Lindsey wrote:

Here are the diffs from the latest snapshot on the landfield site. Please
respond quickly if you spot any obvious howlers.

+ [Tentative paragraph to deal with IMAP]
+ + This requirement includes the transmissiom paths between posting
+    agents, injecting agents, relaying agents, serving agents and reading
+    agents, but it does NOT include paths traversed by Netnews articles
+    that have been converted to Email (8.8.1.1).  In particular, this
+    means that IMAP4 servers which provide access to Netnews SHOULD
+    implement the extension described in section 4.4.3.

IMAP is not Email only as implied.  IMAP handles all 822/2822/MIME
messages, including news.  IMAP *is* on "the transmission path [...]
and reading agents".

!    are potentially available.  Although it will usually be unnecessary
!    to use language tagging within headers, the tagging facilities
!    provided in [UNICODE 3.2] (code points U+E0000 through U+E007F) MAY
!    be used for that purpose.

That's not consistent with RFC 2277's requirement that language
be preserved in the protocol; it can't be buried in non-standard
tags buried inside the charset -- it has to use RFC 3066 standard
language tags (in the subset of ASCII specified in 3066, not
translated to some whacko range and then further obfuscated
by a UTF, unless there is a clear and solid justification for
departing from 3066).  Moreover it cannot be made dependent on
charset support; preservation of the language information is
required even if the charset is not supported.

+ 4.4.3.  The NEWS-8BIT-HEADERS IMAP Extension
+ [This section is highly tentative, and serves as a placeholder to
+ indicate that an IMAP extension will be needed in order to ensure
+ consistency with the present form of this draft. It shows the minimum
+ extension that seems to be necessary, and would require significant
+ further work for any final version.]
+ The current IMAP4 protocol [RFC 2060] forbids 8-bit character in

"current" should be elided; that aspect of the protocol has not changed.
"character" should be "characters".

+    headers (so as to conform with the previous Netnews standard [RFC
+    1036] amd with the current Email standards).
+ [That reference to RFC 2060 should be changed to refer to [RFC 2060bis]
+ if that has been accepted by the time this standard is published.]
+ + Implementations of IMAP4 conforming to this extension MUST + + 1. In the case of Netnews messages only, accept 8-bit octets in
+       headers (part specifiers HEADER or MIME, or the header portion of
+       a MESSAGE/RFC822 part) and pass them on to the client unchanged in
+       any FETCH response;

There is no way to distinguish "Netnews" messages from any other
messages.  This text contradicts RFC 2046 section 5.2.1 which requires
that header fields in message/rfc822 be 7-bit. This WG has no
authority to change the definition of MIME message/rfc822.

What about multipart composite media types? RFC 2046 section 5.1
requires MIME header fields in multipart types be in 7-bit
US-ASCII (possibly including 2047 encoded-words representing
8-bit text) only.  Why the disparate treatment?

Where is 8-bit header content negotiated by the sender *before* presenting
the data to an IMAP server (which might well be via placing an article
in a news spool area)?  Where is the requirement that the *sender*
fall back to RFC 1036/822/2822/MIME-compliant content in the event that
the IMAP sever does not support the extended syntax (i.e. in the default
case)?  Exactly how is this negotiation to take place, especially since
the IMAP server may be an autonomous process and may in fact be running
on a different machine accessing a common news spool via a file sharing
protocol such as NFS or SMB?

What about IMAP2?

***************
*** 1616,1624 ****
     The forms "UT" and "GMT" (indicating universal time) are to be
!    regarded as obsolete synonyms for "+0000". They MUST be be accepted,
!    and passed on unchanged, by all agents, but they MUST NOT be
!    generated as part of new articles by posting and injecting agents.
!    The date-time MUST be semantically valid as required by [RFC 2822].
!    Although folding white space is permitted throughout the date-time
!    syntax, it is RECOMMENDED that a single space be used in each place
!    that FWS appears (whether it is required or optional).
--- 1670,1678 ----
     The forms "UT" and "GMT" (indicating universal time) are to be
!    regarded as obsolete synonyms for "+0000". They MUST be accepted, and
!    passed on unchanged, by all agents, but they MUST NOT be generated as
!    part of new articles by posting and injecting agents.  The date-time
!    MUST be semantically valid as required by [RFC 2822].  Although
!    folding white space is permitted throughout the date-time syntax, it
!    is RECOMMENDED that a single space be used in each place that FWS
!    appears (whether it is required or optional).

The change seems to be line breaks only.  What is the meaning of "RECOMMENDED"
and how does that differ from the standard terms MAY and SHOULD?  Why the
special case for UT and GMT being unchanged -- that implies that anything else,
including standard numeric offsets, may be changed?  What about CFWS? Is a
space "RECOMMENDED" (whatever that means) where 2822 specifies CFWS (optional
or mandatory) rather than FWS?


<Prev in Thread] Current Thread [Next in Thread>
  • Re: draft-ietf-usefor-article-09, Bruce Lilly <=