headers
Bruce Lilly | 3 Feb 2003 18:50
Picon

Re: RFC 2231 and CFWS


Charles Lindsey wrote:

> Thanks for the pointer to RFC 2978. I see that '%' is also allowed, but
> not '*'. So writing a foolproof parser for extended-initial-value would be
> tricky (you have to scan from R to L until you have identified the two
> rightmost "'"s), but I doubt implementors will bother to go so far.

That is not the only way to skin that particular cat; a grammar-based
parser can easily handle extended parameters including a hypothetical
charset name containing a single quote and/or percent sign without
resorting to reverse scanning -- it's handled by the normal parser
state machine stack.  It's not even particularly "tricky" -- one
simply writes the appropriate grammar rules and it just works.
Permalink | Reply | 9 comments |
headers
Bruce Lilly | 3 Feb 2003 20:37
Picon

Re: Language Tagging within Unicode

Charles Lindsey wrote:
> This message is addressed primarily to Martin Duerst, but is Cced to
> the Usefor and ietf-822 lists. Will people replying please ensure that
> Martin is copied, since I am not aware that he regularly reads either of
> those lists.
> 
> 
> There currently appears to be some confusion between the Unicode community and
> the Email community as to the correct usage of Language Tagging.
> 
> Within Unicode (since version 3.1) there have existed the Tag Characters
> U+E0000-U+E007F which can, in principle, change the language over and over
> again within a single text.
> 
> However, there are discouraging remarks about the use of this facility:
> 
>     ... However, the use of these characters is strongly discouraged. The
>     characters in this block are reserved for use with special protocols.
>     They are not to be used in the absence of such protocols, or with any
>     protocols that provide alternate means for language tagging, such as
>     HTML or XML.  The requirement for language information embedded in
>     plain text data is often overstated. ...
> 
> (However, there is no defined list of those "special protocols".)

There is; one of the Unicode documents related to the introduction
specifically mentions ACAP as the intended use, as has been pointed
out several months ago on the Usefor list when this topic first came
up, and repeated recently. A search for "ACAP" on the Unicode web
site takes one right to the document and highlights the relevant text.
(Continue reading)

Permalink | Reply | 3 comments |
headers
Bruce Lilly | 3 Feb 2003 22:29
Picon

Re: Transformation of Non-ASCII headers

Charles Lindsey wrote:
> In <3E32A979.5080904 <at> erols.com> Bruce Lilly <blilly <at> erols.com> writes:
> 
> 
>>Charles Lindsey wrote:
> 
> 
>>>In <3E2EB579.5080200 <at> erols.com> Bruce Lilly <blilly <at> erols.com> writes:
>>> 
>>>
>>>
>>>>1. The draft is incompatible with the MIME standards ...
>>>
>>>The existing MIME standards relate only to Email.
>>>
>>
>>Untrue; MIME has many uses, including HTTP and voice messaging.
> 
> 
> The only reason that MIME applies to HTTP is that RFC 2616 explicitly
> declares it to be so (modulo some small changes). So the MIME standards do
> not currently apply to Netnews (but our draft will fix that).

Incorrect; RFC 1036 specifically mentions that news articles use the
text message format defined in RFC 822, and RFC 2047 explicitly revises
the RFC 822 ABNF for phrase and for comment to permit encoded-words
(see RFC 2047 section 5 which clearly and unambiguously spells this out).
So in the specific case of encoded-words (which is the topic under
discussion), MIME has applied to news for at least a decade (since
RFC 1342).
(Continue reading)

Permalink | Reply | 22 comments |
headers
Henry Spencer | 3 Feb 2003 22:45

Re: Transformation of Non-ASCII headers

On Mon, 3 Feb 2003, Bruce Lilly wrote:
> > ...So the MIME standards do
> > not currently apply to Netnews (but our draft will fix that).
> 
> Incorrect; RFC 1036 specifically mentions that news articles use the
> text message format defined in RFC 822, and RFC 2047 explicitly revises
> the RFC 822 ABNF...

However, RFC 1036 refers specifically and explicitly to RFC 822, *not* to
"RFC 822 or any update thereof".  RFC 2047, like other post-822 updates to
mail standards, does not apply to news unless we make it so. 

                                                          Henry Spencer
                                                       henry <at> spsystems.net
Permalink | Reply | 17 comments |
headers
Bruce Lilly | 3 Feb 2003 23:16
Picon

Re: Transformation of Non-ASCII headers

Henry Spencer wrote:

> However, RFC 1036 refers specifically and explicitly to RFC 822, *not* to
> "RFC 822 or any update thereof".  RFC 2047, like other post-822 updates to
> mail standards, does not apply to news unless we make it so. 

OK, guys, you heard Henry -- no more of that 4-digit year nonsense
in dates.

Yeah, right; everybody on Usenet is going to go back to 2-digit
years, just like it says in RFC 822.
Permalink | Reply | 13 comments |
headers
Henry Spencer | 3 Feb 2003 23:47

Re: Transformation of Non-ASCII headers

On Mon, 3 Feb 2003, Bruce Lilly wrote:
> > However, RFC 1036 refers specifically and explicitly to RFC 822, *not* to
> > "RFC 822 or any update thereof".  RFC 2047, like other post-822 updates to
> > mail standards, does not apply to news unless we make it so. 
> 
> OK, guys, you heard Henry -- no more of that 4-digit year nonsense
> in dates.
> Yeah, right; everybody on Usenet is going to go back to 2-digit
> years, just like it says in RFC 822.

