Subject: Media Type "text/csv": new draft (-02) and Last Call
From: YakovS at solidmatrix.com (Yakov Shafranovich)
Date: Tue Jan 3 16:22:56 2006

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: derhoermi at gmx.net (Bjoern Hoehrmann)
Date: Tue Jan  3 16:22:56 2006
Subject: Scripting Media Types
In-Reply-To: <[email-masked]>
References: <[email-masked]>
Message-ID: <[email-masked]>

* 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:[email-masked] ? http://bjoern.hoehrmann.de
Weinh. Str. 22 ? Telefon: +49(0)621/4309674 ? http://www.bjoernsworld.de
68309 Mannheim ? PGP Pub. KeyID: 0xA4357E78 ? http://www.websitedev.de/ 

From: ned.freed at mrochek.com ([email-masked])
Date: Tue Jan  3 16:22:56 2006
Subject: Scripting Media Types
In-Reply-To: "Your message dated Thu, 17 Feb 2005 09:01:55 -0500" <[email-masked]>
References: <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]>
Message-ID: <[email-masked]>

> On Sun February 13 2005 14:10, [email-masked] 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: YakovS at solidmatrix.com (Yakov Shafranovich)
Date: Tue Jan  3 16:22:56 2006
Subject: Media Type "text/csv", new draft (-01)
Message-ID: <[email-masked]>

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: iana at iana.org (Vickie Magee)
Date: Tue Jan  3 16:22:56 2006
Subject: Discount generic drugs
Message-ID: <9277015.1295788267@tomdual2>

An HTML attachment was scrubbed...
URL: http://www.alvestrand.no/pipermail/ietf-types/attachments/20050214/d7eaa062/attachment.html
>From [email-masked]  Thu Feb 17 15:01:55 2005
From: blilly at erols.com (Bruce Lilly)
Date: Tue Jan  3 16:22:56 2006
Subject: Scripting Media Types
In-Reply-To: <[email-masked]>
References: <[email-masked]>
	<[email-masked]>
	<[email-masked]>
Message-ID: <[email-masked]>

On Sun February 13 2005 14:10, [email-masked] 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: ned.freed at mrochek.com ([email-masked])
Date: Tue Jan  3 16:22:56 2006
Subject: Scripting Media Types
In-Reply-To: "Your message dated Sun, 13 Feb 2005 11:48:22 -0500" <[email-masked]>
References: <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]>
Message-ID: <[email-masked]>

> On Sat February 12 2005 22:09, [email-masked] 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: blilly at erols.com (Bruce Lilly)
Date: Tue Jan  3 16:22:56 2006
Subject: Scripting Media Types
In-Reply-To: <[email-masked]>
References: <[email-masked]> <[email-masked]> <[email-masked]>
Message-ID: <[email-masked]>

On Sat February 12 2005 22:09, [email-masked] 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: ned.freed at mrochek.com ([email-masked])
Date: Tue Jan  3 16:22:56 2006
Subject: Scripting Media Types
In-Reply-To: "Your message dated Sat, 12 Feb 2005 20:16:21 -0500" <[email-masked]>
References: <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]>
Message-ID: <[email-masked]>

> On Sat February 12 2005 15:16, [email-masked] 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: ned.freed at mrochek.com ([email-masked])
Date: Tue Jan  3 16:22:56 2006
Subject: Scripting Media Types
In-Reply-To: "Your message dated Sat, 12 Feb 2005 20:04:07 -0500" <[email-masked]>
References: <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]>
Message-ID: <[email-masked]>

> On Sat February 12 2005 16:43, [email-masked] 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: blilly at erols.com (Bruce Lilly)
Date: Tue Jan  3 16:22:56 2006
Subject: Scripting Media Types
In-Reply-To: <[email-masked]>
References: <[email-masked]> <[email-masked]> <[email-masked]>
Message-ID: <[email-masked]>

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: blilly at erols.com (Bruce Lilly)
Date: Tue Jan  3 16:22:56 2006
Subject: Scripting Media Types
In-Reply-To: <[email-masked]>
References: <[email-masked]> <[email-masked]> <[email-masked]>
Message-ID: <[email-masked]>

On Sat February 12 2005 15:16, [email-masked] 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: blilly at erols.com (Bruce Lilly)
Date: Tue Jan  3 16:22:56 2006
Subject: Scripting Media Types
In-Reply-To: <[email-masked]>
References: <[email-masked]> <[email-masked]> <[email-masked]>
Message-ID: <[email-masked]>

On Sat February 12 2005 16:43, [email-masked] 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: ned.freed at mrochek.com ([email-masked])
Date: Tue Jan  3 16:22:55 2006
Subject: Scripting Media Types
In-Reply-To: "Your message dated Sat, 12 Feb 2005 15:56:31 -0500" <[email-masked]>
References: <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]>
Message-ID: <[email-masked]>

> On Sat February 12 2005 12:45, [email-masked] 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: derhoermi at gmx.net (Bjoern Hoehrmann)
Date: Tue Jan  3 16:22:55 2006
Subject: Scripting Media Types
In-Reply-To: <[email-masked]>
References: <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]>
Message-ID: <[email-masked]>

* [email-masked] 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:[email-masked] ? http://bjoern.hoehrmann.de
Weinh. Str. 22 ? Telefon: +49(0)621/4309674 ? http://www.bjoernsworld.de
68309 Mannheim ? PGP Pub. KeyID: 0xA4357E78 ? http://www.websitedev.de/ 

From: blilly at erols.com (Bruce Lilly)
Date: Tue Jan  3 16:22:55 2006
Subject: Scripting Media Types
In-Reply-To: <[email-masked]>
References: <[email-masked]> <[email-masked]> <[email-masked]>
Message-ID: <[email-masked]>

On Sat February 12 2005 12:45, [email-masked] 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: ned.freed at mrochek.com ([email-masked])
Date: Tue Jan  3 16:22:55 2006
Subject: Scripting Media Types
In-Reply-To: "Your message dated Sat, 12 Feb 2005 20:31:58 +0100" <[email-masked]>
References: <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]>
Message-ID: <[email-masked]>

> * [email-masked] 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: derhoermi at gmx.net (Bjoern Hoehrmann)
Date: Tue Jan  3 16:22:55 2006
Subject: Scripting Media Types
In-Reply-To: <[email-masked]>
References: <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]>
Message-ID: <[email-masked]>

* [email-masked] 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:[email-masked] ? http://bjoern.hoehrmann.de
Weinh. Str. 22 ? Telefon: +49(0)621/4309674 ? http://www.bjoernsworld.de
68309 Mannheim ? PGP Pub. KeyID: 0xA4357E78 ? http://www.websitedev.de/ 

From: ned.freed at mrochek.com ([email-masked])
Date: Sat Feb 12 18:58:10 2005
Subject: Scripting Media Types
In-Reply-To: "Your message dated Wed, 09 Feb 2005 04:08:27 +0100" <[email-masked]>
References: <[email-masked]> <[email-masked]> <[email-masked]>
Message-ID: <[email-masked]>

> * 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 [email-masked]  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: <[email-masked]>
References: <[email-masked]>
	<[email-masked]>
	<[email-masked]>
	<[email-masked]>
Message-ID: <[email-masked]>

* [email-masked] 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:[email-masked] ? http://bjoern.hoehrmann.de
Weinh. Str. 22 ? Telefon: +49(0)621/4309674 ? http://www.bjoernsworld.de
68309 Mannheim ? PGP Pub. KeyID: 0xA4357E78 ? http://www.websitedev.de/ 
>From [email-masked]  Sat Feb 12 21:16:39 2005
From: ned.freed at mrochek.com ([email-masked])
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"
	<[email-masked]>
References: <[email-masked]>
	<[email-masked]>
	<[email-masked]>
	<[email-masked]>
	<[email-masked]>
Message-ID: <[email-masked]>

> * [email-masked] 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 [email-masked]  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: <[email-masked]>
References: <[email-masked]>
	<[email-masked]>
	<[email-masked]>
Message-ID: <[email-masked]>

On Sat February 12 2005 12:45, [email-masked] 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 [email-masked]  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: <[email-masked]>
References: <[email-masked]>
	<[email-masked]>
	<[email-masked]>
	<[email-masked]>
	<[email-masked]>
	<[email-masked]>
Message-ID: <[email-masked]>

* [email-masked] 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:[email-masked] ? http://bjoern.hoehrmann.de
Weinh. Str. 22 ? Telefon: +49(0)621/4309674 ? http://www.bjoernsworld.de
68309 Mannheim ? PGP Pub. KeyID: 0xA4357E78 ? http://www.websitedev.de/ 
>From [email-masked]  Sat Feb 12 22:43:30 2005
From: ned.freed at mrochek.com ([email-masked])
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"
	<[email-masked]>
References: <[email-masked]>
	<[email-masked]>
	<[email-masked]>
	<[email-masked]>
Message-ID: <[email-masked]>

> On Sat February 12 2005 12:45, [email-masked] 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 [email-masked]  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: <[email-masked]>
References: <[email-masked]>
	<[email-masked]>
	<[email-masked]>
Message-ID: <[email-masked]>

On Sat February 12 2005 16:43, [email-masked] 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 [email-masked]  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: <[email-masked]>
References: <[email-masked]>
	<[email-masked]>
	<[email-masked]>
Message-ID: <[email-masked]>

On Sat February 12 2005 15:16, [email-masked] 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 [email-masked]  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: <[email-masked]>
References: <[email-masked]>
	<[email-masked]>
	<[email-masked]>
Message-ID: <[email-masked]>

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 [email-masked]  Sun Feb 13 04:09:23 2005
From: ned.freed at mrochek.com ([email-masked])
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"
	<[email-masked]>
References: <[email-masked]>
	<[email-masked]>
	<[email-masked]>
	<[email-masked]>
Message-ID: <[email-masked]>

> On Sat February 12 2005 16:43, [email-masked] 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 [email-masked]  Sun Feb 13 04:14:11 2005
From: ned.freed at mrochek.com ([email-masked])
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"
	<[email-masked]>
References: <[email-masked]>
	<[email-masked]>
	<[email-masked]>
	<[email-masked]>
Message-ID: <[email-masked]>

> On Sat February 12 2005 15:16, [email-masked] 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 [email-masked]  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: <[email-masked]>
References: <[email-masked]>
	<[email-masked]>
	<[email-masked]>
Message-ID: <[email-masked]>

On Sat February 12 2005 22:09, [email-masked] 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 [email-masked]  Sun Feb 13 20:10:31 2005
From: ned.freed at mrochek.com ([email-masked])
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"
	<[email-masked]>
References: <[email-masked]>
	<[email-masked]>
	<[email-masked]>
	<[email-masked]>
Message-ID: <[email-masked]>

> On Sat February 12 2005 22:09, [email-masked] 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 [email-masked]  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 [email-masked]  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: <[email-masked]>
References: <[email-masked]>
	<[email-masked]>
	<[email-masked]>
Message-ID: <[email-masked]>

On Sun February 13 2005 14:10, [email-masked] 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 [email-masked]  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: <[email-masked]>

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 [email-masked]  Mon Feb 21 18:19:44 2005
From: ned.freed at mrochek.com ([email-masked])
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"
	<[email-masked]>
References: <[email-masked]>
	<[email-masked]>
	<[email-masked]>
	<[email-masked]>
Message-ID: <[email-masked]>

> On Sun February 13 2005 14:10, [email-masked] 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 [email-masked]  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: <[email-masked]>
References: <[email-masked]>
Message-ID: <[email-masked]>

* 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:[email-masked] ? http://bjoern.hoehrmann.de
Weinh. Str. 22 ? Telefon: +49(0)621/4309674 ? http://www.bjoernsworld.de
68309 Mannheim ? PGP Pub. KeyID: 0xA4357E78 ? http://www.websitedev.de/ 
>From [email-masked]  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: <[email-masked]>

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 [email-masked]  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: <[email-masked]>

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

From: ned.freed at mrochek.com ([email-masked])
Date: Tue Jan  3 16:22:55 2006
Subject: Scripting Media Types
In-Reply-To: "Your message dated Wed, 09 Feb 2005 04:08:27 +0100" <[email-masked]>
References: <[email-masked]> <[email-masked]> <[email-masked]>
Message-ID: <[email-masked]>

> * 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: LMM at acm.org (Larry Masinter)
Date: Tue Jan  3 16:22:55 2006
Subject: Media type versioning (was: Re: Scripting Media Types)
In-Reply-To: <[email-masked]>
Message-ID: <[email-masked]>

Re declarative rather than negotiation situations:

You could still use RFC 2912 "content-features" to indicate
information other than what is in the baseline. The idea
is that rather than loading up content-type with information
that is unnecessary for the purpose of content-type, add it
to a separate expression which can contain not only
version information, but other resource constraints.

I don't think anyone's defined a 'version' feature, but that
would be a good thing to work out and add to

http://www.iana.org/assignments/media-feature-tags

Larry

From: ned.freed at mrochek.com ([email-masked])
Date: Tue Jan  3 16:22:55 2006
Subject: Media type versioning (was: Re: Scripting Media Types)
In-Reply-To: "Your message dated Thu, 10 Feb 2005 23:30:28 -0500" <[email-masked]>
References: <[email-masked]> <[email-masked]>
Message-ID: <[email-masked]>

> Summary:
> o media content might contain version information, but reliance
>   on that can result in wasted resources
> o negotiation via content-features may be a viable mechanism
>   where negotiation is possible, but it is not always
>   possible (and some means of indicating version must be
>   available to the content negotiation mechanism)
> o proliferation of type/subtypes tags for the sole purpose
>   of versioning is undesirable
> that leaves parameters associated with the media type as an
> efficient mechanism for indicating version information.

I would also add that how version information should be handled very much
depends on how the versioning is done. Versioning schemes range from single
integer affairs (V1,V2,V3) to major/minor/patch m.n.o schemes to
feature-by-feature enumerations. Some formats (e.g., PostScript) even allow
conditionalization of features that may not be supported, so documents work
everywhere but work "better" (in some sense) when certain extensions are
present.

IMO the more complex a versioning scheme is the less amemable it is to being
captured in a set of parameters. Once things pass a certain point content
negotiation needs to be used, or if it cannot be used there's no choice but to
rely on information embedded in the data.

				Ned

From: blilly at erols.com (Bruce Lilly)
Date: Tue Jan  3 16:22:55 2006
Subject: Scripting Media Types
In-Reply-To: <[email-masked]>
References: <[email-masked]> <[email-masked]> <[email-masked]>
Message-ID: <[email-masked]>

