Re: Injection-Info issues

[Frank Ellermann <[e-mail]>]

Charles Lindsey wrote:
 
> the IANA registry for each media type includes details
> of all the parameters appropriate for that media type.

Checking draft-lilly-text-troff-04.txt and RfC 3676, yes,
it does.

> we have not proposed an IANA Registry for Injection-Info
> parameters (thoug we could if we were so minded).

Not at the moment.  Add authentication= with a reference
to the new NNTPauth, Russ said that this is a good idea.
Alexey would warn us if NNTPauth is blocked.

> Which means that <attribute>s are different from <token>s,
> which is what I said.

That didn't change "x-", 2045 had attribute := token, and
x-token is a special case of extension-token unrelated to
attribute.  

x-token is only used in mechanism (7bit, 8bit, etc.), in
subtype, and in type (indirectly), not in any parameter.

Maybe I should test x-9bit for the nonets in RfC 4042. 

> 2045 most certainly did "strange things" with <x-token>s,
> and <attribute>s inherit those same "strange things".

In my copy <attribute> comes nowhere near to any <x-token>,
<extension-token>, <iana-token>, or <ietf-token>.  It's in
"appendix A - collected grammar", the last three pages.

"x-attribute" does not exist, it's a hallucination.  If you
say that you want to create it from scratch it's fine, you
could use the SPF trick.  Or merge it with 2231 <shudder />

> You just tell people that, if they post through your server,
> then the Injection-Info header will identify them. If they
> don't like that, then they have to go to a different server.
> That is the EU law (slightly simplified, I grant you).

Anoymous and pseudonumous access is a right in a German law,
and the threads discussing this issue put together in a row
are worse than our "Re: ferences" here.  I'm not directly
affected, my favourite server is news.clara.net in the UK ;-)

> In general, the Americans are less squeamish :-( .

They can't spell privacy without a dictionary.  They don't
understand why any @gmail address is begging for a *PLONK*.

> That vulnerability is nothing to do with RFC 2231.

It's about MIME, and this part of the debate was about USEFOR
2.3 "MIME Conformance":

| User agents MUST meet the definition of MIME-conformance in
| [RFC2049] and MUST also support [RFC2231].

2049 is "minimal MIME conformance", 2231 did not update 2049.
Anyway, for USEFOR we need security considerations about 2231:

  MIME security considerations are discussed in [RFC2046].
  Note that applying some [RFC2231] extensions for parameters
  like multi-line paramters on a boundary parameter as defined
  in [RFC2046] might be abused to bypass simple algorithms
  trying to analyze MIME parts.

That's all.  Bye, Frank