regarding your comments on proposed media type text/troff' toInformational RFC

[moore at cs.utk.edu (Keith Moore)]

> The more important reason to avoid automatic interpretation is that
> is is unsafe to do so.

ah, if only implementors and users had common sense.  experience
indicates that they do not.   expecting them to do so, in the absence
of a good reason, is imprudent.
>From [e-mail]  Tue Apr 19 19:15:17 2005
From: moore at cs.utk.edu (Keith Moore)
Date: Tue Apr 19 19:15:28 2005
Subject: regarding your comments on proposed media type text/troff'
 toInformational RFC
In-Reply-To: <[e-mail]>
References: <[e-mail]>
	<[e-mail]>
Message-ID: <[e-mail]>

> The more important reason to avoid automatic interpretation is that
> is is unsafe to do so.

ah, if only implementors and users had common sense.  experience
indicates that they do not.   expecting them to do so, in the absence
of a good reason, is imprudent.
>From [e-mail]  Tue Apr 19 20:54:53 2005
From: blilly at erols.com (Bruce Lilly)
Date: Tue Apr 19 20:55:12 2005
Subject: regarding your comments on proposed media type text/troff' to
	Informational RFC
In-Reply-To: <[e-mail]>
References: <[e-mail]>
	<[e-mail]>
	<[e-mail]>
Message-ID: <[e-mail]>

On Tue April 19 2005 13:13, Keith Moore wrote:
> Bruce,
> 
> I've already cited the relevant text

You cited an out-of-context excerpt from RFC 2046 section 4.5.1
(Octet-Stream Subtype), which is not directly relevant:

1. it concerns application software implementation issues rather than
   media type definitions, parameters, content, or registration

2. it is specific to the application/octet-stream media subtype, which
   is in a completely different media type category.