On Wed February 9 2005 16:46, Bjoern Hoehrmann wrote:
> * Bruce Lilly wrote:
> >You might say something like "there exist some non-MIME-compliant
> >applications that generate unregistered, non-private-use labels
> >such as 'text/javascript'  ...  such use is clearly not interoperable".
> 
> Would such a statement address your concerns in this regard, or do you
> mean wording such as "support" as you've mentioned, "the media type
> application/ecmascript", etc. should still be replaced even if I adopt
> this proposal?

My principal objection is to inappropriate use of text (image, video,
audio, model) discrete types.  I have no objection to registration
under the application discrete media type.  For that matter, there
are a number of scripting languages that have no registered media
tags ((Bourne) shell (and descendants), awk, sed, perl, python, etc.),
and all of them share certain similarities which are distinct from
the bulk of application types (which are primarily data used by
some software, as opposed to *being* software); there might well be
a rare opportunity to register a media type category for scripting
[I am not officially proposing that; I mention it only for the sake
of completeness].
 
> But why does that require the reference to be normative rather than
> informative?

A rule of thumb is that if a reference's relevant content were to
change, and that would result in some change to an implementation of
a media type handler, then that reference is almost certainly
normative.  If the reference is solely for illustrative purposes,
it is informative.

From: blilly at erols.com (Bruce Lilly)
Date: Tue Jan  3 16:22:55 2006
Subject: Media type versioning (was: Re: Scripting Media Types)
In-Reply-To: <[email-masked]>
References: <[email-masked]> <[email-masked]> <[email-masked]>
Message-ID: <[email-masked]>

On Wed February 9 2005 16:46, Bjoern Hoehrmann wrote:

> At least in the context of HTTP, use of such parameters where media
> types provide them is not common in my experience, using them would
> typically require access to the server configuration and users that
> know about the parameters and how to configure the server accordingly;
> RFC 2854 notes that this did not work in practise. The situation might
> be different when this would be relevant for the proposed types, but
> that seems unlikely...

2854 only mentions one parameter (charset) and it seems to encourage
its use; I see no mention of problems with use of (as opposed to
failure to use) that parameter.

> Could you make a suggestion for the draft that would address your
> concern? Would it be sufficient to refer to the version parameter
> as optional parameter with an unconstrained lexical space for its
> value and with the semantics that implementations must consider any
> use of the parameter to indicate that the content is unsupported?

One approach would be to recommend or require display to the user
and confirmation before executing the content.  Since we're dealing
with potentially dangerous executable content, user confirmation
should be required anyway; providing some version information to
the user with a request for confirmation provides the user with
information which may be useful in making a decision. Structured
version information could go further; it might provide applications
with the ability to determine that execution is not possible (due
to lack of availability of some resource, or due to some
incompatibility); that could replace a request for confirmation by
an informative message (possibly localized) which would explain the
problem to the user (as opposed to simply displaying unstructured
"human-readable" versioning content, which might in fact be unreadable
to some humans due to charset and/or language issues).

As to what specific sort of structured versioning information
might be appropriate, that really depends on how the (scripting)
language versions and related compatibility issues are structured.
I can, however, offer an observation about what hasn't worked well,
and how to avoid problems which have plagued other versioning
mechanisms.

MIME itself provides for versioning via a MIME-Version header field.
The field body is defined as two dot-separated integers.  However,
there are several problems:
1. the semantics are undefined; aside from the initial version
   of 1.0, we can't tell how a hypothetical version 1.1 would be
   partially compatible, or a hypothetical version 2.0, etc.
2. the syntax is silent about leading zeroes in the integer
   parts. That's a recipe for interoperability problems.

From: blilly at erols.com (Bruce Lilly)
Date: Fri Feb 11 21:16:03 2005
Subject: Media type versioning (was: Re: Scripting Media Types)
In-Reply-To: <[email-masked]>
References: <[email-masked]>
Message-ID: <[email-masked]>

On Thu February 10 2005 15:31, Larry Masinter wrote:

> My opinion is that content negotiation for versioning capability
> using MIME type parameters is unworkable.

Negotiation isn't always possible; sometimes it's a one-way
street.

> The use of the MIME 
> type is to describe the payload sufficiently so that you know
> HOW to process it, but the content-type label cannot (and thus
> should not) be extended in an attempt to use it to determine
> WHETHER a given processor knows enough to be able to process it.

We're in agreement that the media type/subtype tag should not
be used for versioning (that would result in an unnecessary
proliferation of tags).

> So whether version information should or should not be in
> a media type parameter depends pretty much on whether there
> is an embedded, easy-to-find version indicator in the data
> itself; if there isn't, and processors need to know the version
> to choose between different processing methods, then the
> version parameter should be mandatory. There is no strong
> use case for an optional version parameter, or in general
> for duplicating, in MIME parameters, information that is
> readily obtained from the content itself.

Maybe; if transfer encoding is applied, that would entail
decoding and opening the media content to determine version
information.  If the media type is specified via
message/external-body or a similar mechanism, additional
steps are necessary to obtain the media in order to
determine version information.  If a particular instance
of content is large, that may result in a substantial waste
of resources if it turns out to have an incompatible version.
 
> If you want to do content negotiation, then consider
> using media features and media feature negotiation; with
> media features you can negotiate not only version information,
> but other parameters that might also be necessary to know
> in order to determine interpretability, e.g., availability
> of compression modes, codecs, fonts, color capabilities,
> buffer size limitations, etc.

That's fine for protocols that support negotiation, but
not all protocols do so (HTTP does, RFC 3297 layered on
top of messaging can, but FTP does not).

Summary:
o media content might contain version information, but reliance
  on that can result in wasted resources
o negotiation via content-features may be a viable mechanism
  where negotiation is possible, but it is not always
  possible (and some means of indicating version must be
  available to the content negotiation mechanism)
o proliferation of type/subtypes tags for the sole purpose
  of versioning is undesirable
that leaves parameters associated with the media type as an
efficient mechanism for indicating version information.
>From [email-masked]  Fri Feb 11 06:20:42 2005
From: blilly at erols.com (Bruce Lilly)
Date: Fri Feb 11 21:16:09 2005
Subject: Media type versioning (was: Re: Scripting Media Types)
In-Reply-To: <[email-masked]>
References: <[email-masked]>
	<[email-masked]>
	<[email-masked]>
Message-ID: <[email-masked]>

On Wed February 9 2005 16:46, Bjoern Hoehrmann wrote:

> At least in the context of HTTP, use of such parameters where media
> types provide them is not common in my experience, using them would
> typically require access to the server configuration and users that
> know about the parameters and how to configure the server accordingly;
> RFC 2854 notes that this did not work in practise. The situation might
> be different when this would be relevant for the proposed types, but
> that seems unlikely...

2854 only mentions one parameter (charset) and it seems to encourage
its use; I see no mention of problems with use of (as opposed to
failure to use) that parameter.

> Could you make a suggestion for the draft that would address your
> concern? Would it be sufficient to refer to the version parameter
> as optional parameter with an unconstrained lexical space for its
> value and with the semantics that implementations must consider any
> use of the parameter to indicate that the content is unsupported?

One approach would be to recommend or require display to the user
and confirmation before executing the content.  Since we're dealing
with potentially dangerous executable content, user confirmation
should be required anyway; providing some version information to
the user with a request for confirmation provides the user with
information which may be useful in making a decision. Structured
version information could go further; it might provide applications
with the ability to determine that execution is not possible (due
to lack of availability of some resource, or due to some
incompatibility); that could replace a request for confirmation by
an informative message (possibly localized) which would explain the
problem to the user (as opposed to simply displaying unstructured
"human-readable" versioning content, which might in fact be unreadable
to some humans due to charset and/or language issues).

As to what specific sort of structured versioning information
might be appropriate, that really depends on how the (scripting)
language versions and related compatibility issues are structured.
I can, however, offer an observation about what hasn't worked well,
and how to avoid problems which have plagued other versioning
mechanisms.

MIME itself provides for versioning via a MIME-Version header field.
The field body is defined as two dot-separated integers.  However,
there are several problems:
1. the semantics are undefined; aside from the initial version
   of 1.0, we can't tell how a hypothetical version 1.1 would be
   partially compatible, or a hypothetical version 2.0, etc.
2. the syntax is silent about leading zeroes in the integer
   parts. That's a recipe for interoperability problems.
>From [email-masked]  Fri Feb 11 06:46:29 2005
From: blilly at erols.com (Bruce Lilly)
Date: Fri Feb 11 21:16:18 2005
Subject: Scripting Media Types
In-Reply-To: <[email-masked]>
References: <[email-masked]>
	<[email-masked]>
	<[email-masked]>
Message-ID: <[email-masked]>

On Wed February 9 2005 16:46, Bjoern Hoehrmann wrote:
> * Bruce Lilly wrote:
> >You might say something like "there exist some non-MIME-compliant
> >applications that generate unregistered, non-private-use labels
> >such as 'text/javascript'  ...  such use is clearly not interoperable".
> 
> Would such a statement address your concerns in this regard, or do you
> mean wording such as "support" as you've mentioned, "the media type
> application/ecmascript", etc. should still be replaced even if I adopt
> this proposal?

My principal objection is to inappropriate use of text (image, video,
audio, model) discrete types.  I have no objection to registration
under the application discrete media type.  For that matter, there
are a number of scripting languages that have no registered media
tags ((Bourne) shell (and descendants), awk, sed, perl, python, etc.),
and all of them share certain similarities which are distinct from
the bulk of application types (which are primarily data used by
some software, as opposed to *being* software); there might well be
a rare opportunity to register a media type category for scripting
[I am not officially proposing that; I mention it only for the sake
of completeness].
 
> But why does that require the reference to be normative rather than
> informative?

A rule of thumb is that if a reference's relevant content were to
change, and that would result in some change to an implementation of
a media type handler, then that reference is almost certainly
normative.  If the reference is solely for illustrative purposes,
it is informative.
>From [email-masked]  Fri Feb 11 22:17:14 2005
From: ned.freed at mrochek.com ([email-masked])
Date: Fri Feb 11 22:23:27 2005
Subject: Media type versioning (was: Re: Scripting Media Types)
In-Reply-To: "Your message dated Thu, 10 Feb 2005 23:30:28 -0500"
	<[email-masked]>
References: <[email-masked]>
	<[email-masked]>
Message-ID: <[email-masked]>

> Summary:
> o media content might contain version information, but reliance
>   on that can result in wasted resources
> o negotiation via content-features may be a viable mechanism
>   where negotiation is possible, but it is not always
>   possible (and some means of indicating version must be
>   available to the content negotiation mechanism)
> o proliferation of type/subtypes tags for the sole purpose
>   of versioning is undesirable
> that leaves parameters associated with the media type as an
> efficient mechanism for indicating version information.

I would also add that how version information should be handled very much
depends on how the versioning is done. Versioning schemes range from single
integer affairs (V1,V2,V3) to major/minor/patch m.n.o schemes to
feature-by-feature enumerations. Some formats (e.g., PostScript) even allow
conditionalization of features that may not be supported, so documents work
everywhere but work "better" (in some sense) when certain extensions are
present.

IMO the more complex a versioning scheme is the less amemable it is to being
captured in a set of parameters. Once things pass a certain point content
negotiation needs to be used, or if it cannot be used there's no choice but to
rely on information embedded in the data.

				Ned
>From [email-masked]  Sat Feb 12 03:40:20 2005
From: LMM at acm.org (Larry Masinter)
Date: Sat Feb 12 03:40:29 2005
Subject: Media type versioning (was: Re: Scripting Media Types)
In-Reply-To: <[email-masked]>
Message-ID: <[email-masked]>

Re declarative rather than negotiation situations:

You could still use RFC 2912 "content-features" to indicate
information other than what is in the baseline. The idea
is that rather than loading up content-type with information
that is unnecessary for the purpose of content-type, add it
to a separate expression which can contain not only
version information, but other resource constraints.

I don't think anyone's defined a 'version' feature, but that
would be a good thing to work out and add to

http://www.iana.org/assignments/media-feature-tags

Larry

From: blilly at erols.com (Bruce Lilly)
Date: Tue Jan  3 16:22:55 2006
Subject: Media type versioning (was: Re: Scripting Media Types)
In-Reply-To: <[email-masked]>
References: <[email-masked]>
Message-ID: <[email-masked]>

On Thu February 10 2005 15:31, Larry Masinter wrote:

> My opinion is that content negotiation for versioning capability
> using MIME type parameters is unworkable.

Negotiation isn't always possible; sometimes it's a one-way
street.

> The use of the MIME 
> type is to describe the payload sufficiently so that you know
> HOW to process it, but the content-type label cannot (and thus
> should not) be extended in an attempt to use it to determine
> WHETHER a given processor knows enough to be able to process it.

We're in agreement that the media type/subtype tag should not
be used for versioning (that would result in an unnecessary
proliferation of tags).

> So whether version information should or should not be in
> a media type parameter depends pretty much on whether there
> is an embedded, easy-to-find version indicator in the data
> itself; if there isn't, and processors need to know the version
> to choose between different processing methods, then the
> version parameter should be mandatory. There is no strong
> use case for an optional version parameter, or in general
> for duplicating, in MIME parameters, information that is
> readily obtained from the content itself.

Maybe; if transfer encoding is applied, that would entail
decoding and opening the media content to determine version
information.  If the media type is specified via
message/external-body or a similar mechanism, additional
steps are necessary to obtain the media in order to
determine version information.  If a particular instance
of content is large, that may result in a substantial waste
of resources if it turns out to have an incompatible version.
 
> If you want to do content negotiation, then consider
> using media features and media feature negotiation; with
> media features you can negotiate not only version information,
> but other parameters that might also be necessary to know
> in order to determine interpretability, e.g., availability
> of compression modes, codecs, fonts, color capabilities,
> buffer size limitations, etc.

That's fine for protocols that support negotiation, but
not all protocols do so (HTTP does, RFC 3297 layered on
top of messaging can, but FTP does not).

Summary:
o media content might contain version information, but reliance
  on that can result in wasted resources
o negotiation via content-features may be a viable mechanism
  where negotiation is possible, but it is not always
  possible (and some means of indicating version must be
  available to the content negotiation mechanism)
o proliferation of type/subtypes tags for the sole purpose
  of versioning is undesirable
that leaves parameters associated with the media type as an
efficient mechanism for indicating version information.

From: LMM at acm.org (Larry Masinter)
Date: Thu Feb 10 21:31:52 2005
Subject: Media type versioning (was: Re: Scripting Media Types)
In-Reply-To: <[email-masked]>
Message-ID: <[email-masked]>

> I would like to hear what other ietf-types participants think about
> this. 

My opinion is that content negotiation for versioning capability
using MIME type parameters is unworkable.  The use of the MIME
type is to describe the payload sufficiently so that you know
HOW to process it, but the content-type label cannot (and thus
should not) be extended in an attempt to use it to determine
WHETHER a given processor knows enough to be able to process it.

