Re: Last Call: Originator-Info Message Header to Experimental

[Ned Freed <Ned.Freed at innosoft.com>]

> I am in favor of the proposed Originator_Info header, but the Devil is
> in the details. Specifically, I question the wisdom of prohibiting use
> of the attributes in filters, and I strongly disagree with the
> specification of  character set.

> While it is true that the header can be trivially forged, that does
> not  not provide adequate grounds for a MUST NOT. If I choose to use
> the  contents of this header for purposes of authorization, no harm to
> the net occurs, although I may cause harm to myself. Even a SHOULD NOT
> is questionable.

I disagree. First of all, I generally believe that standards documents need to
actively discourage practices that are demonstrably harmful. It isn't
sufficient to remain neutral on such matters.

Second, the "net" isn't some abstract thing separate from actual systems and
users. The net is the sum of its parts, including these things. If a system
implements poor authorization policies based on bogus header information, I see
this as harming the "net" in a fairly direct sense.

Third, the problem with not prohibiting this sort of thing is that
inexperienced people will then demand that implementations use it in
inappropriate ways. And implementors, even when they know better, can be forced
to do really bad things by this sort of customer pressure. About the only
defense we have from this is standards documents which not only explain what
should be done, they also explain what should not be done, and why.

However, I believe the present text on this point is probably inadequate, as it
doesn't give reasons for the prohibitions it makes.

> Given the current direction of internationalization, I don't see why
> any choice of character encoding other than UTF-8 makes sense. Use of
> MIME means that attributes will be unreadable by those not possessing
> the appropriate character sets, even if they have all of the glyphs.
> The only advantage that I can see for MIME is in distinguishing the
> oriental languages that have been "unified" in Unicode.

I have no problem with recommending that UTF-8 SHOULD be used in cases where
US-ASCII isn't adequate. Indeed, I think doing so would be a good idea, and
support the addition of a statement to this effect.

However, it is possible that disallowing other charsets will prevent this
mechanism from being used in some cases, and this I don't want to have happen.
The primary goal here is to get as much buy-in as possible to this scheme. I'd
rather see information get logged in a zillion different charsets (a clearly
extreme case that isn't going to happen, of course) than not have it logged at
all, or worse, have it logged in entirely inappropriate places like the Sender:
field.

I also agree with changing "multinational" to "multilingual" per Martin's
suggestion, but I must say I see this as a largely editorial change, not a
major problem with the document. And as for the MAYs in there, I agree with
Martin's assessment of what's intended and his suggested rewording.

				Ned