However, some of the considerations of course apply to application
software implementations of other media types, and those are discussed
in the draft, using language similar to (but with RFC 2119 emphasis;
for what that's worth in an Informational RFC) that of the cited section.

> The process parameter as you have defined it is not an essential part 
> of this content-type.

Duh.  That's why it's an optional parameter.  If you don't like it, you
need not use it.

> Nor is it likely to be used in the way you assume, 
> because (as I have already said twice) content-type parameters are 
> rarely displayed to recipients.

I can easily see the entire Content-Type field; look at any I-D-announce
or IETF-Announce list announcement of a draft or RFC -- there are
message/external-body wrappers with Content-Type and Content-ID fields
for the media.

> Nor is the parameter as you have defined 
> it portable to different implementations of troff that have different 
> options.

There is an optional "versions" parameter which can be used to indicate
peculiarities.  However, unless one tries fairly hard, one is unlikely
to encounter incompatible options, as implementations are generally
intended to be compatible, and authors creating content for wide
distribution tend to be careful not to use incompatible features.

> This parameter is just poorly designed, and it's a security 
> risk, and there's simply not enough justification for it to be defined
> the way you propose.

Sending executable content such as a build script as you proposed as an
alternative would be a security risk.  Since the parameter is human-readable
information about the media type, *in* a parameter (which is not executable),
there is no inherent security risk aside from social engineering, and that
exists regardless of any parameters, and regardless of media type.
>From [e-mail]  Tue Apr 19 20:54:53 2005
From: blilly at erols.com (Bruce Lilly)
Date: Tue Apr 19 20:55:17 2005
Subject: regarding your comments on proposed media type text/troff' to
	Informational RFC
In-Reply-To: <[e-mail]>
References: <[e-mail]>
	<[e-mail]>
	<[e-mail]>
Message-ID: <[e-mail]>

On Tue April 19 2005 13:13, Keith Moore wrote:
> Bruce,
> 
> I've already cited the relevant text

You cited an out-of-context excerpt from RFC 2046 section 4.5.1
(Octet-Stream Subtype), which is not directly relevant:

1. it concerns application software implementation issues rather than
   media type definitions, parameters, content, or registration

2. it is specific to the application/octet-stream media subtype, which
   is in a completely different media type category.

However, some of the considerations of course apply to application
software implementations of other media types, and those are discussed
in the draft, using language similar to (but with RFC 2119 emphasis;
for what that's worth in an Informational RFC) that of the cited section.

> The process parameter as you have defined it is not an essential part 
> of this content-type.

Duh.  That's why it's an optional parameter.  If you don't like it, you
need not use it.

> Nor is it likely to be used in the way you assume, 
> because (as I have already said twice) content-type parameters are 
> rarely displayed to recipients.

I can easily see the entire Content-Type field; look at any I-D-announce
or IETF-Announce list announcement of a draft or RFC -- there are
message/external-body wrappers with Content-Type and Content-ID fields
for the media.

> Nor is the parameter as you have defined 
> it portable to different implementations of troff that have different 
> options.

There is an optional "versions" parameter which can be used to indicate
peculiarities.  However, unless one tries fairly hard, one is unlikely
to encounter incompatible options, as implementations are generally
intended to be compatible, and authors creating content for wide
distribution tend to be careful not to use incompatible features.

> This parameter is just poorly designed, and it's a security 
> risk, and there's simply not enough justification for it to be defined
> the way you propose.

Sending executable content such as a build script as you proposed as an
alternative would be a security risk.  Since the parameter is human-readable
information about the media type, *in* a parameter (which is not executable),
there is no inherent security risk aside from social engineering, and that
exists regardless of any parameters, and regardless of media type.
>From [e-mail]  Tue Apr 19 21:08:36 2005
From: blilly at erols.com (Bruce Lilly)
Date: Tue Apr 19 21:08:52 2005
Subject: regarding your comments on proposed media type text/troff'
	toInformational RFC
In-Reply-To: <[e-mail]>
References: <[e-mail]>
Message-ID: <[e-mail]>

On Tue April 19 2005 12:24, Larry Masinter wrote:
> I wish you would reply and say why you think your proposal
> (put processing instructions in a parameter) is better than
> what I recently proposed as an alternative (put processing
> instructions in a comment in the body).

I think I was composing just such a response at the same time that
you were composing your message.

> MIME parameters tend to get lost when the MIME bodies are
> pushed through most file systems.

That's a general issue with such file systems. It applies to most
types and parameters.  For that matter, it applies even if MIME
mechanisms aren't used.  Some systems resort to guesses ("heuristics");
others pretend that Bill Shakespeare was wrong, that a name (or portion
thereof) conveys some essential information.

> MIME parameters are hard 
> to set up for HTTP servers; it's difficult to configure
> them to emit widely variable processing instructions, e.g.,
> if you were to have several different text/troff files,
> each with different processing instructions.

The same could be said for several different text/plain files, each
with a different charset.  Solutions to the problem include groping
through the content (unreliable and inefficient) and maintaining a
database of metadata.
 
> If don't REALLY intend for the processing instructions to be
> handled automatically, and you REALLY intend for humans to read
> and interpret them, you're better off bundling them inside
> the body anyway.

See the issues regarding retrieval of sizable remote content.
>From [e-mail]  Tue Apr 19 21:08:36 2005
From: blilly at erols.com (Bruce Lilly)
Date: Tue Apr 19 21:08:57 2005
Subject: regarding your comments on proposed media type text/troff'
	toInformational RFC
In-Reply-To: <[e-mail]>
References: <[e-mail]>
Message-ID: <[e-mail]>

On Tue April 19 2005 12:24, Larry Masinter wrote:
> I wish you would reply and say why you think your proposal
> (put processing instructions in a parameter) is better than
> what I recently proposed as an alternative (put processing
> instructions in a comment in the body).

I think I was composing just such a response at the same time that
you were composing your message.

> MIME parameters tend to get lost when the MIME bodies are
> pushed through most file systems.

That's a general issue with such file systems. It applies to most
types and parameters.  For that matter, it applies even if MIME
mechanisms aren't used.  Some systems resort to guesses ("heuristics");
others pretend that Bill Shakespeare was wrong, that a name (or portion
thereof) conveys some essential information.

> MIME parameters are hard 
> to set up for HTTP servers; it's difficult to configure
> them to emit widely variable processing instructions, e.g.,
> if you were to have several different text/troff files,
> each with different processing instructions.

The same could be said for several different text/plain files, each
with a different charset.  Solutions to the problem include groping
through the content (unreliable and inefficient) and maintaining a
database of metadata.
 
> If don't REALLY intend for the processing instructions to be
> handled automatically, and you REALLY intend for humans to read
> and interpret them, you're better off bundling them inside
> the body anyway.

See the issues regarding retrieval of sizable remote content.
>From [e-mail]  Tue Apr 19 21:14:19 2005
From: moore at cs.utk.edu (Keith Moore)
Date: Tue Apr 19 21:14:27 2005
Subject: regarding your comments on proposed media type text/troff' to
 Informational RFC
In-Reply-To: <[e-mail]>
References: <[e-mail]>
	<[e-mail]>
	<[e-mail]>
	<[e-mail]>
Message-ID: <[e-mail]>

> You cited an out-of-context excerpt from RFC 2046 section 4.5.1
> (Octet-Stream Subtype), which is not directly relevant:
> 
> 1. it concerns application software implementation issues rather than
>    media type definitions, parameters, content, or registration
> 
> 2. it is specific to the application/octet-stream media subtype, which
>    is in a completely different media type category.

I've already explained why the text is relevant despite the above.

> > The process parameter as you have defined it is not an essential part 
> > of this content-type.
> 
> Duh.  That's why it's an optional parameter.  If you don't like it, you
> need not use it.

What I meant (as if you couldn't figure this out) is that it doesn't have
to be defined the way you want it to be defined in order for the type to
be useful.

> > Nor is it likely to be used in the way you assume, 
> > because (as I have already said twice) content-type parameters are 
> > rarely displayed to recipients.
> 
> I can easily see the entire Content-Type field; look at any I-D-announce
> or IETF-Announce list announcement of a draft or RFC -- there are
> message/external-body wrappers with Content-Type and Content-ID fields
> for the media.

Content-type parameters are not displayed in most mail readers.

> > This parameter is just poorly designed, and it's a security 
> > risk, and there's simply not enough justification for it to be defined
> > the way you propose.
> 
> Sending executable content such as a build script as you proposed as an
> alternative would be a security risk.  

It is well established that email may be used to send executable content,
but we try to discourage having ways that make it easy for the email
reader to distinguish executable content from non-executable content
and execute it.

> Since the parameter is human-readable
> information about the media type, *in* a parameter (which is not executable),

The purpose of content-type parameters is for machine interpretation rather 
than human readability.

> there is no inherent security risk aside from social engineering

hogwash.