Subject: [Ltru] Re: The most perverse tag, plus a comment on fine-tuning

From: "Doug Ewell" <[email-masked]>
Date: Sun, 5 Jun 2005 10:43:57 -0700

Randy Presuhn <randy underscore presuhn at mindspring dot com> wrote:

> As a technical contributor, I don't find the limitations of existing
> applications very persuasive, since we're adding features.  I *do*
> find the limitations of existing *protocols* that use language tags
> more relevant, (though not decisive) since they will have a longer
> term impact on what can actually be used.  However, if we learn that
> protocol FOO, for example, uses language tags and has a field of at
> most 3 octets to hold them, we should think hard before letting that
> be the tail that wags this dog.

I'm using the word "application" in the sense I think most group members
intend, to mean something closer to "protocol" than "implementation."  I
agree that existing code does not matter, except perhaps in ways having
to do with matching, which the matching document should address.

As for existing protocols, it seems clear to me (as to Randy) that the
draft must not be driven by a protocol that assumes, say, that a
language tag can only be LL or LL-CC (and thus can't even handle RFC
1766 registered tags).

RFC 2047, as extended by 2231, has its "encoded word" limit that has
been discussed repeatedly on this list, and seems to be a good example
of a "straight Internet" protocol that uses language tags (i.e. one that
cannot be claimed to belong only to W3C, Unicode, etc.).  This is a
widely used protocol and might amount to an awfully big tail, if you
will.  It might be reasonable to consider the encoded-word-based limit
that has been mentioned before (30-something? I've forgotten) for this
purpose.

BTW, as I read more RFCs that are comparable in scope to the present
draft, I can't help noticing the broad and general statements and even
errors that some of them contain, of the type which have been debated
endlessly within this group, and which -- if allowed to stand
uncontested in the present draft -- would have been considered
deal-breakers.  For example, without casting any aspersions on the
authors of RFC 2231 for human error, it does specify the following ABNF
statement:

encoded-word := "=?" charset ["*" language] "?" encoded-text "?="

instead of the correct

encoded-word := "=?" charset ["*" language] "?" encoding "?"
encoded-text "?="

which was not reported as an erratum until four years had passed.
Compare this to the extremely detailed fine-tuning and scrutiny to which
the ABNF of the present draft has been subjected.

Likewise, the Security Considerations section for RFC 2231 says in its
entirety: "This RFC does not discuss security issues and is not believed
to raise any security issues not already endemic in electronic mail and
present in fully conforming implementations of MIME."  Compare that to
the discussions over homographs and mistagging and the like that have
gone on within this group.  And remember, RFC 2231 is a standards-track
document.  Is it just that the bar of scrutiny has been raised that much
since 1997?

--
Doug Ewell
Fullerton, California
http://users.adelphia.net/~dewell/

_______________________________________________
Ltru mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/ltru