Scripting Media Types

[ned.freed at mrochek.com ([e-mail])]

> * Bruce Lilly wrote:
> >First, the proposed text subtypes are inappropriate; text subtypes
> >are reserved for human-readable text content, with or without
> >markup; see RFC 2046 section 4.  They are not to be used for
> >arbitrary content which happens to be textual, such as programming
> >and scripting languages; they are reserved for natural language.

> That's probably true, but the alternative would be to continue using the
> unregistered types for several years as the application/* types are much
> less well-supported. For example, all SVG implementations I am aware of
> that support relevant scripting,support text/ecmascript (as the relevant
> specifications suggest) while none support application/ecmascript. There
> are about a million hits for type="text/*" but only a few hundred hits
> for type="application/*" using Google (where * are the relevant subtypes
> from the draft).

> There are also several other registered media types that are not meant
> to be used for natural language, for example, text/css, text/uri-list,
> text/vnd.wap.wmlscript, text/sgml, and text/xml do not fit into this
> category (either by their very nature as for text/css or by their use
> in common practise as for text/xml, though I admit that one can greatly
> argue about each type), I thus do not think that it is generally not
> possible to register such types under the text top-level type.

First, the criteria is "meaningful to present directly to a human", not
"is composed of natural language text".

Second, some of these registrations are widely thought to be mistakes -
they never should have been registered under text. As such, they don't
justify additional, similar registrations.

> If you
> consider the content to be "source code" rather than "executable code"
> it is for many people in fact difficult to find much difference between
> types such as text/html and text/ecmascript.

> There are even people who would prefer to just stick with the most
> commonly used types (which would be text/javascript, etc) simply because
> that's what's implemented, what authors use, what you can find in speci-
> fications, documentation, books, etc.pp.

> The types are currently unregistered and pretty much undefined, the
> draft defines underdefined aspects, provides security considerations
> for the types, and would register those types if the draft is approved.
> I think this is more valuable than to keep using the types as-is. In
> particular, I think it would actually help the IANA registry to gain
> relevance if it is less out of touch with reality. On several occasions
> I've contacted organizations to encourage them to register the types
> they use and/or define and I've generally been told that people don't
> bother as the registry is of too little relevance to them. The more it
> reflects reality, the more I would expect people to care, which would
> encourage more review of new types which would consequently encourage
> a more well-defined infrastructure.

The fact that these subtypes of text are in widespread use leads me to suggest
an alternate approach: Why not register them, but mark them as obsolete with a
pointer to the type that should be used instead? The registration will then
serve two purposes: To make it clear what the types contain when they are used
and to also make it clear they should no longer be used. 

> Thus, without arguing about whether text/* is the best place for these
> types (and the draft admits that it is probably not),

Hinting isn't sufficient IMO. We're trying to provide usage guidance here,
so the problematic nature of calling this sort of material text should
discussed.

				Ned
>From [e-mail]  Sat Feb 12 20:31:58 2005
From: derhoermi at gmx.net (Bjoern Hoehrmann)
Date: Sat Feb 12 20:31:54 2005
Subject: Scripting Media Types
In-Reply-To: <[e-mail]>
References: <[e-mail]>
	<[e-mail]>
	<[e-mail]>
	<[e-mail]>
Message-ID: <[e-mail]>

* [e-mail] wrote:
>The fact that these subtypes of text are in widespread use leads me to suggest
>an alternate approach: Why not register them, but mark them as obsolete with a
>pointer to the type that should be used instead? The registration will then
>serve two purposes: To make it clear what the types contain when they are used
>and to also make it clear they should no longer be used. 

The draft states that text/ecmascript is expected to be deprecated in a
future version of the document. This basically means text/ecmascript
should not be used in a context where application/ecmascript could be
used as well. Marking text/ecmascript as obsolete does not allow making
such a distinction as far as I can tell, and I think the registration
should acknowledge that users of the types do not have much of a choice
at the moment.

Consider for example <http://validator.w3.org/> which I help to develop;
it currently only offers SGML DTD validation but we are planning to add
features to report other errors and provide warnings e.g. in cases where
a specification states something SHOULD NOT be done. Marking a media
type as obsolete would basically mean that it SHOULD NOT be used, so it
would be reasonable to for a document like

  <!DOCTYPE html ...>
  ...
  <script type="text/ecmascript">
  ...

to generate a warning like

  Warning: use application/ecmascript instead of text/ecmascript

That's however not a reasonable suggestion at the moment. So maybe I
should add text such as "Use of text/ecmascript in a context where
application/ecmascript could be used as well is discouraged" to make
this clearer?
-- 
Bj?rn H?hrmann ? mailto:[e-mail] ? http://bjoern.hoehrmann.de
Weinh. Str. 22 ? Telefon: [phone] ? http://www.bjoernsworld.de
68309 Mannheim ? PGP Pub. KeyID: 0xA4357E78 ? http://www.websitedev.de/ 
>From [e-mail]  Sat Feb 12 21:16:39 2005
From: ned.freed at mrochek.com ([e-mail])
Date: Sat Feb 12 21:34:00 2005
Subject: Scripting Media Types
In-Reply-To: "Your message dated Sat, 12 Feb 2005 20:31:58 +0100"
	<[e-mail]>
References: <[e-mail]>
	<[e-mail]>
	<[e-mail]>
	<[e-mail]>
	<[e-mail]>
Message-ID: <[e-mail]>

> * [e-mail] wrote:
> >The fact that these subtypes of text are in widespread use leads me to suggest
> >an alternate approach: Why not register them, but mark them as obsolete with a
> >pointer to the type that should be used instead? The registration will then
> >serve two purposes: To make it clear what the types contain when they are used
> >and to also make it clear they should no longer be used.

> The draft states that text/ecmascript is expected to be deprecated in a
> future version of the document.

There is no defined process for deprecation of a media type. The closest
thing we have is marking the type as being obsolete, and the media types
registration procedure specifically calls for this to be done "when use of
the type is no longer appropriate". This IMO matches the present case
exactly.

> This basically means text/ecmascript
> should not be used in a context where application/ecmascript could be
> used as well. Marking text/ecmascript as obsolete does not allow making
> such a distinction as far as I can tell,

Actually, it makes exactly this distinction, one that deprecation does not
make.

> and I think the registration
> should acknowledge that users of the types do not have much of a choice
> at the moment.

That's exactly what registering the types as obsolete does.

				Ned
>From [e-mail]  Sat Feb 12 21:56:31 2005
From: blilly at erols.com (Bruce Lilly)
Date: Sat Feb 12 21:56:49 2005
Subject: Scripting Media Types
In-Reply-To: <[e-mail]>
References: <[e-mail]>
	<[e-mail]>
	<[e-mail]>
Message-ID: <[e-mail]>

On Sat February 12 2005 12:45, [e-mail] wrote:

> The fact that these subtypes of text are in widespread use leads me to suggest
> an alternate approach: Why not register them, but mark them as obsolete with a
> pointer to the type that should be used instead? The registration will then
> serve two purposes: To make it clear what the types contain when they are used
> and to also make it clear they should no longer be used. 

If one looks at the IANA-maintained registry
(http://www.iana.org/assignments/media-types/text/  for the text
types) one sees only a list of subtype tag names with references
to documents.  It's not clear, therefore, how one would go about
marking a subtype as obsolete in a way that would be clear and
obvious to implementers.  Nor is it clear how one would provide a
pointer to a different type in a way that would be clear etc. to
implementers.  Finally, it should be noted that content may be
archived for a considerable time;  how is one to determine whether
or not a type specified in an archived document was valid at the
time that content was created; I see no mechanism for provision
of a timestamp on changes in status of a type or subtype
registration?

> Hinting isn't sufficient IMO. We're trying to provide usage guidance here,
> so the problematic nature of calling this sort of material text should
> discussed.

Right.  And I'm not sure how something as much as mere hinting can
be achieved w.r.t. "obsolete" types with the current registry (lack
of) structure [compared, e.g. to the structure of the charset
registry].  Much less something that provides clear guidance
regarding usage.

About the only thing an implementer can do for non-private-use tags
without extensive manual effort for each type and subtype is to
determine whether something which appears where a media type is
supposed to appear is in fact a registered type -- that's the case
because that's all that can be mechanically determined from the
registry.  Thus a validating parser of Content-Type fields (for
example) can easily indicate that a type is registered -- a table
of registered types can be consulted (though such a table can get
out-of-date quickly) -- but it's much more difficult to be able to
indicate nuances such as whether/when a type has become obsolete,
what other types are related and in what ways, etc.
>From [e-mail]  Sat Feb 12 22:02:54 2005
From: derhoermi at gmx.net (Bjoern Hoehrmann)
Date: Sat Feb 12 22:02:50 2005
Subject: Scripting Media Types
In-Reply-To: <[e-mail]>
References: <[e-mail]>
	<[e-mail]>
	<[e-mail]>
	<[e-mail]>
	<[e-mail]>
	<[e-mail]>
Message-ID: <[e-mail]>

* [e-mail] wrote:
>There is no defined process for deprecation of a media type. The closest
>thing we have is marking the type as being obsolete, and the media types
>registration procedure specifically calls for this to be done "when use of
>the type is no longer appropriate". This IMO matches the present case
>exactly.

Well, my concern is that it would be misleading to suggest people use
application/ecmascript instead of text/ecmascript if the overwhelming
majority can't do that at the moment, so my preferred approach is to
register these types now as COMMON (or LIMITED USE) and update the
registration later to consider them OBSOLETE when support for the
alternate types is more widespread. But I guess pointing out in the
document that marking those types as obsolete does not mean there is
much wrong if these types are used/implemented for reasons of
backwards-compatibility would avoid confusion.

Bruce, would registering these types as OBSOLETE be acceptable to you?
-- 
Bj?rn H?hrmann ? mailto:[e-mail] ? http://bjoern.hoehrmann.de
Weinh. Str. 22 ? Telefon: [phone] ? http://www.bjoernsworld.de
68309 Mannheim ? PGP Pub. KeyID: 0xA4357E78 ? http://www.websitedev.de/ 
>From [e-mail]  Sat Feb 12 22:43:30 2005
From: ned.freed at mrochek.com ([e-mail])
Date: Sat Feb 12 22:52:00 2005
Subject: Scripting Media Types
In-Reply-To: "Your message dated Sat, 12 Feb 2005 15:56:31 -0500"
	<[e-mail]>
References: <[e-mail]>
	<[e-mail]>
	<[e-mail]>
	<[e-mail]>
Message-ID: <[e-mail]>

> On Sat February 12 2005 12:45, [e-mail] wrote:

> > The fact that these subtypes of text are in widespread use leads me to suggest
> > an alternate approach: Why not register them, but mark them as obsolete with a
> > pointer to the type that should be used instead? The registration will then
> > serve two purposes: To make it clear what the types contain when they are used
> > and to also make it clear they should no longer be used.

> If one looks at the IANA-maintained registry
> (http://www.iana.org/assignments/media-types/text/  for the text
> types) one sees only a list of subtype tag names with references
> to documents.  It's not clear, therefore, how one would go about
> marking a subtype as obsolete in a way that would be clear and
> obvious to implementers.

I think if someone gets as far as looking at the IANA registry
they probably are going to take the next step and look at the
actual registration for the type they decide on.

But even if this isn't the case, this is simply a matter of presenting
the information differently.

> Nor is it clear how one would provide a
> pointer to a different type in a way that would be clear etc. to
> implementers.

There are any number of places in the registration where it could go.

  Finally, it should be noted that content may be
> archived for a considerable time;  how is one to determine whether
> or not a type specified in an archived document was valid at the
> time that content was created; I see no mechanism for provision
> of a timestamp on changes in status of a type or subtype
> registration?

This begs the question of whether or not it is actually useful to be able
to make such determinations. I don't think it is.

> > Hinting isn't sufficient IMO. We're trying to provide usage guidance here,
> > so the problematic nature of calling this sort of material text should
> > discussed.

> Right.  And I'm not sure how something as much as mere hinting can
> be achieved w.r.t. "obsolete" types with the current registry (lack
> of) structure [compared, e.g. to the structure of the charset
> registry].  Much less something that provides clear guidance
> regarding usage.

The alternative, however, is to say nothing. And we have ample experience with
this approach and know where it leads: People will continue to use the
unregistered types.

> About the only thing an implementer can do for non-private-use tags
> without extensive manual effort for each type and subtype is to
> determine whether something which appears where a media type is
> supposed to appear is in fact a registered type -- that's the case
> because that's all that can be mechanically determined from the
> registry.  Thus a validating parser of Content-Type fields (for
> example) can easily indicate that a type is registered -- a table
> of registered types can be consulted (though such a table can get
> out-of-date quickly) -- but it's much more difficult to be able to
> indicate nuances such as whether/when a type has become obsolete,
> what other types are related and in what ways, etc.

This is true only in theory. What happens in practice is that lack of
registration is absolutely no impediment to continued, and even increased, use
of the types.

We have little if any experience with whether or not marking something obsolete
will help get it out of circulation. But I have seen cases where spelling out
security considerations has led to folks reconsidering the use of some media
types. So there is some hope. But without a registration, there is none.

				Ned
>From [e-mail]  Sun Feb 13 02:04:07 2005
From: blilly at erols.com (Bruce Lilly)
Date: Sun Feb 13 02:04:55 2005
Subject: Scripting Media Types
In-Reply-To: <[e-mail]>
References: <[e-mail]>
	<[e-mail]>
	<[e-mail]>
Message-ID: <[e-mail]>

On Sat February 12 2005 16:43, [e-mail] wrote:

> I think if someone gets as far as looking at the IANA registry
> they probably are going to take the next step and look at the
> actual registration for the type they decide on.

One might do that for a specific type of interest on some sort
of regular basis.  One might do so for the entire tree, one
time, to set up a table, then add types and subtypes as they
are added to the registries.  But I do not think it is reasonable
to expect that implementers will sift through the entire tree
of registrations regularly in order to catch any change in
registration status.

> > > Hinting isn't sufficient IMO. We're trying to provide usage guidance here,
> > > so the problematic nature of calling this sort of material text should
> > > discussed.
> 
> > Right.  And I'm not sure how something as much as mere hinting can
> > be achieved w.r.t. "obsolete" types with the current registry (lack
> > of) structure [compared, e.g. to the structure of the charset
> > registry].  Much less something that provides clear guidance
> > regarding usage.
> 
> The alternative, however, is to say nothing.

I'm not convinced that that's the only alternative.  Given that
there is work under way to improve the charset registry, it seems
feasible in principle to do something similar for the type and
subtype registries.

> And we have ample experience with 
> this approach and know where it leads: People will continue to use the
> unregistered types.

I believe that given a registration in an appropriate part of
the tree, use will migrate in that direction.  Those who make
the migration will benefit from improved prospects for
interoperability.  Those who do not will be where they are now,
i.e. operating in uncharted waters.
>From [e-mail]  Sun Feb 13 02:16:21 2005
From: blilly at erols.com (Bruce Lilly)
Date: Sun Feb 13 02:16:27 2005
Subject: Scripting Media Types
In-Reply-To: <[e-mail]>
References: <[e-mail]>
	<[e-mail]>
	<[e-mail]>
Message-ID: <[e-mail]>

On Sat February 12 2005 15:16, [e-mail] wrote:

> There is no defined process for deprecation of a media type. The closest
> thing we have is marking the type as being obsolete, and the media types
> registration procedure specifically calls for this to be done "when use of
> the type is no longer appropriate". This IMO matches the present case
> exactly.

Ned, you're the expert on the registration procedure, but isn't the
current discussion about a non-type whose use was never appropriate
rather than a registered type whose use has become inappropriate?  I
believe that's an important pair of distinctions; we've seen in this
case an argument along the lines of "well, text/blah doesn't meet the
requirements for a text type but was registered as one anyway" -- I
suspect that yet another inappropriate registration would make that
sort of argument more likely in the future.
>From [e-mail]  Sun Feb 13 02:36:25 2005
From: blilly at erols.com (Bruce Lilly)
Date: Sun Feb 13 02:36:42 2005
Subject: Scripting Media Types
In-Reply-To: <[e-mail]>
References: <[e-mail]>
	<[e-mail]>
	<[e-mail]>
Message-ID: <[e-mail]>

On Sat February 12 2005 16:02, Bjoern Hoehrmann wrote:

> Well, my concern is that it would be misleading to suggest people use
> application/ecmascript instead of text/ecmascript if the overwhelming
> majority can't do that at the moment

Why do you say that it would be misleading to suggest use of a
type registered in an appropriate part of the tree rather than to
use an unregistered tag which impinges on part of the IANA tree
namespace which is inappropriate for the content; isn't that
exactly the point of a registration -- to provide an appropriate
standardized tag?

> , so my preferred approach is to 
> register these types now as COMMON (or LIMITED USE) and update the
> registration later to consider them OBSOLETE when support for the
> alternate types is more widespread.

I suspect that if an inappropriate registry is made, regardless of
type, that usage patterns will change little, even if an appropriate
registration is made at the same time.  Once a registration is made,
applications will need to support it, if only for backwards
compatibility with archived content.  What the is the incentive for
migration to the appropriate type?  There is a tendency (inertia)
against change; change usually doesn't happen unless there is some
sort of penalty associated with not changing; if both appropriate
and inappropriate types are registered and therefore supported,
where is that motivating penalty?

> But I guess pointing out in the 
> document that marking those types as obsolete does not mean there is
> much wrong if these types are used/implemented for reasons of
> backwards-compatibility would avoid confusion.

It would remove incentive to change to an appropriate tag.

> Bruce, would registering these types as OBSOLETE be acceptable to you?

I'm not the arbiter of type registrations, but it seems to me that
such a registration would entail unnecessary work for IANA and for
implementers, would further dilute the distinction between text and
other types, and would be counterproductive in terms of moving
already non-conforming applications to an appropriate media type
tag usage.  Given those three types of harm that would likely be
caused, I would only support such registration as a last resort,
and I am not convinced that there is any need to resort to such a
measure.  What is wrong with simply registering appropriate types
and encouraging implementers to migrate to those types?
>From [e-mail]  Sun Feb 13 04:09:23 2005
From: ned.freed at mrochek.com ([e-mail])
Date: Sun Feb 13 04:16:06 2005
Subject: Scripting Media Types
In-Reply-To: "Your message dated Sat, 12 Feb 2005 20:04:07 -0500"
	<[e-mail]>
References: <[e-mail]>
	<[e-mail]>
	<[e-mail]>
	<[e-mail]>
Message-ID: <[e-mail]>

> On Sat February 12 2005 16:43, [e-mail] wrote:

> > I think if someone gets as far as looking at the IANA registry
> > they probably are going to take the next step and look at the
> > actual registration for the type they decide on.

> One might do that for a specific type of interest on some sort
> of regular basis.  One might do so for the entire tree, one
> time, to set up a table, then add types and subtypes as they
> are added to the registries.  But I do not think it is reasonable
> to expect that implementers will sift through the entire tree
> of registrations regularly in order to catch any change in
> registration status.

> > > > Hinting isn't sufficient IMO. We're trying to provide usage guidance here,
> > > > so the problematic nature of calling this sort of material text should
> > > > discussed.
> >
> > > Right.  And I'm not sure how something as much as mere hinting can
> > > be achieved w.r.t. "obsolete" types with the current registry (lack
> > > of) structure [compared, e.g. to the structure of the charset
> > > registry].  Much less something that provides clear guidance
> > > regarding usage.
> >
> > The alternative, however, is to say nothing.

> I'm not convinced that that's the only alternative.

I was talking about what to do with the text/* types we're discussing. And its
a binary choice: Either we register them or we don't.

  Given that
> there is work under way to improve the charset registry, it seems
> feasible in principle to do something similar for the type and
> subtype registries.

I certainly have no objection to improving the format of the registry. But I
don't think registering obsolete types should be contingent on that happening.

> > And we have ample experience with
> > this approach and know where it leads: People will continue to use the
> > unregistered types.

> I believe that given a registration in an appropriate part of
> the tree, use will migrate in that direction.  Those who make
> the migration will benefit from improved prospects for
> interoperability.  Those who do not will be where they are now,
> i.e. operating in uncharted waters.

Well, all I can say is that I disagree. I don't think a registration of the
right thing is nearly as powerful as registering the right and warning against
the wrong. And past experience in this exact space tends to support my
position, not yours.

				Ned
>From [e-mail]  Sun Feb 13 04:14:11 2005
From: ned.freed at mrochek.com ([e-mail])
Date: Sun Feb 13 04:31:03 2005
Subject: Scripting Media Types
In-Reply-To: "Your message dated Sat, 12 Feb 2005 20:16:21 -0500"
	<[e-mail]>
References: <[e-mail]>
	<[e-mail]>
	<[e-mail]>
	<[e-mail]>
Message-ID: <[e-mail]>

> On Sat February 12 2005 15:16, [e-mail] wrote:

> > There is no defined process for deprecation of a media type. The closest
> > thing we have is marking the type as being obsolete, and the media types
> > registration procedure specifically calls for this to be done "when use of
> > the type is no longer appropriate". This IMO matches the present case
> > exactly.

> Ned, you're the expert on the registration procedure, but isn't the
> current discussion about a non-type whose use was never appropriate
> rather than a registered type whose use has become inappropriate?

Actually, there was a time when this particular registration would have sailed
right on through.

> I believe that's an important pair of distinctions;

I disagree. I find neither distinction to be in any way important.

> we've seen in this
> case an argument along the lines of "well, text/blah doesn't meet the
> requirements for a text type but was registered as one anyway" -- I
> suspect that yet another inappropriate registration would make that
> sort of argument more likely in the future.

Ah yes, the slippery slope argument. I absolutely reject this, for two
reasons:

(1) Registering a type as obsolete and with a strong admonition that it
    not be used for anything new and for any existing use to convert to
    the correct type ASAP doesn't exactly create a climate that
    engourages inappropriate registrations. If anything, it does the
    exact opposite by making it clear that the text top level type
    shouldn't be abused in this way.

    There's a lot to be said for examples, even (or especially) negative ones.

(2) Been there, done that. The reason media type usage got to be such a
    mess is because the initial go at registration procedures was overly
    restrictive. This led to everyone just using all sorts of types
    willy-nilly. I hasten to add that this is not anyone's fault - at the
    time the registry was first designed we really had no idea how
    things would play out, and the concern that led to the ovverly
    restrictive design was reasonable. But now we know better, and we know
    that registering things both good and bad is a much more effetive
    way of dealing with them than pushing them away in hopes they'll
    vanish.

				Ned
>From [e-mail]  Sun Feb 13 17:48:22 2005
From: blilly at erols.com (Bruce Lilly)
Date: Sun Feb 13 17:49:10 2005
Subject: Scripting Media Types
In-Reply-To: <[e-mail]>
References: <[e-mail]>
	<[e-mail]>
	<[e-mail]>
Message-ID: <[e-mail]>

On Sat February 12 2005 22:09, [e-mail] wrote:

> > > The alternative, however, is to say nothing.
> 
> > I'm not convinced that that's the only alternative.
> 
> I was talking about what to do with the text/* types we're discussing. And its
> a binary choice: Either we register them or we don't.

Registration is a binary choice, but that does not preclude
mentioning inappropriate use of unregistered type names in
an RFC which also registers appropriate types.

> Well, all I can say is that I disagree. I don't think a registration of the
> right thing is nearly as powerful as registering the right and warning against
> the wrong.

I have no qualms about either "registering the right" or
"warning against the wrong". Registering the wrong is
another matter.
>From [e-mail]  Sun Feb 13 20:10:31 2005
From: ned.freed at mrochek.com ([e-mail])
Date: Sun Feb 13 20:13:39 2005
Subject: Scripting Media Types
In-Reply-To: "Your message dated Sun, 13 Feb 2005 11:48:22 -0500"
	<[e-mail]>
References: <[e-mail]>
	<[e-mail]>
	<[e-mail]>
	<[e-mail]>
Message-ID: <[e-mail]>

> On Sat February 12 2005 22:09, [e-mail] wrote:

> > > > The alternative, however, is to say nothing.
> >
> > > I'm not convinced that that's the only alternative.
> >
> > I was talking about what to do with the text/* types we're discussing. And its
> > a binary choice: Either we register them or we don't.

> Registration is a binary choice, but that does not preclude
> mentioning inappropriate use of unregistered type names in
> an RFC which also registers appropriate types.

> > Well, all I can say is that I disagree. I don't think a registration of the
> > right thing is nearly as powerful as registering the right and warning against
> > the wrong.

> I have no qualms about either "registering the right" or
> "warning against the wrong". Registering the wrong is
> another matter.

You have previously claimed that people will only look at the list of
registrations and not bother to look at the actual registrations. By this logic
a discussion of unregistered types buried in the text for some other type isn't
going to be seen.

You can't have it both ways. And please don't bother claiming that
the lack of a registration for these text types will serve as a warning
not to use them - everything we know about media type registrations says
otherwise.

				Ned
>From [e-mail]  Mon Feb 14 17:39:41 2005
From: iana at iana.org (Vickie Magee)
Date: Mon Feb 14 17:53:22 2005
Subject: Discount generic drugs
Message-ID: <9277015.1295788267@tomdual2>

An HTML attachment was scrubbed...
URL: http://eikenes.alvestrand.no/pipermail/ietf-types/attachments/20050214/d7eaa062/attachment.htm
>From [e-mail]  Thu Feb 17 15:01:55 2005
From: blilly at erols.com (Bruce Lilly)
Date: Thu Feb 17 18:01:48 2005
Subject: Scripting Media Types
In-Reply-To: <[e-mail]>
References: <[e-mail]>
	<[e-mail]>
	<[e-mail]>
Message-ID: <[e-mail]>

On Sun February 13 2005 14:10, [e-mail] wrote:

> You have previously claimed that people will only look at the list of
> registrations and not bother to look at the actual registrations. By this logic
> a discussion of unregistered types buried in the text for some other type isn't
> going to be seen.

Yes.
 
> You can't have it both ways. And please don't bother claiming that
> the lack of a registration for these text types will serve as a warning
> not to use them

By itself, it won't serve as a warning.  The problem is that there
is no visible, clear place to provide a warning.  If somebody
(typically a developer) is looking for an appropriate type and sees
application/ecmascript and application/javascript, he is likely to
use one of those.  If text/javascript etc. are also registered and
he sees one of those first, that's what he's likely to use.  The
latter is what we would like to avoid.
>From [e-mail]  Thu Feb 17 20:40:06 2005
From: YakovS at solidmatrix.com (Yakov Shafranovich)
Date: Thu Feb 17 20:44:18 2005
Subject: Media Type "text/csv", new draft (-01)
Message-ID: <[e-mail]>

I spend some time working in a new draft for this MIME type taking into 
accounts comments from this list and others. In particular:
1. I removed the "text/comma-separated-values" type and only left one 
MIME type "text/csv".
2. I changed the definitions to follow the CRLF convention for the 
"text" type for linebreaks.
3. Significant changes in ABNF grammar with a lot of help from Dave Crocker.
4. The CSV format has been moved to the normative part of the document.

I would appreciate comments and suggestions on the new draft. Until it 
posts into the IETF repository, it can be found here:

http://www.shaftek.org/publications/drafts/mime-csv/draft-shafranovich-mime-csv-01.txt
http://www.shaftek.org/publications/drafts/mime-csv/draft-shafranovich-mime-csv-01.html

An HTML list of changes is here:

http://www.shaftek.org/publications/drafts/mime-csv/rfcdiff-00-to-01.html

Thanks,
Yakov
>From [e-mail]  Mon Feb 21 18:19:44 2005
From: ned.freed at mrochek.com ([e-mail])
Date: Mon Feb 21 18:22:52 2005
Subject: Scripting Media Types
In-Reply-To: "Your message dated Thu, 17 Feb 2005 09:01:55 -0500"
	<[e-mail]>
References: <[e-mail]>
	<[e-mail]>
	<[e-mail]>
	<[e-mail]>
Message-ID: <[e-mail]>

> On Sun February 13 2005 14:10, [e-mail] wrote:

> > You have previously claimed that people will only look at the list of
> > registrations and not bother to look at the actual registrations. By this logic
> > a discussion of unregistered types buried in the text for some other type isn't
> > going to be seen.

> Yes.
 
> > You can't have it both ways. And please don't bother claiming that
> > the lack of a registration for these text types will serve as a warning
> > not to use them

> By itself, it won't serve as a warning.  The problem is that there
> is no visible, clear place to provide a warning.

Then let's fix that problem independently of doing the right thing
for these media types.

> If somebody
> (typically a developer) is looking for an appropriate type and sees
> application/ecmascript and application/javascript, he is likely to
> use one of those.  If text/javascript etc. are also registered and
> he sees one of those first, that's what he's likely to use.  The
> latter is what we would like to avoid.

I still don't buy the argument, but even if I did the right thing to do
is to address the clarity problem, not fall down in providing useful
advice.

				Ned
>From [e-mail]  Tue Feb 22 13:09:10 2005
From: derhoermi at gmx.net (Bjoern Hoehrmann)
Date: Tue Feb 22 13:09:15 2005
Subject: Scripting Media Types
In-Reply-To: <[e-mail]>
References: <[e-mail]>
Message-ID: <[e-mail]>

* Bjoern Hoehrmann wrote:
>  A new Internet-Draft is available from the online Internet-Drafts
>directories. This memo describes media types for the ECMAScript and
>JavaScript programming languages.

I've submitted an updated draft which should be published later this
week. A copy of the document can be found at

  http://www.websitedev.de/ietf/draft-hoehrmann-script-types-02.txt

The text/* types are now obsolete and the change controller is now
the IESG rather than the IETF. I've also made some editorial changes,
in particular, processing of the application/ecmascript "version"
parameter is now more clearly described as error handling behavior.
-- 
Bj?rn H?hrmann ? mailto:[e-mail] ? http://bjoern.hoehrmann.de
Weinh. Str. 22 ? Telefon: [phone] ? http://www.bjoernsworld.de
68309 Mannheim ? PGP Pub. KeyID: 0xA4357E78 ? http://www.websitedev.de/ 
>From [e-mail]  Tue Feb 22 17:15:13 2005
From: YakovS at solidmatrix.com (Yakov Shafranovich)
Date: Tue Feb 22 17:15:28 2005
Subject: Media Type "text/csv": new draft (-02) and Last Call
Message-ID: <[e-mail]>

I posted a new draft (-02) with minor ABNF corrections. The new draft 
can be found in the IETF repository:

http://www.ietf.org/internet-drafts/draft-shafranovich-mime-csv-02.txt

The HTML version, a diff of changes and all previous versions can be 
found here:

http://www.shaftek.org/publications/drafts/mime-csv/draft-shafranovich-mime-csv-02.html
http://www.shaftek.org/publications/drafts/mime-csv/rfcdiff-01-to-02.html
http://www.shaftek.org/publications/drafts/mime-csv/

Scott Hollenbeck (APP AD) has reviewed my draft and initiated a Last 
Call on it which is expected to last about four weeks.

Yakov
>From [e-mail]  Thu Feb  3 02:58:34 2005
From: YakovS at solidmatrix.com (Yakov Shafranovich)
Date: Tue Jan  3 16:22:55 2006
Subject: Media Types 'text/csv' and 'text/comma-separated-values'
Message-ID: <[e-mail]>

Hi all,

I noticed that the MIME registration tree has an entry for 
'text/tab-separated-values' but for some reason doesn't have any 
registration for 'text/comma-separated-values' or 'text/csv. I have been 
reviewing some of the stuff out there and so far have seen the following 
being used:

application/csv
text/csv
text/comma-separated-values
text/x-csv

I was wondering if there would be any value to formally register two of 
the CSV types being used from the text tree (text/csv and 
text/comma-separated-values). I put together a small draft which hasn't 
posted to the ID repository yet. A copy should be available here:

http://www.shaftek.org/publications/drafts/mime-csv/draft-shafranovich-mime-csv-00.txt

Yakov