We were talking about what the documents say, not about what is actually
being done on the net -- a gap that is particularly wide where non-ASCII
character sets are concerned. 

Your claim, since you seem to have forgotten it, was that since RFC 1036
references RFC 822, MIME (an extension and amendment to 822) automatically
applies to news as well.  Whether it *should* apply to news, and whether
it is being used *as if* it does, are separate (although related) topics. 

Since you have changed the subject, I assume you have conceded your error. 

                                                          Henry Spencer
                                                       henry <at> spsystems.net
Permalink | Reply | 9 comments |
headers
Keith Moore | 3 Feb 2003 23:55
Picon

Re: Transformation of Non-ASCII headers


> > The only reason that MIME applies to HTTP is that RFC 2616 explicitly
> > declares it to be so (modulo some small changes). So the MIME standards do
> > not currently apply to Netnews (but our draft will fix that).
> 
> Incorrect; RFC 1036 specifically mentions that news articles use the
> text message format defined in RFC 822, and RFC 2047 explicitly revises
> the RFC 822 ABNF for phrase and for comment to permit encoded-words
> (see RFC 2047 section 5 which clearly and unambiguously spells this out).
> So in the specific case of encoded-words (which is the topic under
> discussion), MIME has applied to news for at least a decade (since
> RFC 1342).

RFC 1036's claims notwithstanding, news and email use different message
formats, with different header fields and different interpretations and syntax
for some of the fields that share a common name.  So it's not clear that
2047's revision of the 822 syntax for the purpose of emailed MIME messages
automatically applies to use of a syntax that was derived from 822 for the use
in netnews.  Second, it's doubtful that changing the format of netnews would
have been consistent with the 822ext working group's charter.   Third,
applicability of MIME to Usenet is not something that has been considered when
advancing MIME on the standards track. If we were to consider the rate of
adoption of MIME within the Usenet community, MIME would probably best be
classified as "experimental" for that purpose.  Finally it would set a bad
precedent if every revision of 822 for email purposes were deemed to change
every use of an 822-like syntax (for instance, in HTTP or SIP).  It's good
that we borrow proven designs for use in new protocols, but each protocol has
its own needs and its own user community and different protocols need to be
allowed to evolve separately.
(Continue reading)

Permalink | Reply | 0 comments |
headers
ned+ietf-822 | 4 Feb 2003 00:07

Re: Transformation of Non-ASCII headers


> Henry Spencer wrote:

> > However, RFC 1036 refers specifically and explicitly to RFC 822, *not* to
> > "RFC 822 or any update thereof".  RFC 2047, like other post-822 updates to
> > mail standards, does not apply to news unless we make it so.

> OK, guys, you heard Henry -- no more of that 4-digit year nonsense
> in dates.

> Yeah, right; everybody on Usenet is going to go back to 2-digit
> years, just like it says in RFC 822.

Er, exactly.

I'm sorry, but it has been long been understood that references can deemed to
track to subsequent revisions of a specification without explicit revision to
point to the newer version. This is the sort of situation where common sense
has to prevail. Trying to find and fix every RFC each time a document it refers
to is itselft revised would be a huge waste of time.

As such, there is a lot less to be read into the specific reference to RFC 822
in RFC 1036 than people seem to think.

				Ned
Permalink | Reply | 0 comments |
headers
Bruce Lilly | 4 Feb 2003 01:11
Picon

Re: Transformation of Non-ASCII headers

Henry Spencer wrote:
> On Mon, 3 Feb 2003, Bruce Lilly wrote:
> 
>>>However, RFC 1036 refers specifically and explicitly to RFC 822, *not* to
>>>"RFC 822 or any update thereof".  RFC 2047, like other post-822 updates to
>>>mail standards, does not apply to news unless we make it so. 
>>
>>OK, guys, you heard Henry -- no more of that 4-digit year nonsense
>>in dates.
>>Yeah, right; everybody on Usenet is going to go back to 2-digit
>>years, just like it says in RFC 822.
> 
> 
> We were talking about what the documents say, not about what is actually
> being done on the net -- a gap that is particularly wide where non-ASCII
> character sets are concerned. 
> 
> Your claim, since you seem to have forgotten it, was that since RFC 1036
> references RFC 822, MIME (an extension and amendment to 822) automatically
> applies to news as well.  Whether it *should* apply to news, and whether
> it is being used *as if* it does, are separate (although related) topics. 

Apparently the satire was too subtle.  So here's the long version:

Just as RFC 1123 section 5.2.14 amended the 822 syntax for date, RFC 1342
amended the syntax for phrase and comment (and in the latter case with
far less impact on parsers, since an encoded-word still matches atom (in
word) in a phrase and ctext in a comment).  We didn't have to wait for
2822 to say that date-time in a text message could use 4-digit years; as
soon as RFC 1123 took effect that was the case.  For encoded-words, the
(Continue reading)

Permalink | Reply | 7 comments |
headers
Keith Moore | 4 Feb 2003 01:22
Picon

Re: Transformation of Non-ASCII headers

> Just as RFC 1123 section 5.2.14 amended the 822 syntax for date, RFC 1342
> amended the syntax for phrase and comment (and in the latter case with
> far less impact on parsers, since an encoded-word still matches atom (in
> word) in a phrase and ctext in a comment). 

Actually, no.  There was a difference in intent between the two.  1123 was 
imposing new requirements on existing protocols, 1341 and 1342 were not
doing so.  MIME implementation was not mandatory (as a matter of standards 
compliance) for existing user agents.

Keith
Permalink | Reply | 5 comments |

Gmane