So whether version information should or should not be in
a media type parameter depends pretty much on whether there
is an embedded, easy-to-find version indicator in the data
itself; if there isn't, and processors need to know the version
to choose between different processing methods, then the
version parameter should be mandatory. There is no strong
use case for an optional version parameter, or in general
for duplicating, in MIME parameters, information that is
readily obtained from the content itself.

If you want to do content negotiation, then consider
using media features and media feature negotiation; with
media features you can negotiate not only version information,
but other parameters that might also be necessary to know
in order to determine interpretability, e.g., availability
of compression modes, codecs, fonts, color capabilities,
buffer size limitations, etc.

Larry
-- 
http://larry.masinter.net

From: LMM at acm.org (Larry Masinter)
Date: Tue Jan  3 16:22:55 2006
Subject: Media type versioning (was: Re: Scripting Media Types)
In-Reply-To: <[email-masked]>
Message-ID: <[email-masked]>

> I would like to hear what other ietf-types participants think about
> this. 

My opinion is that content negotiation for versioning capability
using MIME type parameters is unworkable.  The use of the MIME
type is to describe the payload sufficiently so that you know
HOW to process it, but the content-type label cannot (and thus
should not) be extended in an attempt to use it to determine
WHETHER a given processor knows enough to be able to process it.

So whether version information should or should not be in
a media type parameter depends pretty much on whether there
is an embedded, easy-to-find version indicator in the data
itself; if there isn't, and processors need to know the version
to choose between different processing methods, then the
version parameter should be mandatory. There is no strong
use case for an optional version parameter, or in general
for duplicating, in MIME parameters, information that is
readily obtained from the content itself.

If you want to do content negotiation, then consider
using media features and media feature negotiation; with
media features you can negotiate not only version information,
but other parameters that might also be necessary to know
in order to determine interpretability, e.g., availability
of compression modes, codecs, fonts, color capabilities,
buffer size limitations, etc.

Larry
-- 
http://larry.masinter.net

From: harald at alvestrand.no (Harald Tveit Alvestrand)
Date: Tue Jan  3 16:22:55 2006
Subject: Seeking co-moderators(s) of the ietf-types list
In-Reply-To: <[email-masked]>
References: <[email-masked]> <[email-masked]>	<[email-masked]> <[email-masked]> <[email-masked]>
Message-ID: <DC133075BE9293D75FC6FEF1@B50854F0A9192E8EC6CDA126>

Thank you, Mark!

Details in separate message.... and apologies for being slow!

--On 24. januar 2005 12:57 -0500 Mark Baker <[email-masked]> wrote:

> Ok, thanks.
>
> I already spam-filter a handful of Wikis and mailing lists, so adding
> one more to the list wouldn't be a burden for me.  Yes, that's an
> offer. 8-)

From: derhoermi at gmx.net (Bjoern Hoehrmann)
Date: Tue Jan  3 16:22:55 2006
Subject: Scripting Media Types
In-Reply-To: <[email-masked]>
References: <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]>
Message-ID: <[email-masked]>

* Bruce Lilly wrote:
>You might say something like "there exist some non-MIME-compliant
>applications that generate unregistered, non-private-use labels
>such as 'text/javascript'  ...  such use is clearly not interoperable".

Would such a statement address your concerns in this regard, or do you
mean wording such as "support" as you've mentioned, "the media type
application/ecmascript", etc. should still be replaced even if I adopt
this proposal?

>A scripting or programming language implies an interpreter or
>compiler.  Implementers need a specification in order to
>implement interpreters and/or compilers (validating parsers,
>etc.).  Now in some cases, a specification is not publicly
>available (e.g. for proprietary formats such as application/msword),
>but that doesn't appear to apply in this case.

But why does that require the reference to be normative rather than
informative?

>I believe the registration procedure notes that IESG (not IETF) may
>assign change control under some circumstances.  Also, IETF is a
>large, vaguely-defined body consisting of many individuals, numerous
>working groups, etc.  The IESG, on the other hand, is a clearly-defined
>group which makes decisions based on parliamentary procedures, directs
>IANA and the RFC Editor, etc., with a public record of their meetings
>and decisions. See RFCs 3160, 2026, 2418.

True, but then it makes little sense for the other cited RFCs to refer
to the IETF as change controller; I will seek the IESG's advice on this
matter, I don't have strong feelings either way as long as new RFCs may
update the registration.
-- 
Bj?rn H?hrmann ? mailto:[email-masked] ? http://bjoern.hoehrmann.de
Weinh. Str. 22 ? Telefon: +49(0)621/4309674 ? http://www.bjoernsworld.de
68309 Mannheim ? PGP Pub. KeyID: 0xA4357E78 ? http://www.websitedev.de/ 

From: derhoermi at gmx.net (Bjoern Hoehrmann)
Date: Tue Jan  3 16:22:55 2006
Subject: Media type versioning (was: Re: Scripting Media Types)
In-Reply-To: <[email-masked]>
References: <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]>
Message-ID: <[email-masked]>

* Bruce Lilly wrote:
>There are no "reserved parameters"; there are required parameters and
>optional parameters.  If you believe that version information may be
>useful in one or more of the types that you seek to register, you
>might define an optional version parameter (and specify how content
>is to be handled when lacking that parameter), or if it is critical
>to interoperability, make the parameter mandatory.

I would like to hear what other ietf-types participants think about
this. I do not think there is real consensus in the IETF on how to do
versioning on the media type level, as the draft notes, implementers
have attempted to deal with this by appending version numbers to the
subtype name as in text/javascript1.1, some types use parameters to
indicate the "version" (or codec, etc) and other types, as you point
out, did not really consider this issue, for example, for the XML
media types it is not clear whether those can be used for XML 1.1,
RFC 3023 only refers to XML 1.0. An update to RFC 3023 might allow
using e.g. application/xml for XML 1.1 but that would yield in a
situation similar to that of the media type for PowerPoint content.

I do not know how the formats relevant to the draft evolve, so I do
not know at the moment whether updating the document to consider new
formats at a later point is the best way forward, or whether such a
new format should use a new media type. In response to the first draft
in 2001, ECMA TC 39 (the technical committee responsible for the
ECMAScript specification) suggested a application/ecmascript4 media
type for ECMA-262 Edition 4; my understanding is that Edition 4 is 
still not final so it lacks a public specification and such a media
type can thus not be registered in the standards tree at the moment.

I do not want to ignore this issue, hence the reserved version para-
meter. It's not meant to be an optional parameter, it is rather meant
as an anchor for error handling requirements, implementations unaware
of the parameter must not consider content that uses the parameter
supported. This would enable use of the media type for content that
would not interoperate with older implementations that do not support
the new format. There seem to be two alternate approaches to the
problem, either require implementations to consider all parameters
(but charset) as indicating unsupported content or list the parameter
as optional parameter; the former would hinder introduction of other
parameters with different semantics and implementations to implement
common error recovery behavior (i.e., ignore unknown parameters).

The latter does not make significantly more sense to me than the
current approach; as I do not know how the formats evolve, it would
be difficult to specify the lexical space of the parameter value; I
could say it must be empty or can be anything that is allowed for
parameter values, and regardless of the value, the content must be
considered unsupported. I anticipate objections to that approach.
If I specify something else, it could conflict with yet unknown
versioning policies of the format specifications. OTOH, updates of
the document could change the lexical space of the parameter value...

At least in the context of HTTP, use of such parameters where media
types provide them is not common in my experience, using them would
typically require access to the server configuration and users that
know about the parameters and how to configure the server accordingly;
RFC 2854 notes that this did not work in practise. The situation might
be different when this would be relevant for the proposed types, but
that seems unlikely...

Could you make a suggestion for the draft that would address your
concern? Would it be sufficient to refer to the version parameter
as optional parameter with an unconstrained lexical space for its
value and with the semantics that implementations must consider any
use of the parameter to indicate that the content is unsupported?
-- 
Bj?rn H?hrmann ? mailto:[email-masked] ? http://bjoern.hoehrmann.de
Weinh. Str. 22 ? Telefon: +49(0)621/4309674 ? http://www.bjoernsworld.de
68309 Mannheim ? PGP Pub. KeyID: 0xA4357E78 ? http://www.websitedev.de/ 

From: blilly at erols.com (Bruce Lilly)
Date: Wed Feb  9 20:37:15 2005
Subject: Scripting Media Types
In-Reply-To: <[email-masked]>
References: <[email-masked]> <[email-masked]> <[email-masked]>
Message-ID: <[email-masked]>

On Tue February 8 2005 22:08, Bjoern Hoehrmann wrote:
> * 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).

One cannot meaningfully speak of "support" in MIME terms for something
which is neither a registered MIME type nor in the category of types
and subtypes reserved for experimental and private-agreement use (i.e.
beginning with "x-").  Any treatment of unrecognized (i.e. unregistered,
or registered after an application's support was coded, or unrecognized
private-use) types or subtypes MUST be as documented in RFCs 2046 and 2049
for any MIME-compliant application.  In most cases, that means treating
such types as an opaque blob, i.e. as application/octet-stream.

Any application doing otherwise with unregistered type such as the ones
mentioned in your draft is clearly not MIME-compliant (a.k.a. "broken").
And that is independent of the number of instances of that non-compliant
application in the wild, or the number of inappropriately-labeled
files that those applications produce.

In short, there is a principle at work, and that principle is that text
is for humans, and is in a natural language (see RFC 2277, a.k.a. BCP
18).

> 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 [...]

First, we're discussing a specific proposal (yours); any errors (or
lack thereof) in other registrations or proposals are a separate matter.

Second, text/sgml (for example) is perfectly valid; the type refers
to textual, natural language content (with associated markup); the
media type can be presented to a user such that a user can make some
sense of the natural language content by ignoring the markup, or
markup can be applied by rendering the content for the user.  That
of course also applies to application profiles of SGML (e.g. HTML and
XML).  That does not, however, mean that any arbitrary content using
XML markup is suitable as a text subtype; see RFC 2046 sections 1 and 4.

> There are even people who would prefer to just stick with the most
> commonly used types (which would be text/javascript, etc)

Again, "commonly-used" makes little sense in terms of compliant
applications and compliance requirements, and I do not think it is
advisable to cater to broken applications by inappropriately
registering types under the text category which are not in fact
suitable text types.  The developers of the broken applications
should fix their products.

A primary goal of standardization is interoperability; developers
who do not bother to conform to registration procedures and
compliance requirements produce inherently non-interoperable products.
Registering media types inappropriately to cater to such developers
impairs interoperability by muddling the clear distinction between
media type categories; it drives the level of the whole down to
that of the (inherently non-interoperable) lowest level.

> >Second, the draft mentions the proposed types as if they were
> >already registered, which they are not. E.g."use of and support for the
> >   media type application/ecmascript is considerably less widespread
> >   than of text/ecmascript"
> 
> Could you elaborate on this point? I am not quite sure how the draft
> suggests that these types are registered,

"the media type application/ecmascript" etc. clearly implies that
there is a registered media type of that name; there is not.

> in fact, it says that they 
> are not. Maybe you can make a suggestion to rephrase the passages you
> had in mind?

You might say something like "there exist some non-MIME-compliant
applications that generate unregistered, non-private-use labels
such as 'text/javascript'  ...  such use is clearly not interoperable".

> The JavaScript Core Guide 1.5 notes "JavaScript will always include
> features that are not part of the ECMA specification; JavaScript is
> compatible with ECMA, while providing additional features." which is
> also true for JavaScript 1.5; The specification the draft references
> states which features are compatible with ECMA-262 and which aren't.

Then that's a good indication that that reference should be normative
(w.r.t. to another question below), since in order to determine
which features are (in)compatible, one must consult that reference.

> http://www.mozilla.org/js/js15.html lists some of these features. I
> thus would not say that the only difference is the name. Maybe you
> can propose wording for the draft to make this distinction clearer?
> 
> >However, if I am mistaken on that point, the distinction needs
> >to be made much clearer. [And I fail to see why the proposed
> >application/ecmascript (almost) has provision for an optional
> >"version" parameter, while the proposed application/javascript
> >has no corresponding half-provision.]
> 
> The draft notes
> 
>   This document does not define similar means for any other type as
>   deployed software typically ignores unknown parameters which renders
>   such a reserved parameter of little use for those types.

There are no "reserved parameters"; there are required parameters and
optional parameters.  If you believe that version information may be
useful in one or more of the types that you seek to register, you
might define an optional version parameter (and specify how content
is to be handled when lacking that parameter), or if it is critical
to interoperability, make the parameter mandatory.  Past experience
has shown that ignoring (or skirting) the issue is likely to lead
to interoperability problems.  Consider application/vnd/ms-powerpoint,
which lacks any provision for version indication.  It is well-known
that some versions of MS "PowerPoint" are unable to read the
incompatible and proprietary formats generated by other versions of
that application.  Five years from now, do you want people to make
the same sort of statement about application/ecmascript etc.?

Given that there is a "JavaScript 1.5", there presumably were and
will be other versions.
 
> >If the "javascript" variant is to be registered, its reference
> >should be normative rather than informative.
> 
> Per RFC 3160 "A normative reference is a reference to a document that
> must be followed in order to implement the standard." This is true for
> ECMA-262 as the draft depends on terms defined in that document, but
> an implementation of the javascript media types does not depend on the
> JavaScript specification (in my opinion), for example, a generic text
> editor may support the application/javascript type only to the extend
> of properly detecting the character encoding scheme but other than that
> beeing unaware of JavaScript. So it is not obvious to me that the re-
> ference should be normative, could you elaborate on why you think so?

A scripting or programming language implies an interpreter or
compiler.  Implementers need a specification in order to
implement interpreters and/or compilers (validating parsers,
etc.).  Now in some cases, a specification is not publicly
available (e.g. for proprietary formats such as application/msword),
but that doesn't appear to apply in this case.
 
> >Change controller should be IESG, not IETF, as I understand it.
> 
> RFC 3880, RFC 3910, RFC 3680, and RFC 3858, lists the IETF, and RFC
> 3367, RFC 3080, RFC 3288, RFC 3983, and RFC 3529 the IESG as change
> controller for the types these documents register; I could not find
> precise rules which I should use; I think the IESG knows best, so I
> would expect them to provide clarification when reviewing the document.
> Maybe I've missed a resource that provides some clarification on this
> matter?

