headers
Shmuel (Seymour J.) Metz | 1 Aug 2004 03:03

Re: Document definitions

In <cee3mq$vnv$1 <at> gatekeeper.tmr.com>, on 07/30/2004
   at 02:38 PM, Bill Davidsen <davidsen <at> tmr.com> said:

>The best reason to avoid it is that someone would take it as a
>license  to put in advertising or some content not in the difinition,
>knowing  that it must be ignores.

You can't be serious. Someone wanting to do that would use an
X-header, and those have been there for a long time.

--

-- 
     Shmuel (Seymour J.) Metz, SysProg and JOAT
     Atid/2        <http://patriot.net/~shmuel>
We don't care. We don't have to care, we're Congress.
(S877: The Shut up and Eat Your spam act of 2003)
Permalink | Reply | 1 comment |
headers
Shmuel (Seymour J.) Metz | 1 Aug 2004 03:09

Re: Document definitions

In <20040730042304.GB16893 <at> dora.tertius.net.au>, on 07/30/2004
   at 02:23 PM, Thorfinn <thorfinn <at> tertius.net.au> said:

>What testable constraints?  "Accept" is a fairly meaningless word. 
>It just means "read the header and don't blow up".  Just about
>*anything* "accepts" MIME parameters.

In which case it is not a burdensome requirement.

>That's not the same as doing "the right thing" with MIME parameters.
>For that, you want "MUST parse", not "MUST accept".

Irrelevant, because until there is an RFC defining a new MIME
parameter, the "right thing" *IS* "read the header and don't blow up".

--

-- 
     Shmuel (Seymour J.) Metz, SysProg and JOAT
     Atid/2        <http://patriot.net/~shmuel>
We don't care. We don't have to care, we're Congress.
(S877: The Shut up and Eat Your spam act of 2003)
Permalink | Reply | 13 comments |
headers
Shmuel (Seymour J.) Metz | 1 Aug 2004 03:13

Re: Document definitions

In <4109BB54.6000304 <at> erols.com>, on 07/29/2004
   at 11:07 PM, Bruce Lilly <blilly <at> erols.com> said:

>I have read it, and have pointed out that it applies to generation,
>not to parsing.  Evidently you haven;t read that either.

What is evident to you and what is plausible are two different things.

>No, it needs to be considered before the *syntax* is introduced in a
>Standards Track RFC which per the WG charter is supposed to pay
>"particular attention to backward compatibility".

It was considered; that's why the draft does not introduce MIME
parameters for existing header fields.

--

-- 
     Shmuel (Seymour J.) Metz, SysProg and JOAT
     Atid/2        <http://patriot.net/~shmuel>
We don't care. We don't have to care, we're Congress.
(S877: The Shut up and Eat Your spam act of 2003)
Permalink | Reply | 5 comments |
headers
Shmuel (Seymour J.) Metz | 1 Aug 2004 03:17

Re: Document definitions

In <4109BA38.6080504 <at> erols.com>, on 07/29/2004
   at 11:02 PM, Bruce Lilly <blilly <at> erols.com> said:

>No it is not.

Do you have the remotest idea what a non sequitor is? The phrase
refers to a claim that one thing follows from another when in fact it
does not. It has nothing to do with whether the second claim is
plasible or true.

--

-- 
     Shmuel (Seymour J.) Metz, SysProg and JOAT
     Atid/2        <http://patriot.net/~shmuel>
We don't care. We don't have to care, we're Congress.
(S877: The Shut up and Eat Your spam act of 2003)
Permalink | Reply | 2 comments |
headers
Frank Ellermann | 1 Aug 2004 06:13
Picon
Picon

Re: Document definitions

Shmuel (Seymour J.) Metz wrote:

> It was considered; that's why the draft does not introduce
> MIME parameters for existing header fields.

Apparently there's no consensus to mention MIME parameters
at all in one of the USEFOR RfCs.  Good riddance, bye, Frank
Permalink | Reply | 0 comments |
headers
Thorfinn | 1 Aug 2004 17:30
Picon
Favicon

Re: Document definitions

On Sat 31 Jul 2004 at 10:09:35PM -0300, in <200408010209.i7129ufh024258 <at> jefferson.patriot.net>,
"Shmuel (Seymour J.) Metz" <Shmuel+gen <at> patriot.net> wrote:
> Thorfinn <thorfinn <at> tertius.net.au> said:
> >What testable constraints?  "Accept" is a fairly meaningless word. 
> >It just means "read the header and don't blow up".  Just about
> >*anything* "accepts" MIME parameters.
> In which case it is not a burdensome requirement.