I believe the registration procedure notes that IESG (not IETF) may
assign change control under some circumstances.  Also, IETF is a
large, vaguely-defined body consisting of many individuals, numerous
working groups, etc.  The IESG, on the other hand, is a clearly-defined
group which makes decisions based on parliamentary procedures, directs
IANA and the RFC Editor, etc., with a public record of their meetings
and decisions. See RFCs 3160, 2026, 2418.
>From [email-masked]  Wed Feb  9 22:46:04 2005
From: derhoermi at gmx.net (Bjoern Hoehrmann)
Date: Wed Feb  9 22:46:05 2005
Subject: Media type versioning (was: Re: Scripting Media Types)
In-Reply-To: <[email-masked]>
References: <[email-masked]>
	<[email-masked]>
	<[email-masked]>
	<[email-masked]>
Message-ID: <[email-masked]>

* Bruce Lilly wrote:
>There are no "reserved parameters"; there are required parameters and
>optional parameters.  If you believe that version information may be
>useful in one or more of the types that you seek to register, you
>might define an optional version parameter (and specify how content
>is to be handled when lacking that parameter), or if it is critical
>to interoperability, make the parameter mandatory.

I would like to hear what other ietf-types participants think about
this. I do not think there is real consensus in the IETF on how to do
versioning on the media type level, as the draft notes, implementers
have attempted to deal with this by appending version numbers to the
subtype name as in text/javascript1.1, some types use parameters to
indicate the "version" (or codec, etc) and other types, as you point
out, did not really consider this issue, for example, for the XML
media types it is not clear whether those can be used for XML 1.1,
RFC 3023 only refers to XML 1.0. An update to RFC 3023 might allow
using e.g. application/xml for XML 1.1 but that would yield in a
situation similar to that of the media type for PowerPoint content.

I do not know how the formats relevant to the draft evolve, so I do
not know at the moment whether updating the document to consider new
formats at a later point is the best way forward, or whether such a
new format should use a new media type. In response to the first draft
in 2001, ECMA TC 39 (the technical committee responsible for the
ECMAScript specification) suggested a application/ecmascript4 media
type for ECMA-262 Edition 4; my understanding is that Edition 4 is 
still not final so it lacks a public specification and such a media
type can thus not be registered in the standards tree at the moment.

I do not want to ignore this issue, hence the reserved version para-
meter. It's not meant to be an optional parameter, it is rather meant
as an anchor for error handling requirements, implementations unaware
of the parameter must not consider content that uses the parameter
supported. This would enable use of the media type for content that
would not interoperate with older implementations that do not support
the new format. There seem to be two alternate approaches to the
problem, either require implementations to consider all parameters
(but charset) as indicating unsupported content or list the parameter
as optional parameter; the former would hinder introduction of other
parameters with different semantics and implementations to implement
common error recovery behavior (i.e., ignore unknown parameters).

The latter does not make significantly more sense to me than the
current approach; as I do not know how the formats evolve, it would
be difficult to specify the lexical space of the parameter value; I
could say it must be empty or can be anything that is allowed for
parameter values, and regardless of the value, the content must be
considered unsupported. I anticipate objections to that approach.
If I specify something else, it could conflict with yet unknown
versioning policies of the format specifications. OTOH, updates of
the document could change the lexical space of the parameter value...

At least in the context of HTTP, use of such parameters where media
types provide them is not common in my experience, using them would
typically require access to the server configuration and users that
know about the parameters and how to configure the server accordingly;
RFC 2854 notes that this did not work in practise. The situation might
be different when this would be relevant for the proposed types, but
that seems unlikely...

Could you make a suggestion for the draft that would address your
concern? Would it be sufficient to refer to the version parameter
as optional parameter with an unconstrained lexical space for its
value and with the semantics that implementations must consider any
use of the parameter to indicate that the content is unsupported?
-- 
Bj?rn H?hrmann ? mailto:[email-masked] ? http://bjoern.hoehrmann.de
Weinh. Str. 22 ? Telefon: +49(0)621/4309674 ? http://www.bjoernsworld.de
68309 Mannheim ? PGP Pub. KeyID: 0xA4357E78 ? http://www.websitedev.de/ 
>From [email-masked]  Wed Feb  9 22:46:39 2005
From: derhoermi at gmx.net (Bjoern Hoehrmann)
Date: Wed Feb  9 22:46:38 2005
Subject: Scripting Media Types
In-Reply-To: <[email-masked]>
References: <[email-masked]>
	<[email-masked]>
	<[email-masked]>
	<[email-masked]>
Message-ID: <[email-masked]>

* Bruce Lilly wrote:
>You might say something like "there exist some non-MIME-compliant
>applications that generate unregistered, non-private-use labels
>such as 'text/javascript'  ...  such use is clearly not interoperable".

Would such a statement address your concerns in this regard, or do you
mean wording such as "support" as you've mentioned, "the media type
application/ecmascript", etc. should still be replaced even if I adopt
this proposal?

>A scripting or programming language implies an interpreter or
>compiler.  Implementers need a specification in order to
>implement interpreters and/or compilers (validating parsers,
>etc.).  Now in some cases, a specification is not publicly
>available (e.g. for proprietary formats such as application/msword),
>but that doesn't appear to apply in this case.

But why does that require the reference to be normative rather than
informative?

>I believe the registration procedure notes that IESG (not IETF) may
>assign change control under some circumstances.  Also, IETF is a
>large, vaguely-defined body consisting of many individuals, numerous
>working groups, etc.  The IESG, on the other hand, is a clearly-defined
>group which makes decisions based on parliamentary procedures, directs
>IANA and the RFC Editor, etc., with a public record of their meetings
>and decisions. See RFCs 3160, 2026, 2418.

True, but then it makes little sense for the other cited RFCs to refer
to the IETF as change controller; I will seek the IESG's advice on this
matter, I don't have strong feelings either way as long as new RFCs may
update the registration.
-- 
Bj?rn H?hrmann ? mailto:[email-masked] ? http://bjoern.hoehrmann.de
Weinh. Str. 22 ? Telefon: +49(0)621/4309674 ? http://www.bjoernsworld.de
68309 Mannheim ? PGP Pub. KeyID: 0xA4357E78 ? http://www.websitedev.de/ 
>From [email-masked]  Thu Feb 10 14:12:30 2005
From: harald at alvestrand.no (Harald Tveit Alvestrand)
Date: Thu Feb 10 14:32:45 2005
Subject: Seeking co-moderators(s) of the ietf-types list
In-Reply-To: <[email-masked]>
References: <[email-masked]>
	<[email-masked]>	<[email-masked]>
	<[email-masked]>
	<[email-masked]>
Message-ID: <DC133075BE9293D75FC6FEF1@B50854F0A9192E8EC6CDA126>

Thank you, Mark!

Details in separate message.... and apologies for being slow!

--On 24. januar 2005 12:57 -0500 Mark Baker <[email-masked]> wrote:

> Ok, thanks.
>
> I already spam-filter a handful of Wikis and mailing lists, so adding
> one more to the list wouldn't be a burden for me.  Yes, that's an
> offer. 8-)

From: blilly at erols.com (Bruce Lilly)
Date: Tue Jan  3 16:22:55 2006
Subject: Scripting Media Types
In-Reply-To: <[email-masked]>
References: <[email-masked]> <[email-masked]> <[email-masked]>
Message-ID: <[email-masked]>

On Tue February 8 2005 22:08, Bjoern Hoehrmann wrote:
> * 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).

One cannot meaningfully speak of "support" in MIME terms for something
which is neither a registered MIME type nor in the category of types
and subtypes reserved for experimental and private-agreement use (i.e.
beginning with "x-").  Any treatment of unrecognized (i.e. unregistered,
or registered after an application's support was coded, or unrecognized
private-use) types or subtypes MUST be as documented in RFCs 2046 and 2049
for any MIME-compliant application.  In most cases, that means treating
such types as an opaque blob, i.e. as application/octet-stream.

Any application doing otherwise with unregistered type such as the ones
mentioned in your draft is clearly not MIME-compliant (a.k.a. "broken").
And that is independent of the number of instances of that non-compliant
application in the wild, or the number of inappropriately-labeled
files that those applications produce.

In short, there is a principle at work, and that principle is that text
is for humans, and is in a natural language (see RFC 2277, a.k.a. BCP
18).

> 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 [...]

First, we're discussing a specific proposal (yours); any errors (or
lack thereof) in other registrations or proposals are a separate matter.

Second, text/sgml (for example) is perfectly valid; the type refers
to textual, natural language content (with associated markup); the
media type can be presented to a user such that a user can make some
sense of the natural language content by ignoring the markup, or
markup can be applied by rendering the content for the user.  That
of course also applies to application profiles of SGML (e.g. HTML and
XML).  That does not, however, mean that any arbitrary content using
XML markup is suitable as a text subtype; see RFC 2046 sections 1 and 4.

> There are even people who would prefer to just stick with the most
> commonly used types (which would be text/javascript, etc)

Again, "commonly-used" makes little sense in terms of compliant
applications and compliance requirements, and I do not think it is
advisable to cater to broken applications by inappropriately
registering types under the text category which are not in fact
suitable text types.  The developers of the broken applications
should fix their products.

A primary goal of standardization is interoperability; developers
who do not bother to conform to registration procedures and
compliance requirements produce inherently non-interoperable products.
Registering media types inappropriately to cater to such developers
impairs interoperability by muddling the clear distinction between
media type categories; it drives the level of the whole down to
that of the (inherently non-interoperable) lowest level.

> >Second, the draft mentions the proposed types as if they were
> >already registered, which they are not. E.g."use of and support for the
> >   media type application/ecmascript is considerably less widespread
> >   than of text/ecmascript"
> 
> Could you elaborate on this point? I am not quite sure how the draft
> suggests that these types are registered,

"the media type application/ecmascript" etc. clearly implies that
there is a registered media type of that name; there is not.

> in fact, it says that they 
> are not. Maybe you can make a suggestion to rephrase the passages you
> had in mind?

You might say something like "there exist some non-MIME-compliant
applications that generate unregistered, non-private-use labels
such as 'text/javascript'  ...  such use is clearly not interoperable".

> The JavaScript Core Guide 1.5 notes "JavaScript will always include
> features that are not part of the ECMA specification; JavaScript is
> compatible with ECMA, while providing additional features." which is
> also true for JavaScript 1.5; The specification the draft references
> states which features are compatible with ECMA-262 and which aren't.

Then that's a good indication that that reference should be normative
(w.r.t. to another question below), since in order to determine
which features are (in)compatible, one must consult that reference.

> http://www.mozilla.org/js/js15.html lists some of these features. I
> thus would not say that the only difference is the name. Maybe you
> can propose wording for the draft to make this distinction clearer?
> 
> >However, if I am mistaken on that point, the distinction needs
> >to be made much clearer. [And I fail to see why the proposed
> >application/ecmascript (almost) has provision for an optional
> >"version" parameter, while the proposed application/javascript
> >has no corresponding half-provision.]
> 
> The draft notes
> 
>   This document does not define similar means for any other type as
>   deployed software typically ignores unknown parameters which renders
>   such a reserved parameter of little use for those types.

There are no "reserved parameters"; there are required parameters and
optional parameters.  If you believe that version information may be
useful in one or more of the types that you seek to register, you
might define an optional version parameter (and specify how content
is to be handled when lacking that parameter), or if it is critical
to interoperability, make the parameter mandatory.  Past experience
has shown that ignoring (or skirting) the issue is likely to lead
to interoperability problems.  Consider application/vnd/ms-powerpoint,
which lacks any provision for version indication.  It is well-known
that some versions of MS "PowerPoint" are unable to read the
incompatible and proprietary formats generated by other versions of
that application.  Five years from now, do you want people to make
the same sort of statement about application/ecmascript etc.?

Given that there is a "JavaScript 1.5", there presumably were and
will be other versions.
 
> >If the "javascript" variant is to be registered, its reference
> >should be normative rather than informative.
> 
> Per RFC 3160 "A normative reference is a reference to a document that
> must be followed in order to implement the standard." This is true for
> ECMA-262 as the draft depends on terms defined in that document, but
> an implementation of the javascript media types does not depend on the
> JavaScript specification (in my opinion), for example, a generic text
> editor may support the application/javascript type only to the extend
> of properly detecting the character encoding scheme but other than that
> beeing unaware of JavaScript. So it is not obvious to me that the re-
> ference should be normative, could you elaborate on why you think so?

A scripting or programming language implies an interpreter or
compiler.  Implementers need a specification in order to
implement interpreters and/or compilers (validating parsers,
etc.).  Now in some cases, a specification is not publicly
available (e.g. for proprietary formats such as application/msword),
but that doesn't appear to apply in this case.
 
> >Change controller should be IESG, not IETF, as I understand it.
> 
> RFC 3880, RFC 3910, RFC 3680, and RFC 3858, lists the IETF, and RFC
> 3367, RFC 3080, RFC 3288, RFC 3983, and RFC 3529 the IESG as change
> controller for the types these documents register; I could not find
> precise rules which I should use; I think the IESG knows best, so I
> would expect them to provide clarification when reviewing the document.
> Maybe I've missed a resource that provides some clarification on this
> matter?

I believe the registration procedure notes that IESG (not IETF) may
assign change control under some circumstances.  Also, IETF is a
large, vaguely-defined body consisting of many individuals, numerous
working groups, etc.  The IESG, on the other hand, is a clearly-defined
group which makes decisions based on parliamentary procedures, directs
IANA and the RFC Editor, etc., with a public record of their meetings
and decisions. See RFCs 3160, 2026, 2418.

From: chris at w3.org (Chris Lilley)
Date: Wed Feb  9 10:45:52 2005
Subject: Scripting Media Types
In-Reply-To: <[email-masked]>
References: <[email-masked]> <[email-masked]> <[email-masked]>
Message-ID: <[email-masked]>

On Wednesday, February 9, 2005, 2:08:27 PM, Bjoern wrote:

BH> * 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.