No, just a totally pointless one.

> >That's not the same as doing "the right thing" with MIME parameters.
> >For that, you want "MUST parse", not "MUST accept".
> Irrelevant, because until there is an RFC defining a new MIME
> parameter, the "right thing" *IS* "read the header and don't blow up".

I dunno about you, but I find the idea of putting in a pointless
requirement that is trivially satisfied by doing nothing, rather, erm...
pointless.

If a future RFC wants to define a MIME parameter for an existing header,
that future RFC will have *exactly the same problem with getting
accepted and parsed correctly*, whether we say "MUST accept" or not in
*this* RFC.

That's my point - whether we say "MUST accept" or not, makes *absolutely
no difference*.  Why waste words and space?

Later,

  Thorf
(Continue reading)

Permalink | Reply | 10 comments |
headers
Bruce Lilly | 1 Aug 2004 21:13
Picon

Re: Document definitions

Shmuel (Seymour J.) Metz wrote:

> It was considered; that's why the draft does not introduce MIME
> parameters for existing header fields.

Why do you keep repeating that lie? Path is an existing field.
Newsgroups is an existing field. Lines is not only an existing
field, it's deprecated and likely to be dropped -- now explain
exactly why it has to have *new* syntax introduced at this time.
Permalink | Reply | 3 comments |
headers
Bruce Lilly | 1 Aug 2004 21:21
Picon

Re: Document definitions

Shmuel (Seymour J.) Metz wrote:
> In <4109BA38.6080504 <at> erols.com>, on 07/29/2004
>    at 11:02 PM, Bruce Lilly <blilly <at> erols.com> said:
> 
> 
>>No it is not.
> 
> 
> Do you have the remotest idea what a non sequitor is?

I know very well what it means.

> The phrase
> refers to a claim that one thing follows from another when in fact it
> does not. It has nothing to do with whether the second claim is
> plasible or true.

To recap the recent conversation (since you seem to have felt it
necessary to snip everything so that you could assert a claim of
non-sequitur):

Shmuel:
>Failure to provide syntax is not the same as precluding the syntax in
> a subsequent RFC.

Bruce:
>failing to provide for so-called MIME parameters in
>>non-MIME fields does not preclude adding the syntax in a future RFC.

There's no non-sequitur there. There simply is no need at this time
(Continue reading)

Permalink | Reply | 1 comment |
headers
Bruce Lilly | 1 Aug 2004 21:32
Picon

Re: Document definitions

Shmuel (Seymour J.) Metz wrote:
> In <20040730042304.GB16893 <at> dora.tertius.net.au>, on 07/30/2004
>    at 02:23 PM, Thorfinn <thorfinn <at> tertius.net.au> said:
> 
> 
>>What testable constraints?  "Accept" is a fairly meaningless word. 
>>It just means "read the header and don't blow up".  Just about
>>*anything* "accepts" MIME parameters.
> 
> 
> In which case it is not a burdensome requirement.

Nor does it do anything to pave the way for interpretation of
such parameters -- the *only* excuse given to date for introducing
such syntax at this time.  The only thing that would do that would
be full parsing.
Permalink | Reply | 1 comment |
headers
Shmuel (Seymour J.) Metz | 1 Aug 2004 19:37

Re: Document definitions

In <20040801153005.GB17926 <at> dora.tertius.net.au>, on 08/02/2004
   at 01:30 AM, Thorfinn <thorfinn <at> tertius.net.au> said:

>No, just a totally pointless one.

Not pointless, because *IF* an RFC is accepted that adds a MIME
parameter, having the requirement here will allow for a quicker
phasein.

>If a future RFC wants to define a MIME parameter for an existing
>header, that future RFC will have *exactly the same problem with
>getting accepted and parsed correctly*, whether we say "MUST accept"
>or not in *this* RFC.

Not if some of the work has already been done as a result of this RFC.

--

-- 
     Shmuel (Seymour J.) Metz, SysProg and JOAT
     Atid/2        <http://patriot.net/~shmuel>
We don't care. We don't have to care, we're Congress.
(S877: The Shut up and Eat Your spam act of 2003)
Permalink | Reply | 9 comments |

Gmane