BH> That's probably true, but the alternative would be to continue using the
BH> unregistered types for several years as the application/* types are much
BH> less well-supported. For example, all SVG implementations I am aware of
BH> that support relevant scripting,support text/ecmascript (as the relevant
BH> specifications suggest)

Yes

BH> while none support application/ecmascript.

because the spec doesn't say to. However, if the preferred and
registered media type was application/ecmascript, then the SVG spec
could require support for this type.

>>Second, the draft mentions the proposed types as if they were
>>already registered, which they are not. E.g."use of and support for the
>>   media type application/ecmascript is considerably less widespread
>>   than of text/ecmascript"

BH> Could you elaborate on this point? I am not quite sure how the draft
BH> suggests that these types are registered, in fact, it says that they
BH> are not. Maybe you can make a suggestion to rephrase the passages you
BH> had in mind?

Yes, it doesn't say they are registered. It says which ones are in
active use currently.

>>Fourth, I see no compelling reason to register both "javascript"
>>and "ecmascript" variants;

I do - they are related but different languages. One is defined by an
international standards group and one ( a superset) by browser vendor.

-- 
 Chris Lilley                    mailto:[email-masked]
 Chair, W3C SVG Working Group
 Member, W3C Technical Architecture Group

From: chris at w3.org (Chris Lilley)
Date: Tue Jan  3 16:22:55 2006
Subject: Scripting Media Types
In-Reply-To: <[email-masked]>
References: <[email-masked]> <[email-masked]> <[email-masked]>
Message-ID: <[email-masked]>

On Wednesday, February 9, 2005, 2:08:27 PM, Bjoern wrote:

BH> * 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.

BH> That's probably true, but the alternative would be to continue using the
BH> unregistered types for several years as the application/* types are much
BH> less well-supported. For example, all SVG implementations I am aware of
BH> that support relevant scripting,support text/ecmascript (as the relevant
BH> specifications suggest)

Yes

BH> while none support application/ecmascript.

because the spec doesn't say to. However, if the preferred and
registered media type was application/ecmascript, then the SVG spec
could require support for this type.

>>Second, the draft mentions the proposed types as if they were
>>already registered, which they are not. E.g."use of and support for the
>>   media type application/ecmascript is considerably less widespread
>>   than of text/ecmascript"

BH> Could you elaborate on this point? I am not quite sure how the draft
BH> suggests that these types are registered, in fact, it says that they
BH> are not. Maybe you can make a suggestion to rephrase the passages you
BH> had in mind?

Yes, it doesn't say they are registered. It says which ones are in
active use currently.

>>Fourth, I see no compelling reason to register both "javascript"
>>and "ecmascript" variants;

I do - they are related but different languages. One is defined by an
international standards group and one ( a superset) by browser vendor.

-- 
 Chris Lilley                    mailto:[email-masked]
 Chair, W3C SVG Working Group
 Member, W3C Technical Architecture Group

From: braden at endoframe.com (Braden McDaniel)
Date: Tue Jan  3 16:22:55 2006
Subject: Scripting Media Types
In-Reply-To: <[email-masked]>
References: <[email-masked]> <[email-masked]> <[email-masked]>
Message-ID: <[email-masked]>

On Wed, 2005-02-09 at 04:08 +0100, Bjoern Hoehrmann wrote:

[snip]

> The JavaScript Core Guide 1.5 notes "JavaScript will always include
> features that are not part of the ECMA specification; JavaScript is
> compatible with ECMA, while providing additional features." which is
> also true for JavaScript 1.5; The specification the draft references
> states which features are compatible with ECMA-262 and which aren't.

The "Core JavaScript Reference" isn't a language specification. It's my
understanding that JavaScript has no such thing; it is defined in terms
of a reference implementation, SpiderMonkey. Would it be inappropriate
to list that as a normative reference?

-- 
Braden McDaniel                           e-mail: <[email-masked]>
<http://endoframe.com>                    Jabber: <[email-masked]>

From: derhoermi at gmx.net (Bjoern Hoehrmann)
Date: Wed Feb  9 04:09:34 2005
Subject: Scripting Media Types
In-Reply-To: <[email-masked]>
References: <[email-masked]> <[email-masked]>
Message-ID: <[email-masked]>

* 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. 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.

Thus, without arguing about whether text/* is the best place for these
types (and the draft admits that it is probably not), I do not think
that this should hinder the registration of these types. If the IESG
disagrees, I might well revise the draft dropping the text/* types, but
I think a registration of these types is valuable and thus think I
should leave that decision to the IESG.

>Second, the draft mentions the proposed types as if they were
>already registered, which they are not. E.g."use of and support for the
>   media type application/ecmascript is considerably less widespread
>   than of text/ecmascript"

Could you elaborate on this point? I am not quite sure how the draft
suggests that these types are registered, in fact, it says that they
are not. Maybe you can make a suggestion to rephrase the passages you
had in mind?

>Third, I see little point in registering a media type only to
>subsequently deprecate its use: "It is expected that an update of this
>   document will deprecate the media type text/ecmascript".  Media
>may remain in archives indefinitely; if a currently-unregistered
>type name is inappropriately being used, it should not be registered
>and then promptly deprecated -- it should not be registered unless
>there is a valid reason for registration (inappropriate use w/o
>registration is not a valid reason).

See above.

>Fourth, I see no compelling reason to register both "javascript"
>and "ecmascript" variants; my understanding is that "ECMAscipt"
>is the officially (de-jure) standardized name for the scripting
>language sometimes (confusingly, because it has no relationship
>to the language known as Java) referred to as "javascript".

The JavaScript Core Guide 1.5 notes "JavaScript will always include
features that are not part of the ECMA specification; JavaScript is
compatible with ECMA, while providing additional features." which is
also true for JavaScript 1.5; The specification the draft references
states which features are compatible with ECMA-262 and which aren't.
http://www.mozilla.org/js/js15.html lists some of these features. I
thus would not say that the only difference is the name. Maybe you
can propose wording for the draft to make this distinction clearer?

>However, if I am mistaken on that point, the distinction needs
>to be made much clearer. [And I fail to see why the proposed
>application/ecmascript (almost) has provision for an optional
>"version" parameter, while the proposed application/javascript
>has no corresponding half-provision.]

The draft notes

  This document does not define similar means for any other type as
  deployed software typically ignores unknown parameters which renders
  such a reserved parameter of little use for those types.

and notes the rationale for application/ecmascript beeing a little bit
different from the other types in section 1.2. I am not sure how this
is not sufficiently clear, maybe you can elaborate on this point? I am
happy to add additional or change existing text to make this point
clearer, but at the moment I am not sure how, so I would appreciate a
suggestion.

>If the "javascript" variant is to be registered, its reference
>should be normative rather than informative.

Per RFC 3160 "A normative reference is a reference to a document that
must be followed in order to implement the standard." This is true for
ECMA-262 as the draft depends on terms defined in that document, but
an implementation of the javascript media types does not depend on the
JavaScript specification (in my opinion), for example, a generic text
editor may support the application/javascript type only to the extend
of properly detecting the character encoding scheme but other than that
beeing unaware of JavaScript. So it is not obvious to me that the re-
ference should be normative, could you elaborate on why you think so?

>Change controller should be IESG, not IETF, as I understand it.

RFC 3880, RFC 3910, RFC 3680, and RFC 3858, lists the IETF, and RFC
3367, RFC 3080, RFC 3288, RFC 3983, and RFC 3529 the IESG as change
controller for the types these documents register; I could not find
precise rules which I should use; I think the IESG knows best, so I
would expect them to provide clarification when reviewing the document.
Maybe I've missed a resource that provides some clarification on this
matter?

Thanks for your comments!
-- 
Bj?rn H?hrmann ? mailto:[email-masked] ? http://bjoern.hoehrmann.de
Weinh. Str. 22 ? Telefon: +49(0)621/4309674 ? http://www.bjoernsworld.de
68309 Mannheim ? PGP Pub. KeyID: 0xA4357E78 ? http://www.websitedev.de/ 
>From [email-masked]  Wed Feb  9 05:05:52 2005
From: braden at endoframe.com (Braden McDaniel)
Date: Wed Feb  9 05:06:00 2005
Subject: Scripting Media Types
In-Reply-To: <[email-masked]>
References: <[email-masked]>
	<[email-masked]>
	<[email-masked]>
Message-ID: <[email-masked]>

On Wed, 2005-02-09 at 04:08 +0100, Bjoern Hoehrmann wrote:

[snip]

> The JavaScript Core Guide 1.5 notes "JavaScript will always include
> features that are not part of the ECMA specification; JavaScript is
> compatible with ECMA, while providing additional features." which is
> also true for JavaScript 1.5; The specification the draft references
> states which features are compatible with ECMA-262 and which aren't.

The "Core JavaScript Reference" isn't a language specification. It's my
understanding that JavaScript has no such thing; it is defined in terms
of a reference implementation, SpiderMonkey. Would it be inappropriate
to list that as a normative reference?

-- 
Braden McDaniel                           e-mail: <[email-masked]>
<http://endoframe.com>                    Jabber: <[email-masked]>

From: derhoermi at gmx.net (Bjoern Hoehrmann)
Date: Tue Jan  3 16:22:55 2006
Subject: Scripting Media Types
In-Reply-To: <[email-masked]>
References: <[email-masked]> <[email-masked]>
Message-ID: <[email-masked]>

* 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. 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.

Thus, without arguing about whether text/* is the best place for these
types (and the draft admits that it is probably not), I do not think
that this should hinder the registration of these types. If the IESG
disagrees, I might well revise the draft dropping the text/* types, but
I think a registration of these types is valuable and thus think I
should leave that decision to the IESG.

>Second, the draft mentions the proposed types as if they were
>already registered, which they are not. E.g."use of and support for the
>   media type application/ecmascript is considerably less widespread
>   than of text/ecmascript"

Could you elaborate on this point? I am not quite sure how the draft
suggests that these types are registered, in fact, it says that they
are not. Maybe you can make a suggestion to rephrase the passages you
had in mind?

>Third, I see little point in registering a media type only to
>subsequently deprecate its use: "It is expected that an update of this
>   document will deprecate the media type text/ecmascript".  Media
>may remain in archives indefinitely; if a currently-unregistered
>type name is inappropriately being used, it should not be registered
>and then promptly deprecated -- it should not be registered unless
>there is a valid reason for registration (inappropriate use w/o
>registration is not a valid reason).

See above.

>Fourth, I see no compelling reason to register both "javascript"
>and "ecmascript" variants; my understanding is that "ECMAscipt"
>is the officially (de-jure) standardized name for the scripting
>language sometimes (confusingly, because it has no relationship
>to the language known as Java) referred to as "javascript".

The JavaScript Core Guide 1.5 notes "JavaScript will always include
features that are not part of the ECMA specification; JavaScript is
compatible with ECMA, while providing additional features." which is
also true for JavaScript 1.5; The specification the draft references
states which features are compatible with ECMA-262 and which aren't.
http://www.mozilla.org/js/js15.html lists some of these features. I
thus would not say that the only difference is the name. Maybe you
can propose wording for the draft to make this distinction clearer?

>However, if I am mistaken on that point, the distinction needs
>to be made much clearer. [And I fail to see why the proposed
>application/ecmascript (almost) has provision for an optional
>"version" parameter, while the proposed application/javascript
>has no corresponding half-provision.]

The draft notes

  This document does not define similar means for any other type as
  deployed software typically ignores unknown parameters which renders
  such a reserved parameter of little use for those types.

and notes the rationale for application/ecmascript beeing a little bit
different from the other types in section 1.2. I am not sure how this
is not sufficiently clear, maybe you can elaborate on this point? I am
happy to add additional or change existing text to make this point
clearer, but at the moment I am not sure how, so I would appreciate a
suggestion.

>If the "javascript" variant is to be registered, its reference
>should be normative rather than informative.

Per RFC 3160 "A normative reference is a reference to a document that
must be followed in order to implement the standard." This is true for
ECMA-262 as the draft depends on terms defined in that document, but
an implementation of the javascript media types does not depend on the
JavaScript specification (in my opinion), for example, a generic text
editor may support the application/javascript type only to the extend
of properly detecting the character encoding scheme but other than that
beeing unaware of JavaScript. So it is not obvious to me that the re-
ference should be normative, could you elaborate on why you think so?

>Change controller should be IESG, not IETF, as I understand it.

RFC 3880, RFC 3910, RFC 3680, and RFC 3858, lists the IETF, and RFC
3367, RFC 3080, RFC 3288, RFC 3983, and RFC 3529 the IESG as change
controller for the types these documents register; I could not find
precise rules which I should use; I think the IESG knows best, so I
would expect them to provide clarification when reviewing the document.
Maybe I've missed a resource that provides some clarification on this
matter?

Thanks for your comments!
-- 
Bj?rn H?hrmann ? mailto:[email-masked] ? http://bjoern.hoehrmann.de
Weinh. Str. 22 ? Telefon: +49(0)621/4309674 ? http://www.bjoernsworld.de
68309 Mannheim ? PGP Pub. KeyID: 0xA4357E78 ? http://www.websitedev.de/ 

From: blilly at erols.com (Bruce Lilly)
Date: Wed Feb  9 02:18:54 2005
Subject: Scripting Media Types
In-Reply-To: <[email-masked]>
References: <[email-masked]>
Message-ID: <[email-masked]>

There are a few issues:

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.

Second, the draft mentions the proposed types as if they were
already registered, which they are not. E.g."use of and support for the
   media type application/ecmascript is considerably less widespread
   than of text/ecmascript"

Third, I see little point in registering a media type only to
subsequently deprecate its use: "It is expected that an update of this
   document will deprecate the media type text/ecmascript".  Media
may remain in archives indefinitely; if a currently-unregistered
type name is inappropriately being used, it should not be registered
and then promptly deprecated -- it should not be registered unless
there is a valid reason for registration (inappropriate use w/o
registration is not a valid reason).

Fourth, I see no compelling reason to register both "javascript"
and "ecmascript" variants; my understanding is that "ECMAscipt"
is the officially (de-jure) standardized name for the scripting
language sometimes (confusingly, because it has no relationship
to the language known as Java) referred to as "javascript".
However, if I am mistaken on that point, the distinction needs
to be made much clearer. [And I fail to see why the proposed
application/ecmascript (almost) has provision for an optional
"version" parameter, while the proposed application/javascript
has no corresponding half-provision.]

If the "javascript" variant is to be registered, its reference
should be normative rather than informative.

Change controller should be IESG, not IETF, as I understand it.

From: blilly at erols.com (Bruce Lilly)
Date: Tue Jan  3 16:22:55 2006
Subject: Scripting Media Types
In-Reply-To: <[email-masked]>
References: <[email-masked]>
Message-ID: <[email-masked]>

There are a few issues:

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.

Second, the draft mentions the proposed types as if they were
already registered, which they are not. E.g."use of and support for the
   media type application/ecmascript is considerably less widespread
   than of text/ecmascript"

Third, I see little point in registering a media type only to
subsequently deprecate its use: "It is expected that an update of this
   document will deprecate the media type text/ecmascript".  Media
may remain in archives indefinitely; if a currently-unregistered
type name is inappropriately being used, it should not be registered
and then promptly deprecated -- it should not be registered unless
there is a valid reason for registration (inappropriate use w/o
registration is not a valid reason).

Fourth, I see no compelling reason to register both "javascript"
and "ecmascript" variants; my understanding is that "ECMAscipt"
is the officially (de-jure) standardized name for the scripting
language sometimes (confusingly, because it has no relationship
to the language known as Java) referred to as "javascript".
However, if I am mistaken on that point, the distinction needs
to be made much clearer. [And I fail to see why the proposed
application/ecmascript (almost) has provision for an optional
"version" parameter, while the proposed application/javascript
has no corresponding half-provision.]

If the "javascript" variant is to be registered, its reference
should be normative rather than informative.

Change controller should be IESG, not IETF, as I understand it.

From: duerst at w3.org (Martin Duerst)
Date: Tue Feb  8 12:51:48 2005
Subject: Media Types 'text/csv' and 'text/comma-separated-values'
In-Reply-To: <[email-masked]>
References: <[email-masked]> <[email-masked]> <6.0.0.20.2.20050204105514.05bcce48@localhost> <[email-masked]>
Message-ID: <6.0.0.20.2.20050208115754.02704b48@localhost>

At 06:06 05/02/06, Bruce Lilly wrote:

 >On the other hand, "comma-separated-values" is meaningful,
 >whereas neither the originally-proposed "csv" nor Martin's
 >suggested "cvs" is; and that probably explains the transcription
 >error.

Appologies for my typo. I think "csv" is known well enough for
people who use it frequently enough. It's also the customary
extension. So I don't see any problems to go with "csv".

Regards,    Martin. 

From: duerst at w3.org (Martin Duerst)
Date: Tue Jan  3 16:22:55 2006
Subject: Media Types 'text/csv' and 'text/comma-separated-values'
In-Reply-To: <[email-masked]>
References: <[email-masked]> <[email-masked]> <6.0.0.20.2.20050204105514.05bcce48@localhost> <[email-masked]>
Message-ID: <6.0.0.20.2.20050208115754.02704b48@localhost>

At 06:06 05/02/06, Bruce Lilly wrote:

 >On the other hand, "comma-separated-values" is meaningful,
 >whereas neither the originally-proposed "csv" nor Martin's
 >suggested "cvs" is; and that probably explains the transcription
 >error.

Appologies for my typo. I think "csv" is known well enough for
people who use it frequently enough. It's also the customary
extension. So I don't see any problems to go with "csv".

Regards,    Martin. 

From: joedwil at earthlink.net (Joe D Williams)
Date: Tue Jan  3 16:22:55 2006
Subject: [x3d-public] Scripting Media Types
References: <[email-masked]>
Message-ID: <000501c50d83$ef792ce0$91d9f7a5@a>

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

Looks like we need to be concerned about these types:

      * text/javascript          .js
      * text/ecmascript          .es
      * application/javascript   .js
      * application/ecmascript   .es

For X3D, it looks like we should allow (or require only)
the .es types. Only the .es types reference the ECMA spec.

Thank You and Best Regards,
Joe

----- Original Message -----
From: "Bjoern Hoehrmann" <[email-masked]>
To: <[email-masked]>
Sent: February 07, 2005 1:38 PM
Subject: [x3d-public] Scripting Media Types

> Hi,
>
>   A new Internet-Draft is available from the online Internet-Drafts
> directories. This memo describes media types for the ECMAScript and
> JavaScript programming languages.
>
> http://www.ietf.org/internet-drafts/draft-hoehrmann-script-types-01.txt
> http://www.websitedev.de/ietf/draft-hoehrmann-script-types-01.txt
>
> Please send comments to the ietf-types mailing list, refer to
>
>   http://www.alvestrand.no/mailman/listinfo/ietf-types
>
> for details. If no major issues arise, I'll ask the IESG to consider
> the document for publication as Informational RFC in about two weeks.
>
> Thanks,
> --
> Bj?rn H?hrmann ? mailto:[email-masked] ? http://bjoern.hoehrmann.de
> Weinh. Str. 22 ? Telefon: +49(0)621/4309674 ? http://www.bjoernsworld.de
> 68309 Mannheim ? PGP Pub. KeyID: 0xA4357E78 ? http://www.websitedev.de/
> -------------------------------------------------------------------------
> for list subscription/unsubscription,
> go to http://www.web3d.org/cgi-bin/public_list_signup/lwgate/listsavail.html
>

From: derhoermi at gmx.net (Bjoern Hoehrmann)
Date: Tue Jan  3 16:22:55 2006
Subject: Scripting Media Types
Message-ID: <[email-masked]>

Hi,

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

? http://www.ietf.org/internet-drafts/draft-hoehrmann-script-types-01.txt
? http://www.websitedev.de/ietf/draft-hoehrmann-script-types-01.txt

Please send comments to the ietf-types mailing list, refer to

  http://www.alvestrand.no/mailman/listinfo/ietf-types

for details. If no major issues arise, I'll ask the IESG to consider
the document for publication as Informational RFC in about two weeks.

Thanks,
-- 
Bj?rn H?hrmann ? mailto:[email-masked] ? http://bjoern.hoehrmann.de
Weinh. Str. 22 ? Telefon: +49(0)621/4309674 ? http://www.bjoernsworld.de
68309 Mannheim ? PGP Pub. KeyID: 0xA4357E78 ? http://www.websitedev.de/ 

From: iana at iana.org (Tim Mckinley)
Date: Tue Jan  3 16:22:55 2006
Subject: Discount generic drugs
Message-ID: <[email-masked]>

An HTML attachment was scrubbed...
URL: http://www.alvestrand.no/pipermail/ietf-types/attachments/20050207/92623ba9/attachment.html
>From [email-masked]  Sat Feb  5 00:07:21 2005
From: mhammer at cisco.com (Mike Hammer)
Date: Tue Jan  3 16:22:55 2006
Subject: Updated Registration of media type "application/nss"
Message-ID: <[email-masked]>

(Second try)

This email requests that the IESG approve the assignment of the 
media subtype as described in the registration template below.

Reference:  draft-freed-media-type-reg-02.txt, January 11, 2005,
            Media Type Specifications and Registration Procedures, 
            Section 5, Registration Procedures,
            Section 10, Registration Template.

To: [email-masked]
Subject: Registration of media type "application/nss"

Type name: application

Subtype name: nss

Required parameters: none

Optional parameters: charset

Encoding considerations: binary (Note:  Data is in US-ASCII range.)

Security considerations: 

   NSS has the potential to disclose private customer information
   and the potential for modification of NSS bodies during message
   transport to manipulate call setup, mid-call events, or call 
   release.  Modification means the addition of an NSS body where
   none existed, the removal of an NSS body where one existed, or 
   the changing of contents of existing NSS bodies in messages.   
   NSS can reveal information about telephone subscribers that is 
   requested to remain private.  Security mechanisms must be 
   provided to meet privacy agreements and regulations.  

   NSS can be deployed as an interdomain signaling mechanism and 
   may be subject to trust relationships and agreements between 
   administrative domains as well as legal requirements in various 
   jurisdictions.  NSS can affect routing of telephone calls and 
   associated billing.  Security mechanisms must be provided to 
   control fraud, malicious intents, and unintended consequences.

   Such mechanisms include the ability to selectively filter or map
   and forward each information element within NSS upon entry or exit
   of an administrative domain.  It is expected that nodes performing
   such functions will be User Agents, such as gateway nodes or 
   IP-based Application servers acting on behalf of users.  Note that
   RFC 3261 Section 16.6 says:  "The proxy MUST NOT add to, modify, 
   or remove the message body."  That includes NSS bodies.  All 
   information from unauthenticated entities must be validated and 
   authorized before being mapped and forwarded in subsequent signaling
   messages.  Such checks are particularly needed when information is 
   mapped to/from SIP headers.  Note, however, that the intent of NSS
   is to carry data that would be mutually exclusive with the data 
   capable of being carried in SIP headers.

   When encapsulated by SIP, the integrity and confidentiality of SIP 
   messages containing NSS bodies must be addressed.  SIP mandates that 
   Transport Layer Security (TLS) must be supported.  The Internet 
   Protocol Security (IPSEC) mechanisms may be used as an alternative 
   on signaling hops between nodes trusted to handle PSTN signaling. 
   TLS and IPSEC are discussed in Section 26 of the Session 
   Initiation Protocol RFC 3261.  However, trusted nodes would need 
   to specify and agree on the security suites to be used with IPSEC.
   See RFC 3324 for discussion on trust domains and related security
   requirements.

   When intermediate hops are not trusted, end-to-end integrity and 
   confidentiality may be addressed using S/MIME:

     RFC 3850, "Secure/Multipurpose Internet Mail Extensions (S/MIME)
     Version 3.1 Certificate Handling", July 2004.

     RFC 3851, "Secure/Multipurpose Internet Mail Extensions (S/MIME)
     Version 3.1 Message Specification", July 2004.

     RFC 3852, "Cryptographic Message Syntax (CMS)", July 2004.

     RFC 3853, "S/MIME Advanced Encryption Standard (AES) Requirement 
     for the Session Initiation Protocol (SIP)", July 2004.

   NSS MIME bodies should be secured using S/MIME to mitigate
   concerns with authentication of the sender, integrity protection 
   during transit, and confidentiality protection from disclosure to 
   unauthorized third parties.  NSS endpoints must support S/MIME 
   signatures and should support S/MIME encryption.  

   For H.323-based encapsulation of NSS bodies, the security mechanisms
   of ITU-T Recommendation H.235, "Security and encryption for H-series
   (H.323 and other H.245-based) multimedia terminals", August 2003, must 
   be used to provide integrity and confidentiality.

   NSS consists of well defined message types and parameters.  Arbitrary 
   content or directives within field values is not permitted.

   NSS does not employ "active content."

   NSS contains fields which instruct whether privacy data such as 
   calling party's number is to be presented or restricted.

   NSS is used without and is silent about compression.  Use of compression 
   in conjunction with NSS does not present any security issues.

Interoperability considerations:  Compatibility mechanisms are 
   defined in Q.1980.1.

Published specification:  ITU-T Recommendation Q.1980.1, "The Narrowband 
   Signalling Syntax (NSS) - Syntax Definition", December 2004.  Link:
 
http://www.itu.int/rec/recommendation.asp?type=folders&lang=e&parent=T-REC-Q
.1980.1

Applications which use this media type:  Applications in PSTN
   Gateways and call control application servers.

Additional Information:

   Magic numbers:  None

   File Extensions:  None

   Macintosh File Type Codes:  None

   Object Identifiers:  {itu-t(0) recommendation(0) q(17) 1980 1}
                        (0.0.17.1980.1)
      See ITU-T Recommendation H.323 Annex M.4 "Tunneling of 
      Narrowband Signalling Syntax (NSS) for H.323", December 2004.

Person to contact for further information:

   Name:  Michael Hammer
   E-Mail:  [email-masked]

Intended Usage:  COMMON

Restrictions on usage:  None

Author:  ITU-T Study Group 11

Change controller:  ITU-T Study Group 11

END

From: blilly at erols.com (Bruce Lilly)
Date: Sat Feb  5 22:15:24 2005
Subject: Media Types 'text/csv' and 'text/comma-separated-values'
In-Reply-To: <6.0.0.20.2.20050204105514.05bcce48@localhost>
References: <[email-masked]> <[email-masked]> <6.0.0.20.2.20050204105514.05bcce48@localhost>
Message-ID: <[email-masked]>

On Thu February 3 2005 20:56, Martin Duerst wrote:
> Hello Yakov,
> 
> As far as I know, there is no convention that would force either
> text/comma-separated-values or text/cvs. My suggestion is to
> pick one, and have implementations converge on it. I'd personally
> prefer text/cvs, just because it's shorter.

On the other hand, "comma-separated-values" is meaningful,
whereas neither the originally-proposed "csv" nor Martin's
suggested "cvs" is; and that probably explains the transcription
error.
>From [email-masked]  Mon Feb  7 22:38:34 2005
From: derhoermi at gmx.net (Bjoern Hoehrmann)
Date: Mon Feb  7 22:38:35 2005
Subject: Scripting Media Types
Message-ID: <[email-masked]>

Hi,

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

? http://www.ietf.org/internet-drafts/draft-hoehrmann-script-types-01.txt
? http://www.websitedev.de/ietf/draft-hoehrmann-script-types-01.txt

Please send comments to the ietf-types mailing list, refer to

  http://www.alvestrand.no/mailman/listinfo/ietf-types

for details. If no major issues arise, I'll ask the IESG to consider
the document for publication as Informational RFC in about two weeks.

Thanks,
-- 
Bj?rn H?hrmann ? mailto:[email-masked] ? http://bjoern.hoehrmann.de
Weinh. Str. 22 ? Telefon: +49(0)621/4309674 ? http://www.bjoernsworld.de
68309 Mannheim ? PGP Pub. KeyID: 0xA4357E78 ? http://www.websitedev.de/ 
>From [email-masked]  Mon Feb  7 06:34:40 2005
From: iana at iana.org (Tim Mckinley)
Date: Tue Feb  8 06:51:11 2005
Subject: Discount generic drugs
Message-ID: <[email-masked]>

An HTML attachment was scrubbed...
URL: http://eikenes.alvestrand.no/pipermail/ietf-types/attachments/20050207/92623ba9/attachment.htm
>From [email-masked]  Sat Feb  5 00:07:21 2005
From: mhammer at cisco.com (Mike Hammer)
Date: Tue Feb  8 10:25:56 2005
Subject: Updated Registration of media type "application/nss"
Message-ID: <[email-masked]>

(Second try)

This email requests that the IESG approve the assignment of the 
media subtype as described in the registration template below.

Reference:  draft-freed-media-type-reg-02.txt, January 11, 2005,
            Media Type Specifications and Registration Procedures, 
            Section 5, Registration Procedures,
            Section 10, Registration Template.

To: [email-masked]
Subject: Registration of media type "application/nss"

Type name: application

Subtype name: nss

Required parameters: none

Optional parameters: charset

Encoding considerations: binary (Note:  Data is in US-ASCII range.)

Security considerations: 

   NSS has the potential to disclose private customer information
   and the potential for modification of NSS bodies during message
   transport to manipulate call setup, mid-call events, or call 
   release.  Modification means the addition of an NSS body where
   none existed, the removal of an NSS body where one existed, or 
   the changing of contents of existing NSS bodies in messages.   
   NSS can reveal information about telephone subscribers that is 
   requested to remain private.  Security mechanisms must be 
   provided to meet privacy agreements and regulations.  

   NSS can be deployed as an interdomain signaling mechanism and 
   may be subject to trust relationships and agreements between 
   administrative domains as well as legal requirements in various 
   jurisdictions.  NSS can affect routing of telephone calls and 
   associated billing.  Security mechanisms must be provided to 
   control fraud, malicious intents, and unintended consequences.

   Such mechanisms include the ability to selectively filter or map
   and forward each information element within NSS upon entry or exit
   of an administrative domain.  It is expected that nodes performing
   such functions will be User Agents, such as gateway nodes or 
   IP-based Application servers acting on behalf of users.  Note that
   RFC 3261 Section 16.6 says:  "The proxy MUST NOT add to, modify, 
   or remove the message body."  That includes NSS bodies.  All 
   information from unauthenticated entities must be validated and 
   authorized before being mapped and forwarded in subsequent signaling
   messages.  Such checks are particularly needed when information is 
   mapped to/from SIP headers.  Note, however, that the intent of NSS
   is to carry data that would be mutually exclusive with the data 
   capable of being carried in SIP headers.

   When encapsulated by SIP, the integrity and confidentiality of SIP 
   messages containing NSS bodies must be addressed.  SIP mandates that 
   Transport Layer Security (TLS) must be supported.  The Internet 
   Protocol Security (IPSEC) mechanisms may be used as an alternative 
   on signaling hops between nodes trusted to handle PSTN signaling. 
   TLS and IPSEC are discussed in Section 26 of the Session 
   Initiation Protocol RFC 3261.  However, trusted nodes would need 
   to specify and agree on the security suites to be used with IPSEC.
   See RFC 3324 for discussion on trust domains and related security
   requirements.

   When intermediate hops are not trusted, end-to-end integrity and 
   confidentiality may be addressed using S/MIME:

     RFC 3850, "Secure/Multipurpose Internet Mail Extensions (S/MIME)
     Version 3.1 Certificate Handling", July 2004.

     RFC 3851, "Secure/Multipurpose Internet Mail Extensions (S/MIME)
     Version 3.1 Message Specification", July 2004.

     RFC 3852, "Cryptographic Message Syntax (CMS)", July 2004.

     RFC 3853, "S/MIME Advanced Encryption Standard (AES) Requirement 
     for the Session Initiation Protocol (SIP)", July 2004.

   NSS MIME bodies should be secured using S/MIME to mitigate
   concerns with authentication of the sender, integrity protection 
   during transit, and confidentiality protection from disclosure to 
   unauthorized third parties.  NSS endpoints must support S/MIME 
   signatures and should support S/MIME encryption.  

   For H.323-based encapsulation of NSS bodies, the security mechanisms
   of ITU-T Recommendation H.235, "Security and encryption for H-series
   (H.323 and other H.245-based) multimedia terminals", August 2003, must 
   be used to provide integrity and confidentiality.

   NSS consists of well defined message types and parameters.  Arbitrary 
   content or directives within field values is not permitted.

   NSS does not employ "active content."

   NSS contains fields which instruct whether privacy data such as 
   calling party's number is to be presented or restricted.

   NSS is used without and is silent about compression.  Use of compression 
   in conjunction with NSS does not present any security issues.

Interoperability considerations:  Compatibility mechanisms are 
   defined in Q.1980.1.

Published specification:  ITU-T Recommendation Q.1980.1, "The Narrowband 
   Signalling Syntax (NSS) - Syntax Definition", December 2004.  Link:
 
http://www.itu.int/rec/recommendation.asp?type=folders&lang=e&parent=T-REC-Q
.1980.1

Applications which use this media type:  Applications in PSTN
   Gateways and call control application servers.

Additional Information:

   Magic numbers:  None

   File Extensions:  None

   Macintosh File Type Codes:  None

   Object Identifiers:  {itu-t(0) recommendation(0) q(17) 1980 1}
                        (0.0.17.1980.1)
      See ITU-T Recommendation H.323 Annex M.4 "Tunneling of 
      Narrowband Signalling Syntax (NSS) for H.323", December 2004.

Person to contact for further information:

   Name:  Michael Hammer
   E-Mail:  [email-masked]

Intended Usage:  COMMON

Restrictions on usage:  None

Author:  ITU-T Study Group 11

Change controller:  ITU-T Study Group 11

END
>From [email-masked]  Tue Feb  8 03:14:32 2005
From: joedwil at earthlink.net (Joe D Williams)
Date: Tue Feb  8 10:25:59 2005
Subject: [x3d-public] Scripting Media Types
References: <[email-masked]>
Message-ID: <000501c50d83$ef792ce0$91d9f7a5@a>

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

Looks like we need to be concerned about these types:

      * text/javascript          .js
      * text/ecmascript          .es
      * application/javascript   .js
      * application/ecmascript   .es

For X3D, it looks like we should allow (or require only)
the .es types. Only the .es types reference the ECMA spec.

Thank You and Best Regards,
Joe

----- Original Message -----
From: "Bjoern Hoehrmann" <[email-masked]>
To: <[email-masked]>
Sent: February 07, 2005 1:38 PM
Subject: [x3d-public] Scripting Media Types

> Hi,
>
>   A new Internet-Draft is available from the online Internet-Drafts
> directories. This memo describes media types for the ECMAScript and
> JavaScript programming languages.
>
> http://www.ietf.org/internet-drafts/draft-hoehrmann-script-types-01.txt
> http://www.websitedev.de/ietf/draft-hoehrmann-script-types-01.txt
>
> Please send comments to the ietf-types mailing list, refer to
>
>   http://www.alvestrand.no/mailman/listinfo/ietf-types
>
> for details. If no major issues arise, I'll ask the IESG to consider
> the document for publication as Informational RFC in about two weeks.
>
> Thanks,
> --
> Bj?rn H?hrmann ? mailto:[email-masked] ? http://bjoern.hoehrmann.de
> Weinh. Str. 22 ? Telefon: +49(0)621/4309674 ? http://www.bjoernsworld.de
> 68309 Mannheim ? PGP Pub. KeyID: 0xA4357E78 ? http://www.websitedev.de/
> -------------------------------------------------------------------------
> for list subscription/unsubscription,
> go to http://www.web3d.org/cgi-bin/public_list_signup/lwgate/listsavail.html
>

From: blilly at erols.com (Bruce Lilly)
Date: Tue Jan  3 16:22:55 2006
Subject: Media Types 'text/csv' and 'text/comma-separated-values'
In-Reply-To: <6.0.0.20.2.20050204105514.05bcce48@localhost>
References: <[email-masked]> <[email-masked]> <6.0.0.20.2.20050204105514.05bcce48@localhost>
Message-ID: <[email-masked]>

On Thu February 3 2005 20:56, Martin Duerst wrote:
> Hello Yakov,
> 
> As far as I know, there is no convention that would force either
> text/comma-separated-values or text/cvs. My suggestion is to
> pick one, and have implementations converge on it. I'd personally
> prefer text/cvs, just because it's shorter.

On the other hand, "comma-separated-values" is meaningful,
whereas neither the originally-proposed "csv" nor Martin's
suggested "cvs" is; and that probably explains the transcription
error.

From: dbooth at w3.org (David Booth)
Date: Fri Feb  4 22:45:44 2005
Subject: Proposed media type registration: application/wsdl+xml
Message-ID: <[email-masked]>

This proposed media type registration was previously sent to
[email-masked] on 04-Oct-2004:
http://eikenes.alvestrand.no/pipermail/ietf-types/2004-October/000438.html

The only comment received (which was sent privately) was a suggested
change to the contact information to read:
[[
Person & email address to contact for further information:
	World Wide Web Consortium <[email-masked]>
]]

The version below reflects the above-mentioned change.

----------------------------------------------------------

The proposed registration below is for a media type
"application/wsdl+xml" for use with WSDL 2.0 documents.
The registration will be requested on behalf
of the W3C Web Services Description Working Group.
WSDL 2.0 documents are used to describe Web services.
The specification of the WSDL 2.0 language itself
is available at http://www.w3.org/TR/wsdl20 .
This media type definition appears in
http://www.w3.org/TR/wsdl20#ietf-draft , which will
be updated as necessary.  (The version below is the most
recent.)

This proposed registration is for community review and
will be submitted to the IESG for review, approval, and
registration with IANA at a later stage.

The Last Call period for WSDL 2.0 ends 4 October 2004.
However, because of this late notification, the deadline
for comments on the media type registration has been
extended to 18 October 2004.

=======================================================

To: [email-masked] 
Subject: Registration of media type application/wsdl+xml

Type name:
	application

Subtype name:
	wsdl+xml

Required parameters:
	none

Optional parameters:
	charset
		This parameter has identical semantics
		to the charset parameter of the
		"application/xml" media type as specified
		in [RFC 3023] 
		( http://www.ietf.org/rfc/rfc3023.txt ).

Encoding considerations:
	Identical to those of "application/xml" as
	described in [RFC 3023] 
	( http://www.ietf.org/rfc/rfc3023.txt )
	section 3.2, as applied
	to the WSDL document infoset.

Restrictions on usage:
	none

Security considerations:
	This media type uses the "+xml" convention.
	It shares the same security considerations as
	described in [RFC 3023] 
	( http://www.ietf.org/rfc/rfc3023.txt )
	section 10.

Interoperability considerations:
	There are no known interoperability issues.

Published specification:
	[WSDL 2.0 Core Language] 
	( http://www.w3.org/TR/wsdl20 ),
	[WSDL 2.0 Predefined Extensions] 
	( http://www.w3.org/TR/wsdl20-extensions ),
	and [WSDL 2.0 Bindings]
	( http://www.w3.org/TR/wsdl20-bindings ).

Applications which use this media type:
	No known applications currently use this media
	type.

Additional information:

	Magic number(s):
		In general, the same as for application/xml
		[RFC 3023] 
		( http://www.ietf.org/rfc/rfc3023.txt ).
		In particular, the XML root
		element of the returned object will be
		<wsdl:description>, where "wsdl" as any
		namespace prefix that maps to a WSDL 2.0
		namespace URI, as defined in [WSDL 2.0
		Core Language]
		( http://www.w3.org/TR/wsdl20 ).

	File extension(s):
		wsdl

	Macintosh File Type Code(s):
		WSDL

	Base URI:
		As specified in [RFC 3023]
		( http://www.ietf.org/rfc/rfc3023.txt )
		section 6.

	Fragment identifiers:
		As specified in [WSDL 2.0 FragIDs].

Person & email address to contact for further information:
	World Wide Web Consortium <[email-masked]>

Intended usage:
	COMMON

Author/Change controller:
	The WSDL 2.0 specification set is a work product
	of the World Wide Web Consortium's Web Service
	Description Working Group [WSDL 2.0 WG]. The W3C
	has change control over these specifications.

References:

[RFC 3023]
	IETF "RFC 3023: XML Media Types", M. Murata,
	S. St. Laurent, D. Kohn, July 1998. (See
	http://www.ietf.org/rfc/rfc3023.txt .)

[WSDL 2.0 Core Language]
	Web Services Description Language (WSDL) Version
	2.0 Part 1: Core Language, R. Chinnici, M. Gudgin,
	J-J. Moreau, S. Weerawarana, Editors. World Wide
	Web Consortium, 3 August 2004. This version
	of the "Web Services Description Language
	(WSDL) Version 2.0 Part 1: Core Language"
	Specification is available is available at
	http://www.w3.org/TR/2004/WD-wsdl20-20040803 . The
	latest version of "Web Services Description
	Language (WSDL) Version 2.0 Part 1: Core Language"
	is available at http://www.w3.org/TR/wsdl20 .

[WSDL 2.0 FragIDs]
	WSDL 2.0 Fragment Identifiers.	This is
	a subsection of [WSDL 2.0 Core Language]
	above.	The latest version is available at
	http://www.w3.org/TR/wsdl20/#frag-ids

[WSDL 2.0 Predefined Extensions]
	Web Services Description Language (WSDL) Version
	2.0 Part 2: Predefined Extensions, M. Gudgin,
	A. Lewis, and J. Schlimmer, Editors. World
	Wide Web Consortium, 3 August 2004. This
	version of the "Web Services Description
	Language (WSDL) Version 2.0 Part 2: Predefined
	Extensions" Specification is available at
	http://www.w3.org/TR/2004/WD-wsdl20-extensions-20040803 .
	The latest version of "Web Services
	Description Language (WSDL) Version 2.0 Part
	2: Predefined Extensions" is available at
	http://www.w3.org/TR/wsdl20-extensions .

[WSDL 2.0 Bindings]
	Web Services Description Language (WSDL)
	Version 2.0 Part 3: Bindings, H. Haas, P. Le
	H?garet, J-J. Moreau, D. Orchard, J. Schlimmer,
	Editors. World Wide Web Consortium, 3 August
	2004. This version of the "Web Services
	Description Language (WSDL) Version 2.0 Part
	3: Bindings" Specification is available at
	http://www.w3.org/TR/2004/WD-wsdl20-bindings-20040803 .
	The latest version of "Web Services Description
	Language (WSDL) Version 2.0 Part 3: Bindings" is
	available at http://www.w3.org/TR/wsdl20-bindings .

[WSDL 2.0 WG]
	The W3C Web Services Description Working Group.
	Information about this Working Group is available
	at http://www.w3.org/2002/ws/desc/

[XML 1.0]
	Extensible Markup Language (XML) 1.0
	(Second Edition), T. Bray, J. Paoli,
	C. M. Sperberg-McQueen, and E. Maler,
	Editors. World Wide Web Consortium, 10
	February 1998, revised 6 October 2000. This
	version of the XML 1.0 Recommendation is
	http://www.w3.org/TR/2000/REC-xml-20001006 . The
	latest version of XML 1.0 is available at
	http://www.w3.org/TR/REC-xml .

--------------------

The proposal above was prepared following instructions at
http://www.ietf.org/internet-drafts/draft-freed-media-type-reg-01.txt ,
and further instructions at
http://www.w3.org/2002/06/registering-mediatype.html ,
since this is a media type from W3C.
-- 

David Booth
W3C Fellow / Hewlett-Packard

From: dbooth at w3.org (David Booth)
Date: Tue Jan  3 16:22:55 2006
Subject: Proposed media type registration: application/wsdl+xml
Message-ID: <[email-masked]>

This proposed media type registration was previously sent to
[email-masked] on 04-Oct-2004:
http://eikenes.alvestrand.no/pipermail/ietf-types/2004-October/000438.html

The only comment received (which was sent privately) was a suggested
change to the contact information to read:
[[
Person & email address to contact for further information:
	World Wide Web Consortium <[email-masked]>
]]

The version below reflects the above-mentioned change.

----------------------------------------------------------

The proposed registration below is for a media type
"application/wsdl+xml" for use with WSDL 2.0 documents.
The registration will be requested on behalf
of the W3C Web Services Description Working Group.
WSDL 2.0 documents are used to describe Web services.
The specification of the WSDL 2.0 language itself
is available at http://www.w3.org/TR/wsdl20 .
This media type definition appears in
http://www.w3.org/TR/wsdl20#ietf-draft , which will
be updated as necessary.  (The version below is the most
recent.)

This proposed registration is for community review and
will be submitted to the IESG for review, approval, and
registration with IANA at a later stage.

The Last Call period for WSDL 2.0 ends 4 October 2004.
However, because of this late notification, the deadline
for comments on the media type registration has been
extended to 18 October 2004.

=======================================================

To: [email-masked] 
Subject: Registration of media type application/wsdl+xml

Type name:
	application

Subtype name:
	wsdl+xml

Required parameters:
	none

Optional parameters:
	charset
		This parameter has identical semantics
		to the charset parameter of the
		"application/xml" media type as specified
		in [RFC 3023] 
		( http://www.ietf.org/rfc/rfc3023.txt ).

Encoding considerations:
	Identical to those of "application/xml" as
	described in [RFC 3023] 
	( http://www.ietf.org/rfc/rfc3023.txt )
	section 3.2, as applied
	to the WSDL document infoset.

Restrictions on usage:
	none

Security considerations:
	This media type uses the "+xml" convention.
	It shares the same security considerations as
	described in [RFC 3023] 
	( http://www.ietf.org/rfc/rfc3023.txt )
	section 10.

Interoperability considerations:
	There are no known interoperability issues.

Published specification:
	[WSDL 2.0 Core Language] 
	( http://www.w3.org/TR/wsdl20 ),
	[WSDL 2.0 Predefined Extensions] 
	( http://www.w3.org/TR/wsdl20-extensions ),
	and [WSDL 2.0 Bindings]
	( http://www.w3.org/TR/wsdl20-bindings ).

Applications which use this media type:
	No known applications currently use this media
	type.

Additional information:

	Magic number(s):
		In general, the same as for application/xml
		[RFC 3023] 
		( http://www.ietf.org/rfc/rfc3023.txt ).
		In particular, the XML root
		element of the returned object will be
		<wsdl:description>, where "wsdl" as any
		namespace prefix that maps to a WSDL 2.0
		namespace URI, as defined in [WSDL 2.0
		Core Language]
		( http://www.w3.org/TR/wsdl20 ).

	File extension(s):
		wsdl

	Macintosh File Type Code(s):
		WSDL

	Base URI:
		As specified in [RFC 3023]
		( http://www.ietf.org/rfc/rfc3023.txt )
		section 6.

	Fragment identifiers:
		As specified in [WSDL 2.0 FragIDs].

Person & email address to contact for further information:
	World Wide Web Consortium <[email-masked]>

Intended usage:
	COMMON

Author/Change controller:
	The WSDL 2.0 specification set is a work product
	of the World Wide Web Consortium's Web Service
	Description Working Group [WSDL 2.0 WG]. The W3C
	has change control over these specifications.

References:

[RFC 3023]
	IETF "RFC 3023: XML Media Types", M. Murata,
	S. St. Laurent, D. Kohn, July 1998. (See
	http://www.ietf.org/rfc/rfc3023.txt .)

[WSDL 2.0 Core Language]
	Web Services Description Language (WSDL) Version
	2.0 Part 1: Core Language, R. Chinnici, M. Gudgin,
	J-J. Moreau, S. Weerawarana, Editors. World Wide
	Web Consortium, 3 August 2004. This version
	of the "Web Services Description Language
	(WSDL) Version 2.0 Part 1: Core Language"
	Specification is available is available at
	http://www.w3.org/TR/2004/WD-wsdl20-20040803 . The
	latest version of "Web Services Description
	Language (WSDL) Version 2.0 Part 1: Core Language"
	is available at http://www.w3.org/TR/wsdl20 .

[WSDL 2.0 FragIDs]
	WSDL 2.0 Fragment Identifiers.	This is
	a subsection of [WSDL 2.0 Core Language]
	above.	The latest version is available at
	http://www.w3.org/TR/wsdl20/#frag-ids

[WSDL 2.0 Predefined Extensions]
	Web Services Description Language (WSDL) Version
	2.0 Part 2: Predefined Extensions, M. Gudgin,
	A. Lewis, and J. Schlimmer, Editors. World
	Wide Web Consortium, 3 August 2004. This
	version of the "Web Services Description
	Language (WSDL) Version 2.0 Part 2: Predefined
	Extensions" Specification is available at
	http://www.w3.org/TR/2004/WD-wsdl20-extensions-20040803 .
	The latest version of "Web Services
	Description Language (WSDL) Version 2.0 Part
	2: Predefined Extensions" is available at
	http://www.w3.org/TR/wsdl20-extensions .

[WSDL 2.0 Bindings]
	Web Services Description Language (WSDL)
	Version 2.0 Part 3: Bindings, H. Haas, P. Le
	H?garet, J-J. Moreau, D. Orchard, J. Schlimmer,
	Editors. World Wide Web Consortium, 3 August
	2004. This version of the "Web Services
	Description Language (WSDL) Version 2.0 Part
	3: Bindings" Specification is available at
	http://www.w3.org/TR/2004/WD-wsdl20-bindings-20040803 .
	The latest version of "Web Services Description
	Language (WSDL) Version 2.0 Part 3: Bindings" is
	available at http://www.w3.org/TR/wsdl20-bindings .

[WSDL 2.0 WG]
	The W3C Web Services Description Working Group.
	Information about this Working Group is available
	at http://www.w3.org/2002/ws/desc/

[XML 1.0]
	Extensible Markup Language (XML) 1.0
	(Second Edition), T. Bray, J. Paoli,
	C. M. Sperberg-McQueen, and E. Maler,
	Editors. World Wide Web Consortium, 10
	February 1998, revised 6 October 2000. This
	version of the XML 1.0 Recommendation is
	http://www.w3.org/TR/2000/REC-xml-20001006 . The
	latest version of XML 1.0 is available at
	http://www.w3.org/TR/REC-xml .

--------------------

The proposal above was prepared following instructions at
http://www.ietf.org/internet-drafts/draft-freed-media-type-reg-01.txt ,
and further instructions at
http://www.w3.org/2002/06/registering-mediatype.html ,
since this is a media type from W3C.
-- 

David Booth
W3C Fellow / Hewlett-Packard

From: duerst at w3.org (Martin Duerst)
Date: Sat Feb  5 08:22:56 2005
Subject: Media Types 'text/csv' and 'text/comma-separated-values'
In-Reply-To: <[email-masked]>
References: <[email-masked]> <6.0.0.20.2.20050203171705.04098430@localhost> <[email-masked]>
Message-ID: <6.0.0.20.2.20050204105514.05bcce48@localhost>

Hello Yakov,

As far as I know, there is no convention that would force either
text/comma-separated-values or text/cvs. My suggestion is to
pick one, and have implementations converge on it. I'd personally
prefer text/cvs, just because it's shorter.

Regards,   Martin.

At 08:08 05/02/04, Yakov Shafranovich wrote:
 >Martin,
 >
 >The reason why I put in an additional 'text/comma-separated-values' type
 >is because there is an existing registration for
 >"text/tabbed-separated-values" and I thought that the CSV one should
 >correspond to the existing one. However, its too long for practical use
 >which is why I included "text/csv" as well. In practice I have seen both
 >being used.
 >
 >In truth, I don't know enough about the historical conventions for MIME
 >types to judge whether an existing registration for
 >"tabbed-separated-values" should mandate "comma-separated-values". I
 >assumed that there is a convention, but if in fact I am wrong, I will be
 >happy to adjust the draft to target one type.
 >
 >As for the encoding section, you have a valid point. I will adjust it
 >for the -01 draft including the ABNF grammar in the appendix.
 >
 >Yakov
 >
 >Martin Duerst wrote:
 >> Hello Yakov,
 >> Good work. Two comments:
 >> - I think registering just text/cvs should be enough.
 >>   One point of the registry is to reduce the number of values
 >>   used for the same thing to one. The registration can serve
 >>   to converge to that.
 >
 >> - I like the realism in the "Encoding considerations" section,
 >>   but shouldn't you at least mention LF also for line ends,
 >>   or just leave out specific values?
 >> Regards,    Martin.
 >>
 >> At 10:58 05/02/03, Yakov Shafranovich wrote:
 >>  >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
 >>  >
 >>
 >>
 >
 > 

From: duerst at w3.org (Martin Duerst)
Date: Tue Jan  3 16:22:55 2006
Subject: Media Types 'text/csv' and 'text/comma-separated-values'
In-Reply-To: <[email-masked]>
References: <[email-masked]> <6.0.0.20.2.20050203171705.04098430@localhost> <[email-masked]>
Message-ID: <6.0.0.20.2.20050204105514.05bcce48@localhost>

Hello Yakov,

As far as I know, there is no convention that would force either
text/comma-separated-values or text/cvs. My suggestion is to
pick one, and have implementations converge on it. I'd personally
prefer text/cvs, just because it's shorter.

Regards,   Martin.

At 08:08 05/02/04, Yakov Shafranovich wrote:
 >Martin,
 >
 >The reason why I put in an additional 'text/comma-separated-values' type
 >is because there is an existing registration for
 >"text/tabbed-separated-values" and I thought that the CSV one should
 >correspond to the existing one. However, its too long for practical use
 >which is why I included "text/csv" as well. In practice I have seen both
 >being used.
 >
 >In truth, I don't know enough about the historical conventions for MIME
 >types to judge whether an existing registration for
 >"tabbed-separated-values" should mandate "comma-separated-values". I
 >assumed that there is a convention, but if in fact I am wrong, I will be
 >happy to adjust the draft to target one type.
 >
 >As for the encoding section, you have a valid point. I will adjust it
 >for the -01 draft including the ABNF grammar in the appendix.
 >
 >Yakov
 >
 >Martin Duerst wrote:
 >> Hello Yakov,
 >> Good work. Two comments:
 >> - I think registering just text/cvs should be enough.
 >>   One point of the registry is to reduce the number of values
 >>   used for the same thing to one. The registration can serve
 >>   to converge to that.
 >
 >> - I like the realism in the "Encoding considerations" section,
 >>   but shouldn't you at least mention LF also for line ends,
 >>   or just leave out specific values?
 >> Regards,    Martin.
 >>
 >> At 10:58 05/02/03, Yakov Shafranovich wrote:
 >>  >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
 >>  >
 >>
 >>
 >
 > 

From: YakovS at solidmatrix.com (Yakov Shafranovich)
Date: Fri Feb  4 00:08:48 2005
Subject: Media Types 'text/csv' and 'text/comma-separated-values'
In-Reply-To: <6.0.0.20.2.20050203171705.04098430@localhost>
References: <[email-masked]> <6.0.0.20.2.20050203171705.04098430@localhost>
Message-ID: <[email-masked]>

Martin,

The reason why I put in an additional 'text/comma-separated-values' type
is because there is an existing registration for
"text/tabbed-separated-values" and I thought that the CSV one should
correspond to the existing one. However, its too long for practical use
which is why I included "text/csv" as well. In practice I have seen both
being used.

In truth, I don't know enough about the historical conventions for MIME
types to judge whether an existing registration for
"tabbed-separated-values" should mandate "comma-separated-values". I
assumed that there is a convention, but if in fact I am wrong, I will be
happy to adjust the draft to target one type.

As for the encoding section, you have a valid point. I will adjust it
for the -01 draft including the ABNF grammar in the appendix.

Yakov

Martin Duerst wrote:
> Hello Yakov,
> 
> Good work. Two comments:
> 
> - I think registering just text/cvs should be enough.
>   One point of the registry is to reduce the number of values
>   used for the same thing to one. The registration can serve
>   to converge to that.

> - I like the realism in the "Encoding considerations" section,
>   but shouldn't you at least mention LF also for line ends,
>   or just leave out specific values?
> 
> Regards,    Martin.
> 
> 
> At 10:58 05/02/03, Yakov Shafranovich wrote:
>  >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
>  >
> 
> 
> 

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'
In-Reply-To: <6.0.0.20.2.20050203171705.04098430@localhost>
References: <[email-masked]> <6.0.0.20.2.20050203171705.04098430@localhost>
Message-ID: <[email-masked]>

Martin,

The reason why I put in an additional 'text/comma-separated-values' type
is because there is an existing registration for
"text/tabbed-separated-values" and I thought that the CSV one should
correspond to the existing one. However, its too long for practical use
which is why I included "text/csv" as well. In practice I have seen both
being used.

In truth, I don't know enough about the historical conventions for MIME
types to judge whether an existing registration for
"tabbed-separated-values" should mandate "comma-separated-values". I
assumed that there is a convention, but if in fact I am wrong, I will be
happy to adjust the draft to target one type.

As for the encoding section, you have a valid point. I will adjust it
for the -01 draft including the ABNF grammar in the appendix.

Yakov

Martin Duerst wrote:
> Hello Yakov,
> 
> Good work. Two comments:
> 
> - I think registering just text/cvs should be enough.
>   One point of the registry is to reduce the number of values
>   used for the same thing to one. The registration can serve
>   to converge to that.

> - I like the realism in the "Encoding considerations" section,
>   but shouldn't you at least mention LF also for line ends,
>   or just leave out specific values?
> 
> Regards,    Martin.
> 
> 
> At 10:58 05/02/03, Yakov Shafranovich wrote:
>  >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
>  >
> 
> 
> 

From: duerst at w3.org (Martin Duerst)
Date: Tue Jan  3 16:22:55 2006
Subject: Media Types 'text/csv' and 'text/comma-separated-values'
In-Reply-To: <[email-masked]>
References: <[email-masked]>
Message-ID: <6.0.0.20.2.20050203171705.04098430@localhost>

Hello Yakov,

Good work. Two comments:

- I think registering just text/cvs should be enough.
   One point of the registry is to reduce the number of values
   used for the same thing to one. The registration can serve
   to converge to that.
- I like the realism in the "Encoding considerations" section,
   but shouldn't you at least mention LF also for line ends,
   or just leave out specific values?

Regards,    Martin.

At 10:58 05/02/03, Yakov Shafranovich wrote:
 >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
 > 

From: YakovS at solidmatrix.com (Yakov Shafranovich)
Date: Thu Feb  3 02:58:49 2005
Subject: Media Types 'text/csv' and 'text/comma-separated-values'
Message-ID: <[email-masked]>

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
>From [email-masked]  Thu Feb  3 09:19:50 2005
From: duerst at w3.org (Martin Duerst)
Date: Thu Feb  3 09:19:59 2005
Subject: Media Types 'text/csv' and 'text/comma-separated-values'
In-Reply-To: <[email-masked]>
References: <[email-masked]>
Message-ID: <6.0.0.20.2.20050203171705.04098430@localhost>

Hello Yakov,

Good work. Two comments:

- I think registering just text/cvs should be enough.
   One point of the registry is to reduce the number of values
   used for the same thing to one. The registration can serve
   to converge to that.
- I like the realism in the "Encoding considerations" section,
   but shouldn't you at least mention LF also for line ends,
   or just leave out specific values?

Regards,    Martin.

At 10:58 05/02/03, Yakov Shafranovich wrote:
 >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
 >