Subject: Testing the waters for text/troff
From: ned.freed at mrochek.com ([email-masked])
Date: Tue Jan 3 16:22:52 2006

> [I am not a Mac expert...]

I'm not either, but Mac OS X is the primary platform I work on, so I am at
least somewhat familiar with how this stuff works.

> At  4pm on 25/11/04 you (Bruce Lilly) wrote:
> >
> > In my search for "Macintosh File Type Code", I found one document
> > that mentions "File Type Codes", but that is specifically for Mac OS 9
> > and earlier, not for "Macintosh" in general (indeed, "Macintosh"
> > appears nowhere in that document (
> > http://docs.info.apple.com/article.html?artnum=55381
> > )).

> Yes. Mac OS X and Mac OS Classic (9 and earlier) are completely separate
> operating systems that happen to look similar. OSX is a perfectly normal
> BSDish system with a GUI derived from NeXTStep on top of it. AFAIK OSX
> doesn't use the Classic file type codes at all,

Actually, it does use them, although it also uses file name extensions. The
results can get to be a bit messy - I cited a web page in a previous post that
discusses this issue to some extent. Note that the messiness has more to do
with the fact that some applications pay attention to type codes while others
pay attention to file name extensions than it does to any confusion at the OS
level.

Creator codes are used much more extensively than type codes. However, this is
also true of Mac OS 9. Of course this is just common sense: A given file _type_
may be of interest to many applications, but a creator code binds a file to a
specific application. Specific information trumps general information.

> though what it does do
> by way of 'file associations' I'm not sure. I *certainly* hope it
> doesn't use file extensions...

Mac OS X understands file extensions and handles them specially, but AFAIK it
does not use them to associate an application with a file. That's still done
with type and creator codes. Of course this doesn't prevent specific
applications from doing this, and in fact that's exactly what happens. Mozilla
on Mac OS X, for example, has a table that maps either MIME types or file name
extensions to creator codes.

In case you care, here's a discussion of file name extension handling
in Mac OS X:

  http://cocoa.mamasam.com/COCOADEV/2001/09/1/11740.php

I will also point out that Mac OS X has various security features
surrounding double clicking on files that at least attempt to prevent
bad things from happening.

> > On Wed November 24 2004 15:40, Ben Morrow wrote:
> > >
> > > In your case, as *roff is unused on Apple systems, you could simply
> > > state that there is no Apple type code.
> >
> > I'm not so sure about that; I have seen literally dozens of references
> > to troff on Apple systems (all seem to refer to "Mac OS X"), so it's
> > certainly not true that "*roff is unused on Apple systems".  I recall
> > an Apple UNIX-based system called "Lisa" a few years back, and I
> > know of several versions of troff packages for a variety of platforms,
> > so I would not be at all surprised to find pre-OS-X troff on Apple
> > systems.

> This is all true; however, the Mac file type codes are only relevant to
> Mac OS Classic, which very rarely has *roff installed.

They aren't. See above.

> > Aside from this specific exercise, there are broader issues that should
> > be addressed in the media type registration form:
> > 1. If what is meant by "Macintosh File Type Code" is in fact
> >     "Mac OS 9 File Type Code" it would help if the registration
> >    template were revised to say so.  It's too late to help me for
> >    this case, but it might save others many hours of fruitless
> >    searching.

> This I would definitely agree with.

I don't because it is based on an incorrect conclusion.

> > 2. It would also help if there were a pointer to a definitive source
> >     of information for these OS-specific, platform-specific codes.
> > As the registration procedure and template seem to be undergoing
> > an update (draft-freed-media-type-reg-01.txt), that might be a good
> > opportunity to clarify such issues (or perhaps to elide that
> > idiosyncratic item altogether).

> No, that would be a bad idea, at least until Classic is firmly in the
> dustbin of history (I don't think it's quite there, yet).

It most certainly isn't, and isn't likely to be for a very long time. I know
plenty of people who still use OS 9 and I know of applications people depend on
that haven't been ported to OS X yet.

> Any sane
> system of file type identifications would use MIME types directly;

Agreed, but sadly that's not how things work in practice. And our security
is the worse for it.

				Ned

From: blilly at erols.com (Bruce Lilly)
Date: Tue Jan  3 16:22:52 2006
Subject: Testing the waters for text/troff
In-Reply-To: <[email-masked]>
References: <[email-masked]> <[email-masked]> <[email-masked]>
Message-ID: <[email-masked]>

On Fri November 26 2004 17:47, [email-masked] wrote:

> HTML files are a lot more uquitous than nroff files and they make do with the
> TEXT type.
[...]
> > > The fact of the matter is that file type codes are far less ideosyncratic in
> > > their behavior, specification, and handling than file name extensions are.
> 
> > They're idiosyncratic to the extent that they apply only to
> > one particular OS (several versions) on one particular
> > hardware platform, with obscure documentation not
> > amenable to search by non-Apple media type registrants.
> > File name "extensions" are another matter, and I have a
> > paragraph written about them.
> 
> File name extensions are in fact far more ideosyncratic. Not only does their
> meaning vary widely from one OS to the next,

Clearly Mac OS file type codes only apply to one OS, and are
meaningless for all other OSes. I.e. their meaning varies
from none to some from one OS to the next.

> they vary from version to version 
> and even from application to application. As a result there  are numerous
> conflicts and inconsistencies. Not only is it impossible to determine what
> extension to use for a given object in all cases,

It seems to be impossible to determine what Mac OS file type code
to use for a given object (e.g. the case in point).

> it is impossible to say what 
> a given extension means in all cases.

Given your statement regarding HTML and "TEXT", it sounds like
that's also the case for Mac OS file type codes; it appears that
sometimes "TEXT" means plain text and sometimes it means HTML.
 
> If similar issues exist for Mac file type codes I am unaware of them.

See above.
 
> There is not now and never has been any requirement that such information be
> provided as part of any registration.

Yes, I overstated the case. Sorry.

From: ned.freed at mrochek.com ([email-masked])
Date: Tue Jan  3 16:22:52 2006
Subject: Testing the waters for text/troff
In-Reply-To: "Your message dated Thu, 25 Nov 2004 21:53:52 -0500" <[email-masked]>
References: <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]>
Message-ID: <[email-masked]>

> On Thu November 25 2004 17:53, [email-masked] wrote:

> > Well, the very first Google search I did with the string you specified turned
> > up this as the initial reference:

> > http://developer.apple.com/datatype/

> > This includes a concise explanation of the codes, how they are used, how to
> > register them, how to find what ones are in use, and a FAQ.
> >
> > Seems to me you've made this many times harder than it needed to be.

> You must be seeing things that I can't see; the URL you provided
> is a page about "Creator Codes" for applications, not "File Codes"
> for data formats.  It not only doesn't say how to determine which
> codes are in use, it specifically says that Apple won't release that
> information, but will only tell if a specific code is in use (but won't
> say by whom or for what).

Yes, sorry, that's the page for creator codes. However, the many other
references that search turns up talk about file type codes in considerable
detail.

> > > 1. If what is meant by "Macintosh File Type Code" is in fact
> > >     "Mac OS 9 File Type Code" it would help if the registration
> > >    template were revised to say so.

> > File type codes are used in all versions of Mac OS, including Mac OS X. As
> > such, the revision you propose is totally inappropriate.

> The suggestion is to change "Macintosh" to "Mac OS", since
> that is apparently how the codes are referred to by Apple. Not
> surprising since it appears to be OS-related rather than
> hardware-related.

Fine, whatever. This is a difference that makes no difference IMO.

> > A simple question about the role of type and creator codes directed at anyone
> > even slightly familiar with Mac OS internals would have sufficed. Or a google
> > search, as I showed above.

> The role isn't the question; which specific code is used is
> the question (which is as yet unanswered).  And your
> Google search result was about an entirely different type
> of code.
 
Actually, the two are tightly interrelated and material discussing one usually
discussses the other.

The way this works is that the creator code attached to a file is used to
determine what application to fire up when you double-click on the file. The
type code is then used by the application to determine what sort of data is in
the file. Applications also make known the list of file types they can handle.
This comes into play when the creating application cannot be found - in this
case the OS then has the ability to list all of the applications that handle
material of this type.

Now, as far as this particular type goes, AFAIK there is no Mac OS GUI version
of nroff/troff. As I said before, Mac OS X does ship with groff, but only as a
command line utility. While I suppose it is possible that a command line
utility could look at file type codes, groff doesn't appear to have been
enhanced in this way. As such, it is very unlikely that a file type code has
been defined for this format, nor is there any real need to define such a code.
HTML files are a lot more uquitous than nroff files and they make do with the
TEXT type.

> > I'll consider adding a reference to Apple's data type registration page, but
> > whether or not it will survive the RFC Editor is anyone's guess.

> Thanks. I guess it would help if there were some assurance
> that the reference is stable (e.g. if the information appears
> in some printed documentation).

Well, given that the reference doesn't cover file type codes in any
detail it seems unreasonable to add it.

> > The fact of the matter is that file type codes are far less ideosyncratic in
> > their behavior, specification, and handling than file name extensions are.

> They're idiosyncratic to the extent that they apply only to
> one particular OS (several versions) on one particular
> hardware platform, with obscure documentation not
> amenable to search by non-Apple media type registrants.
> File name "extensions" are another matter, and I have a
> paragraph written about them.

File name extensions are in fact far more ideosyncratic. Not only does their
meaning vary widely from one OS to the next, they vary from version to version
and even from application to application. As a result there  are numerous
conflicts and inconsistencies. Not only is it impossible to determine what
extension to use for a given object in all cases, it is impossible to say what
a given extension means in all cases.

If similar issues exist for Mac file type codes I am unaware of them.

> > Removing the ability to specify them in a registration is therefore completely
> > inappropriate.

> Nobody is suggesting removing the ability to specify them,
> which is certainly possible via the "Any other information
> that the author deems interesting may be added" portion.
> Rather it is being suggested that the *requirement* for
> registrants to determine and specify such idiosyncratic
> information might be either facilitated (by providing information
> about how to find that information) or dropped (leaving it
> as optional information supplied by authors who deem it to be
> interesting).

There is not now and never has been any requirement that such information be
provided as part of any registration. The registration procedure is VERY clear
about this. It says:

  Various sorts of optional information SHOULD be included in the specification
  of a media type if it is available:

So, if you don't know the code, you leave it out. The point was, is, and
always has been that if you do know the code you should include it. Why
is this so hard to understand?

				Ned

From: blilly at erols.com (Bruce Lilly)
Date: Tue Jan  3 16:22:52 2006
Subject: Testing the waters for text/troff
In-Reply-To: <[email-masked]>
References: <[email-masked]> <[email-masked]> <[email-masked]>
Message-ID: <[email-masked]>

On Thu November 25 2004 17:53, [email-masked] wrote:

> Well, the very first Google search I did with the string you specified turned
> up this as the initial reference:
> 
> http://developer.apple.com/datatype/
> 
> This includes a concise explanation of the codes, how they are used, how to
> register them, how to find what ones are in use, and a FAQ.
> 
> Seems to me you've made this many times harder than it needed to be.

You must be seeing things that I can't see; the URL you provided
is a page about "Creator Codes" for applications, not "File Codes"
for data formats.  It not only doesn't say how to determine which
codes are in use, it specifically says that Apple won't release that
information, but will only tell if a specific code is in use (but won't
say by whom or for what).

> > 1. If what is meant by "Macintosh File Type Code" is in fact
> >     "Mac OS 9 File Type Code" it would help if the registration
> >    template were revised to say so.
> 
> File type codes are used in all versions of Mac OS, including Mac OS X. As
> such, the revision you propose is totally inappropriate.

The suggestion is to change "Macintosh" to "Mac OS", since
that is apparently how the codes are referred to by Apple. Not
surprising since it appears to be OS-related rather than
hardware-related.

> A simple question about the role of type and creator codes directed at anyone
> even slightly familiar with Mac OS internals would have sufficed. Or a google
> search, as I showed above.

The role isn't the question; which specific code is used is
the question (which is as yet unanswered).  And your
Google search result was about an entirely different type
of code.
 
> I'll consider adding a reference to Apple's data type registration page, but
> whether or not it will survive the RFC Editor is anyone's guess.

Thanks. I guess it would help if there were some assurance
that the reference is stable (e.g. if the information appears
in some printed documentation).

> The fact of the matter is that file type codes are far less ideosyncratic in
> their behavior, specification, and handling than file name extensions are.

They're idiosyncratic to the extent that they apply only to
one particular OS (several versions) on one particular
hardware platform, with obscure documentation not
amenable to search by non-Apple media type registrants.
File name "extensions" are another matter, and I have a
paragraph written about them.

> Removing the ability to specify them in a registration is therefore completely
> inappropriate.

Nobody is suggesting removing the ability to specify them,
which is certainly possible via the "Any other information
that the author deems interesting may be added" portion.
Rather it is being suggested that the *requirement* for
registrants to determine and specify such idiosyncratic
information might be either facilitated (by providing information
about how to find that information) or dropped (leaving it
as optional information supplied by authors who deem it to be
interesting).

From: ben at morrow.me.uk (Ben Morrow)
Date: Tue Jan  3 16:22:52 2006
Subject: Testing the waters for text/troff
In-Reply-To: <[email-masked]>
References: <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]>
Message-ID: <[email-masked]>

[I am not a Mac expert...]

At  4pm on 25/11/04 you (Bruce Lilly) wrote:
> 
> In my search for "Macintosh File Type Code", I found one document
> that mentions "File Type Codes", but that is specifically for Mac OS 9
> and earlier, not for "Macintosh" in general (indeed, "Macintosh"
> appears nowhere in that document (
> http://docs.info.apple.com/article.html?artnum=55381
> )).

Yes. Mac OS X and Mac OS Classic (9 and earlier) are completely separate
operating systems that happen to look similar. OSX is a perfectly normal
BSDish system with a GUI derived from NeXTStep on top of it. AFAIK OSX
doesn't use the Classic file type codes at all, though what it does do
by way of 'file associations' I'm not sure. I *certainly* hope it
doesn't use file extensions...

> On Wed November 24 2004 15:40, Ben Morrow wrote:
> >
> > In your case, as *roff is unused on Apple systems, you could simply
> > state that there is no Apple type code.
> 
> I'm not so sure about that; I have seen literally dozens of references
> to troff on Apple systems (all seem to refer to "Mac OS X"), so it's
> certainly not true that "*roff is unused on Apple systems".  I recall
> an Apple UNIX-based system called "Lisa" a few years back, and I
> know of several versions of troff packages for a variety of platforms,
> so I would not be at all surprised to find pre-OS-X troff on Apple
> systems.

This is all true; however, the Mac file type codes are only relevant to
Mac OS Classic, which very rarely has *roff installed.

> Aside from this specific exercise, there are broader issues that should
> be addressed in the media type registration form:
> 1. If what is meant by "Macintosh File Type Code" is in fact
>     "Mac OS 9 File Type Code" it would help if the registration
>    template were revised to say so.  It's too late to help me for
>    this case, but it might save others many hours of fruitless
>    searching.

This I would definitely agree with.

> 2. It would also help if there were a pointer to a definitive source
>     of information for these OS-specific, platform-specific codes.
> As the registration procedure and template seem to be undergoing
> an update (draft-freed-media-type-reg-01.txt), that might be a good
> opportunity to clarify such issues (or perhaps to elide that
> idiosyncratic item altogether).

No, that would be a bad idea, at least until Classic is firmly in the
dustbin of history (I don't think it's quite there, yet). Any sane
system of file type identifications would use MIME types directly;
however, the registry provides a mapping to legacy systems such as Mac
OS types and Win32 file extensions for situations such a browser saving
a downloaded file, and web servers giving an entity a type without other
explicit information.

Ben

-- 
And if you wanna make sense / Whatcha looking at me for?          (Fiona Apple)
                            * [email-masked] *

From: ned.freed at mrochek.com ([email-masked])
Date: Tue Jan  3 16:22:52 2006
Subject: Testing the waters for text/troff
In-Reply-To: "Your message dated Thu, 25 Nov 2004 16:13:05 -0500" <[email-masked]>
References: <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]>
Message-ID: <[email-masked]>

> On Wed November 24 2004 15:40, Ben Morrow wrote:
> > At  7pm on 23/11/04 you (Bruce Lilly) wrote:
> > > some of the obscure things asked for; for example, I have no idea
> > > what "Macintosh File Type Code(s)" is supposed to mean
> > > [searching for "Macintosh File Type Code" on the Apple web site
> > > yielded zero useful results].
> >
> > Apple calls them 'creator' and 'type' (IIRC) codes. Each file on an
> > Apple (HFS) filesystem is labelled with two four-octet codes, a
> > 'creator' which indicates which application to open with and a 'type'
> > which indicates which of the formats that application supports this file
> > is in. So, for example, a TIFF saved from Photoshop has creator '8BIM'
> > which, for reasons best known to Adobe and Apple, means Photoshop, and
> > type 'tiff'.

> In my search for "Macintosh File Type Code", I found one document
> that mentions "File Type Codes", but that is specifically for Mac OS 9
> and earlier, not for "Macintosh" in general (indeed, "Macintosh"
> appears nowhere in that document (
> http://docs.info.apple.com/article.html?artnum=55381
> )).

Well, the very first Google search I did with the string you specified turned
up this as the initial reference:

http://developer.apple.com/datatype/

This includes a concise explanation of the codes, how they are used, how to
register them, how to find what ones are in use, and a FAQ.

Seems to me you've made this many times harder than it needed to be.

> > In your case, as *roff is unused on Apple systems, you could simply
> > state that there is no Apple type code.

> I'm not so sure about that; I have seen literally dozens of references
> to troff on Apple systems (all seem to refer to "Mac OS X"), so it's
> certainly not true that "*roff is unused on Apple systems".  I recall
> an Apple UNIX-based system called "Lisa" a few years back, and I
> know of several versions of troff packages for a variety of platforms,
> so I would not be at all surprised to find pre-OS-X troff on Apple
> systems.

Mac OS X ships with groff, which provides both nroff and troff emulation. So
yes, it is used on Mac OS X. However, AFAIK there is no type code registered
for *roff documents.

> Aside from this specific exercise, there are broader issues that should
> be addressed in the media type registration form:

> 1. If what is meant by "Macintosh File Type Code" is in fact
>     "Mac OS 9 File Type Code" it would help if the registration
>    template were revised to say so.

File type codes are used in all versions of Mac OS, including Mac OS X. As
such, the revision you propose is totally inappropriate.

>    It's too late to help me for
>    this case, but it might save others many hours of fruitless
>    searching.

A simple question about the role of type and creator codes directed at anyone
even slightly familiar with Mac OS internals would have sufficed. Or a google
search, as I showed above.

> 2. It would also help if there were a pointer to a definitive source
>     of information for these OS-specific, platform-specific codes.

I'll consider adding a reference to Apple's data type registration page, but
whether or not it will survive the RFC Editor is anyone's guess.

> As the registration procedure and template seem to be undergoing
> an update (draft-freed-media-type-reg-01.txt), that might be a good
> opportunity to clarify such issues (or perhaps to elide that
> idiosyncratic item altogether).

The fact of the matter is that file type codes are far less ideosyncratic in
their behavior, specification, and handling than file name extensions are.
Removing the ability to specify them in a registration is therefore completely
inappropriate.

You're making a mountain out of a molehill here, Bruce.

				Ned

From: blilly at erols.com (Bruce Lilly)
Date: Tue Jan  3 16:22:52 2006
Subject: Testing the waters for text/troff
In-Reply-To: <[email-masked]>
References: <[email-masked]> <[email-masked]> <[email-masked]>
Message-ID: <[email-masked]>

On Wed November 24 2004 15:40, Ben Morrow wrote:
> At  7pm on 23/11/04 you (Bruce Lilly) wrote:
> > some of the obscure things asked for; for example, I have no idea
> > what "Macintosh File Type Code(s)" is supposed to mean
> > [searching for "Macintosh File Type Code" on the Apple web site
> > yielded zero useful results].
> 
> Apple calls them 'creator' and 'type' (IIRC) codes. Each file on an
> Apple (HFS) filesystem is labelled with two four-octet codes, a
> 'creator' which indicates which application to open with and a 'type'
> which indicates which of the formats that application supports this file
> is in. So, for example, a TIFF saved from Photoshop has creator '8BIM'
> which, for reasons best known to Adobe and Apple, means Photoshop, and
> type 'tiff'.

In my search for "Macintosh File Type Code", I found one document
that mentions "File Type Codes", but that is specifically for Mac OS 9
and earlier, not for "Macintosh" in general (indeed, "Macintosh"
appears nowhere in that document (
http://docs.info.apple.com/article.html?artnum=55381
)).

> In your case, as *roff is unused on Apple systems, you could simply
> state that there is no Apple type code.

I'm not so sure about that; I have seen literally dozens of references
to troff on Apple systems (all seem to refer to "Mac OS X"), so it's
certainly not true that "*roff is unused on Apple systems".  I recall
an Apple UNIX-based system called "Lisa" a few years back, and I
know of several versions of troff packages for a variety of platforms,
so I would not be at all surprised to find pre-OS-X troff on Apple
systems.

Aside from this specific exercise, there are broader issues that should
be addressed in the media type registration form:
1. If what is meant by "Macintosh File Type Code" is in fact
    "Mac OS 9 File Type Code" it would help if the registration
   template were revised to say so.  It's too late to help me for
   this case, but it might save others many hours of fruitless
   searching.
2. It would also help if there were a pointer to a definitive source
    of information for these OS-specific, platform-specific codes.
As the registration procedure and template seem to be undergoing
an update (draft-freed-media-type-reg-01.txt), that might be a good
opportunity to clarify such issues (or perhaps to elide that
idiosyncratic item altogether).

From: ben at morrow.me.uk (Ben Morrow)
Date: Tue Jan  3 16:22:52 2006
Subject: Testing the waters for text/troff
In-Reply-To: <[email-masked]>
References: <[email-masked]> <6.0.0.20.2.20041123084754.05f1b608@localhost> <[email-masked]>
Message-ID: <[email-masked]>

At  7pm on 23/11/04 you (Bruce Lilly) wrote:
> some of the obscure things asked for; for example, I have no idea
> what "Macintosh File Type Code(s)" is supposed to mean
> [searching for "Macintosh File Type Code" on the Apple web site
> yielded zero useful results].

Apple calls them 'creator' and 'type' (IIRC) codes. Each file on an
Apple (HFS) filesystem is labelled with two four-octet codes, a
'creator' which indicates which application to open with and a 'type'
which indicates which of the formats that application supports this file
is in. So, for example, a TIFF saved from Photoshop has creator '8BIM'
which, for reasons best known to Adobe and Apple, means Photoshop, and
type 'tiff'.

In your case, as *roff is unused on Apple systems, you could simply
state that there is no Apple type code.

Ben

-- 
And if you wanna make sense / Whatcha looking at me for?          (Fiona Apple)
                            * [email-masked] *

From: derhoermi at gmx.net (Bjoern Hoehrmann)
Date: Wed Nov 24 18:29:07 2004
Subject: MIME Type Review Request: image/svg+xml
In-Reply-To: <[email-masked]>
References: <[email-masked]> <6.0.0.20.2.20041119083958.085ea200@localhost> <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]>
Message-ID: <[email-masked]>

* Chris Lilley wrote:
>BH> Consider a *UTF-8 encoded* document
>BH>
>BH>   Content-Type: application/xml;charset=iso-8859-1
>BH>
>BH>   <?xml version="1.0"?>
>BH>   ...
>BH>   <!--Bj?rn-->
>BH>   ...
>BH>
>BH> With no BOM and using only US-ASCII characters for the rest of the
>BH> document,

>So in this case, although the processor that generated it is non
>conforming, the content is not non conforming (but it should be) and the
>processor that receives it has two possibilities:

I've actually asked to get a better understanding on how you intend to
change RFC3023, yet I am afraid you did not really say what happens with
the document above if RFC3023bis gets approved with your changes. I
would appreciate to know just a, b, c, or what else for the various
cases.

>b) it can note that a required encoding declaration is not present, and
>throw a well formedness error.

It actually can't, 0xC3 0xB6 is a legal sequence in both UTF-8 and
ISO-8859-1, it would need to know that I meant to have "Bj?rn" in the
comment which it cannot know.

>Consider an *8859-1 encoded* document
>
>  Content-Type: application/xml;charset=UTF-8
>
>  <?xml version="1.0"?>
>  ...
>  <!--Bj?rn-->
>  ...
>
>With your proposal, would the well formedness error (bytes occur that
>cannot occur in UTF-8) be silently recovered from if the HTTP
>header overrides it, even for an XML processor, while it would continue
>to fail in other cases (such as server side processing)?

I do not really think I've made a proposal to change RFC3023 other than
that the differences between text/xml and application/xml are removed to
properly reflect running code. I can only tell you what XML 1.0 and RFC
3023 require in these cases but you know that already.

>It would sometimes be b) and sometimes c) depending on the particular
>software and whether its reading from disk on the server or over the
>net. I frankly can't understand how you consider this lack of
>interoperability to be a desirable thing.

I am in fact most interested to learn how you think this can be improved
upon which is why I asked you about the impact of your proposal for the
various cases I've mentioned. What applications currently do does not
really help me to get a better understanding of that.
>From [email-masked]  Wed Nov 24 21:40:33 2004
From: ben at morrow.me.uk (Ben Morrow)
Date: Thu Nov 25 19:30:21 2004
Subject: Testing the waters for text/troff
In-Reply-To: <[email-masked]>
References: <[email-masked]>
	<6.0.0.20.2.20041123084754.05f1b608@localhost>
	<[email-masked]>
Message-ID: <[email-masked]>

At  7pm on 23/11/04 you (Bruce Lilly) wrote:
> some of the obscure things asked for; for example, I have no idea
> what "Macintosh File Type Code(s)" is supposed to mean
> [searching for "Macintosh File Type Code" on the Apple web site
> yielded zero useful results].

Apple calls them 'creator' and 'type' (IIRC) codes. Each file on an
Apple (HFS) filesystem is labelled with two four-octet codes, a
'creator' which indicates which application to open with and a 'type'
which indicates which of the formats that application supports this file
is in. So, for example, a TIFF saved from Photoshop has creator '8BIM'
which, for reasons best known to Adobe and Apple, means Photoshop, and
type 'tiff'.

In your case, as *roff is unused on Apple systems, you could simply
state that there is no Apple type code.

Ben

-- 
And if you wanna make sense / Whatcha looking at me for?          (Fiona Apple)
                            * [email-masked] *
>From [email-masked]  Thu Nov 25 22:13:05 2004
From: blilly at erols.com (Bruce Lilly)
Date: Thu Nov 25 22:13:17 2004
Subject: Testing the waters for text/troff
In-Reply-To: <[email-masked]>
References: <[email-masked]>
	<[email-masked]>
	<[email-masked]>
Message-ID: <[email-masked]>

On Wed November 24 2004 15:40, Ben Morrow wrote:
> At  7pm on 23/11/04 you (Bruce Lilly) wrote:
> > some of the obscure things asked for; for example, I have no idea
> > what "Macintosh File Type Code(s)" is supposed to mean
> > [searching for "Macintosh File Type Code" on the Apple web site
> > yielded zero useful results].
> 
> Apple calls them 'creator' and 'type' (IIRC) codes. Each file on an
> Apple (HFS) filesystem is labelled with two four-octet codes, a
> 'creator' which indicates which application to open with and a 'type'
> which indicates which of the formats that application supports this file
> is in. So, for example, a TIFF saved from Photoshop has creator '8BIM'
> which, for reasons best known to Adobe and Apple, means Photoshop, and
> type 'tiff'.

In my search for "Macintosh File Type Code", I found one document
that mentions "File Type Codes", but that is specifically for Mac OS 9
and earlier, not for "Macintosh" in general (indeed, "Macintosh"
appears nowhere in that document (
http://docs.info.apple.com/article.html?artnum=55381
)).

> In your case, as *roff is unused on Apple systems, you could simply
> state that there is no Apple type code.

I'm not so sure about that; I have seen literally dozens of references
to troff on Apple systems (all seem to refer to "Mac OS X"), so it's
certainly not true that "*roff is unused on Apple systems".  I recall
an Apple UNIX-based system called "Lisa" a few years back, and I
know of several versions of troff packages for a variety of platforms,
so I would not be at all surprised to find pre-OS-X troff on Apple
systems.

Aside from this specific exercise, there are broader issues that should
be addressed in the media type registration form:
1. If what is meant by "Macintosh File Type Code" is in fact
    "Mac OS 9 File Type Code" it would help if the registration
   template were revised to say so.  It's too late to help me for
   this case, but it might save others many hours of fruitless
   searching.
2. It would also help if there were a pointer to a definitive source
    of information for these OS-specific, platform-specific codes.
As the registration procedure and template seem to be undergoing
an update (draft-freed-media-type-reg-01.txt), that might be a good
opportunity to clarify such issues (or perhaps to elide that
idiosyncratic item altogether).
>From [email-masked]  Thu Nov 25 23:53:40 2004
From: ned.freed at mrochek.com ([email-masked])
Date: Fri Nov 26 00:07:17 2004
Subject: Testing the waters for text/troff
In-Reply-To: "Your message dated Thu, 25 Nov 2004 16:13:05 -0500"
	<[email-masked]>
References: <[email-masked]>
	<[email-masked]>
	<[email-masked]>
	<[email-masked]>
Message-ID: <[email-masked]>

> On Wed November 24 2004 15:40, Ben Morrow wrote:
> > At  7pm on 23/11/04 you (Bruce Lilly) wrote:
> > > some of the obscure things asked for; for example, I have no idea
> > > what "Macintosh File Type Code(s)" is supposed to mean
> > > [searching for "Macintosh File Type Code" on the Apple web site
> > > yielded zero useful results].
> >
> > Apple calls them 'creator' and 'type' (IIRC) codes. Each file on an
> > Apple (HFS) filesystem is labelled with two four-octet codes, a
> > 'creator' which indicates which application to open with and a 'type'
> > which indicates which of the formats that application supports this file
> > is in. So, for example, a TIFF saved from Photoshop has creator '8BIM'
> > which, for reasons best known to Adobe and Apple, means Photoshop, and
> > type 'tiff'.

> In my search for "Macintosh File Type Code", I found one document
> that mentions "File Type Codes", but that is specifically for Mac OS 9
> and earlier, not for "Macintosh" in general (indeed, "Macintosh"
> appears nowhere in that document (
> http://docs.info.apple.com/article.html?artnum=55381
> )).

Well, the very first Google search I did with the string you specified turned
up this as the initial reference:

http://developer.apple.com/datatype/

This includes a concise explanation of the codes, how they are used, how to
register them, how to find what ones are in use, and a FAQ.

Seems to me you've made this many times harder than it needed to be.

> > In your case, as *roff is unused on Apple systems, you could simply
> > state that there is no Apple type code.

> I'm not so sure about that; I have seen literally dozens of references
> to troff on Apple systems (all seem to refer to "Mac OS X"), so it's
> certainly not true that "*roff is unused on Apple systems".  I recall
> an Apple UNIX-based system called "Lisa" a few years back, and I
> know of several versions of troff packages for a variety of platforms,
> so I would not be at all surprised to find pre-OS-X troff on Apple
> systems.

Mac OS X ships with groff, which provides both nroff and troff emulation. So
yes, it is used on Mac OS X. However, AFAIK there is no type code registered
for *roff documents.

> Aside from this specific exercise, there are broader issues that should
> be addressed in the media type registration form:

> 1. If what is meant by "Macintosh File Type Code" is in fact
>     "Mac OS 9 File Type Code" it would help if the registration
>    template were revised to say so.

File type codes are used in all versions of Mac OS, including Mac OS X. As
such, the revision you propose is totally inappropriate.

>    It's too late to help me for
>    this case, but it might save others many hours of fruitless
>    searching.

A simple question about the role of type and creator codes directed at anyone
even slightly familiar with Mac OS internals would have sufficed. Or a google
search, as I showed above.

> 2. It would also help if there were a pointer to a definitive source
>     of information for these OS-specific, platform-specific codes.

I'll consider adding a reference to Apple's data type registration page, but
whether or not it will survive the RFC Editor is anyone's guess.

> As the registration procedure and template seem to be undergoing
> an update (draft-freed-media-type-reg-01.txt), that might be a good
> opportunity to clarify such issues (or perhaps to elide that
> idiosyncratic item altogether).

The fact of the matter is that file type codes are far less ideosyncratic in
their behavior, specification, and handling than file name extensions are.
Removing the ability to specify them in a registration is therefore completely
inappropriate.

You're making a mountain out of a molehill here, Bruce.

				Ned
>From [email-masked]  Fri Nov 26 03:53:52 2004
From: blilly at erols.com (Bruce Lilly)
Date: Fri Nov 26 03:54:01 2004
Subject: Testing the waters for text/troff
In-Reply-To: <[email-masked]>
References: <[email-masked]>
	<[email-masked]>
	<[email-masked]>
Message-ID: <[email-masked]>

On Thu November 25 2004 17:53, [email-masked] wrote:

> Well, the very first Google search I did with the string you specified turned
> up this as the initial reference:
> 
> http://developer.apple.com/datatype/
> 
> This includes a concise explanation of the codes, how they are used, how to
> register them, how to find what ones are in use, and a FAQ.
> 
> Seems to me you've made this many times harder than it needed to be.

You must be seeing things that I can't see; the URL you provided
is a page about "Creator Codes" for applications, not "File Codes"
for data formats.  It not only doesn't say how to determine which
codes are in use, it specifically says that Apple won't release that
information, but will only tell if a specific code is in use (but won't
say by whom or for what).

> > 1. If what is meant by "Macintosh File Type Code" is in fact
> >     "Mac OS 9 File Type Code" it would help if the registration
> >    template were revised to say so.
> 
> File type codes are used in all versions of Mac OS, including Mac OS X. As
> such, the revision you propose is totally inappropriate.

The suggestion is to change "Macintosh" to "Mac OS", since
that is apparently how the codes are referred to by Apple. Not
surprising since it appears to be OS-related rather than
hardware-related.

> A simple question about the role of type and creator codes directed at anyone
> even slightly familiar with Mac OS internals would have sufficed. Or a google
> search, as I showed above.

The role isn't the question; which specific code is used is
the question (which is as yet unanswered).  And your
Google search result was about an entirely different type
of code.
 
> I'll consider adding a reference to Apple's data type registration page, but
> whether or not it will survive the RFC Editor is anyone's guess.

Thanks. I guess it would help if there were some assurance
that the reference is stable (e.g. if the information appears
in some printed documentation).

> The fact of the matter is that file type codes are far less ideosyncratic in
> their behavior, specification, and handling than file name extensions are.

They're idiosyncratic to the extent that they apply only to
one particular OS (several versions) on one particular
hardware platform, with obscure documentation not
amenable to search by non-Apple media type registrants.
File name "extensions" are another matter, and I have a
paragraph written about them.

> Removing the ability to specify them in a registration is therefore completely
> inappropriate.

Nobody is suggesting removing the ability to specify them,
which is certainly possible via the "Any other information
that the author deems interesting may be added" portion.
Rather it is being suggested that the *requirement* for
registrants to determine and specify such idiosyncratic
information might be either facilitated (by providing information
about how to find that information) or dropped (leaving it
as optional information supplied by authors who deem it to be
interesting).
>From [email-masked]  Fri Nov 26 23:47:19 2004
From: ned.freed at mrochek.com ([email-masked])
Date: Sat Nov 27 00:11:14 2004
Subject: Testing the waters for text/troff
In-Reply-To: "Your message dated Thu, 25 Nov 2004 21:53:52 -0500"
	<[email-masked]>
References: <[email-masked]>
	<[email-masked]>
	<[email-masked]>
	<[email-masked]>
Message-ID: <[email-masked]>

> On Thu November 25 2004 17:53, [email-masked] wrote:

> > Well, the very first Google search I did with the string you specified turned
> > up this as the initial reference:

> > http://developer.apple.com/datatype/

> > This includes a concise explanation of the codes, how they are used, how to
> > register them, how to find what ones are in use, and a FAQ.
> >
> > Seems to me you've made this many times harder than it needed to be.

> You must be seeing things that I can't see; the URL you provided
> is a page about "Creator Codes" for applications, not "File Codes"
> for data formats.  It not only doesn't say how to determine which
> codes are in use, it specifically says that Apple won't release that
> information, but will only tell if a specific code is in use (but won't
> say by whom or for what).

Yes, sorry, that's the page for creator codes. However, the many other
references that search turns up talk about file type codes in considerable
detail.

> > > 1. If what is meant by "Macintosh File Type Code" is in fact
> > >     "Mac OS 9 File Type Code" it would help if the registration
> > >    template were revised to say so.

> > File type codes are used in all versions of Mac OS, including Mac OS X. As
> > such, the revision you propose is totally inappropriate.

> The suggestion is to change "Macintosh" to "Mac OS", since
> that is apparently how the codes are referred to by Apple. Not
> surprising since it appears to be OS-related rather than
> hardware-related.

Fine, whatever. This is a difference that makes no difference IMO.

> > A simple question about the role of type and creator codes directed at anyone
> > even slightly familiar with Mac OS internals would have sufficed. Or a google
> > search, as I showed above.

> The role isn't the question; which specific code is used is
> the question (which is as yet unanswered).  And your
> Google search result was about an entirely different type
> of code.
 
Actually, the two are tightly interrelated and material discussing one usually
discussses the other.

The way this works is that the creator code attached to a file is used to
determine what application to fire up when you double-click on the file. The
type code is then used by the application to determine what sort of data is in
the file. Applications also make known the list of file types they can handle.
This comes into play when the creating application cannot be found - in this
case the OS then has the ability to list all of the applications that handle
material of this type.

Now, as far as this particular type goes, AFAIK there is no Mac OS GUI version
of nroff/troff. As I said before, Mac OS X does ship with groff, but only as a
command line utility. While I suppose it is possible that a command line
utility could look at file type codes, groff doesn't appear to have been
enhanced in this way. As such, it is very unlikely that a file type code has
been defined for this format, nor is there any real need to define such a code.
HTML files are a lot more uquitous than nroff files and they make do with the
TEXT type.

> > I'll consider adding a reference to Apple's data type registration page, but
> > whether or not it will survive the RFC Editor is anyone's guess.

> Thanks. I guess it would help if there were some assurance
> that the reference is stable (e.g. if the information appears
> in some printed documentation).

Well, given that the reference doesn't cover file type codes in any
detail it seems unreasonable to add it.

> > The fact of the matter is that file type codes are far less ideosyncratic in
> > their behavior, specification, and handling than file name extensions are.

> They're idiosyncratic to the extent that they apply only to
> one particular OS (several versions) on one particular
> hardware platform, with obscure documentation not
> amenable to search by non-Apple media type registrants.
> File name "extensions" are another matter, and I have a
> paragraph written about them.

File name extensions are in fact far more ideosyncratic. Not only does their
meaning vary widely from one OS to the next, they vary from version to version
and even from application to application. As a result there  are numerous
conflicts and inconsistencies. Not only is it impossible to determine what
extension to use for a given object in all cases, it is impossible to say what
a given extension means in all cases.

If similar issues exist for Mac file type codes I am unaware of them.

> > Removing the ability to specify them in a registration is therefore completely
> > inappropriate.

> Nobody is suggesting removing the ability to specify them,
> which is certainly possible via the "Any other information
> that the author deems interesting may be added" portion.
> Rather it is being suggested that the *requirement* for
> registrants to determine and specify such idiosyncratic
> information might be either facilitated (by providing information
> about how to find that information) or dropped (leaving it
> as optional information supplied by authors who deem it to be
> interesting).

There is not now and never has been any requirement that such information be
provided as part of any registration. The registration procedure is VERY clear
about this. It says:

  Various sorts of optional information SHOULD be included in the specification
  of a media type if it is available:

So, if you don't know the code, you leave it out. The point was, is, and
always has been that if you do know the code you should include it. Why
is this so hard to understand?

				Ned
>From [email-masked]  Sat Nov 27 05:20:01 2004
From: blilly at erols.com (Bruce Lilly)
Date: Sat Nov 27 05:20:14 2004
Subject: Testing the waters for text/troff
In-Reply-To: <[email-masked]>
References: <[email-masked]>
	<[email-masked]>
	<[email-masked]>
Message-ID: <[email-masked]>

On Fri November 26 2004 17:47, [email-masked] wrote:

> HTML files are a lot more uquitous than nroff files and they make do with the
> TEXT type.
[...]
> > > The fact of the matter is that file type codes are far less ideosyncratic in
> > > their behavior, specification, and handling than file name extensions are.
> 
> > They're idiosyncratic to the extent that they apply only to
> > one particular OS (several versions) on one particular
> > hardware platform, with obscure documentation not
> > amenable to search by non-Apple media type registrants.
> > File name "extensions" are another matter, and I have a
> > paragraph written about them.
> 
> File name extensions are in fact far more ideosyncratic. Not only does their
> meaning vary widely from one OS to the next,

Clearly Mac OS file type codes only apply to one OS, and are
meaningless for all other OSes. I.e. their meaning varies
from none to some from one OS to the next.

> they vary from version to version 
> and even from application to application. As a result there  are numerous
> conflicts and inconsistencies. Not only is it impossible to determine what
> extension to use for a given object in all cases,

It seems to be impossible to determine what Mac OS file type code
to use for a given object (e.g. the case in point).

> it is impossible to say what 
> a given extension means in all cases.

Given your statement regarding HTML and "TEXT", it sounds like
that's also the case for Mac OS file type codes; it appears that
sometimes "TEXT" means plain text and sometimes it means HTML.
 
> If similar issues exist for Mac file type codes I am unaware of them.

See above.
 
> There is not now and never has been any requirement that such information be
> provided as part of any registration.

Yes, I overstated the case. Sorry.
>From [email-masked]  Fri Nov 26 00:20:05 2004
From: ben at morrow.me.uk (Ben Morrow)
Date: Sat Nov 27 16:46:29 2004
Subject: Testing the waters for text/troff
In-Reply-To: <[email-masked]>
References: <[email-masked]>
	<[email-masked]>
	<[email-masked]>
	<[email-masked]>
Message-ID: <[email-masked]>

[I am not a Mac expert...]

At  4pm on 25/11/04 you (Bruce Lilly) wrote:
> 
> In my search for "Macintosh File Type Code", I found one document
> that mentions "File Type Codes", but that is specifically for Mac OS 9
> and earlier, not for "Macintosh" in general (indeed, "Macintosh"
> appears nowhere in that document (
> http://docs.info.apple.com/article.html?artnum=55381
> )).

Yes. Mac OS X and Mac OS Classic (9 and earlier) are completely separate
operating systems that happen to look similar. OSX is a perfectly normal
BSDish system with a GUI derived from NeXTStep on top of it. AFAIK OSX
doesn't use the Classic file type codes at all, though what it does do
by way of 'file associations' I'm not sure. I *certainly* hope it
doesn't use file extensions...

> On Wed November 24 2004 15:40, Ben Morrow wrote:
> >
> > In your case, as *roff is unused on Apple systems, you could simply
> > state that there is no Apple type code.
> 
> I'm not so sure about that; I have seen literally dozens of references
> to troff on Apple systems (all seem to refer to "Mac OS X"), so it's
> certainly not true that "*roff is unused on Apple systems".  I recall
> an Apple UNIX-based system called "Lisa" a few years back, and I
> know of several versions of troff packages for a variety of platforms,
> so I would not be at all surprised to find pre-OS-X troff on Apple
> systems.

This is all true; however, the Mac file type codes are only relevant to
Mac OS Classic, which very rarely has *roff installed.

> Aside from this specific exercise, there are broader issues that should
> be addressed in the media type registration form:
> 1. If what is meant by "Macintosh File Type Code" is in fact
>     "Mac OS 9 File Type Code" it would help if the registration
>    template were revised to say so.  It's too late to help me for
>    this case, but it might save others many hours of fruitless
>    searching.

This I would definitely agree with.

> 2. It would also help if there were a pointer to a definitive source
>     of information for these OS-specific, platform-specific codes.
> As the registration procedure and template seem to be undergoing
> an update (draft-freed-media-type-reg-01.txt), that might be a good
> opportunity to clarify such issues (or perhaps to elide that
> idiosyncratic item altogether).

No, that would be a bad idea, at least until Classic is firmly in the
dustbin of history (I don't think it's quite there, yet). Any sane
system of file type identifications would use MIME types directly;
however, the registry provides a mapping to legacy systems such as Mac
OS types and Win32 file extensions for situations such a browser saving
a downloaded file, and web servers giving an entity a type without other
explicit information.

Ben

-- 
And if you wanna make sense / Whatcha looking at me for?          (Fiona Apple)
                            * [email-masked] *
>From [email-masked]  Sat Nov 27 16:57:42 2004
From: ned.freed at mrochek.com ([email-masked])
Date: Sat Nov 27 17:37:41 2004
Subject: Testing the waters for text/troff
In-Reply-To: "Your message dated Thu, 25 Nov 2004 23:20:05 +0000"
	<[email-masked]>
References: <[email-masked]>
	<[email-masked]>
	<[email-masked]>
	<[email-masked]>
	<[email-masked]>
Message-ID: <[email-masked]>

> [I am not a Mac expert...]

I'm not either, but Mac OS X is the primary platform I work on, so I am at
least somewhat familiar with how this stuff works.

> At  4pm on 25/11/04 you (Bruce Lilly) wrote:
> >
> > In my search for "Macintosh File Type Code", I found one document
> > that mentions "File Type Codes", but that is specifically for Mac OS 9
> > and earlier, not for "Macintosh" in general (indeed, "Macintosh"
> > appears nowhere in that document (
> > http://docs.info.apple.com/article.html?artnum=55381
> > )).

> Yes. Mac OS X and Mac OS Classic (9 and earlier) are completely separate
> operating systems that happen to look similar. OSX is a perfectly normal
> BSDish system with a GUI derived from NeXTStep on top of it. AFAIK OSX
> doesn't use the Classic file type codes at all,

Actually, it does use them, although it also uses file name extensions. The
results can get to be a bit messy - I cited a web page in a previous post that
discusses this issue to some extent. Note that the messiness has more to do
with the fact that some applications pay attention to type codes while others
pay attention to file name extensions than it does to any confusion at the OS
level.

Creator codes are used much more extensively than type codes. However, this is
also true of Mac OS 9. Of course this is just common sense: A given file _type_
may be of interest to many applications, but a creator code binds a file to a
specific application. Specific information trumps general information.

> though what it does do
> by way of 'file associations' I'm not sure. I *certainly* hope it
> doesn't use file extensions...

Mac OS X understands file extensions and handles them specially, but AFAIK it
does not use them to associate an application with a file. That's still done
with type and creator codes. Of course this doesn't prevent specific
applications from doing this, and in fact that's exactly what happens. Mozilla
on Mac OS X, for example, has a table that maps either MIME types or file name
extensions to creator codes.

In case you care, here's a discussion of file name extension handling
in Mac OS X:

  http://cocoa.mamasam.com/COCOADEV/2001/09/1/11740.php

I will also point out that Mac OS X has various security features
surrounding double clicking on files that at least attempt to prevent
bad things from happening.

> > On Wed November 24 2004 15:40, Ben Morrow wrote:
> > >
> > > In your case, as *roff is unused on Apple systems, you could simply
> > > state that there is no Apple type code.
> >
> > I'm not so sure about that; I have seen literally dozens of references
> > to troff on Apple systems (all seem to refer to "Mac OS X"), so it's
> > certainly not true that "*roff is unused on Apple systems".  I recall
> > an Apple UNIX-based system called "Lisa" a few years back, and I
> > know of several versions of troff packages for a variety of platforms,
> > so I would not be at all surprised to find pre-OS-X troff on Apple
> > systems.

> This is all true; however, the Mac file type codes are only relevant to
> Mac OS Classic, which very rarely has *roff installed.

They aren't. See above.

> > Aside from this specific exercise, there are broader issues that should
> > be addressed in the media type registration form:
> > 1. If what is meant by "Macintosh File Type Code" is in fact
> >     "Mac OS 9 File Type Code" it would help if the registration
> >    template were revised to say so.  It's too late to help me for
> >    this case, but it might save others many hours of fruitless
> >    searching.

> This I would definitely agree with.

I don't because it is based on an incorrect conclusion.

> > 2. It would also help if there were a pointer to a definitive source
> >     of information for these OS-specific, platform-specific codes.
> > As the registration procedure and template seem to be undergoing
> > an update (draft-freed-media-type-reg-01.txt), that might be a good
> > opportunity to clarify such issues (or perhaps to elide that
> > idiosyncratic item altogether).

> No, that would be a bad idea, at least until Classic is firmly in the
> dustbin of history (I don't think it's quite there, yet).

It most certainly isn't, and isn't likely to be for a very long time. I know
plenty of people who still use OS 9 and I know of applications people depend on
that haven't been ported to OS X yet.

> Any sane
> system of file type identifications would use MIME types directly;

Agreed, but sadly that's not how things work in practice. And our security
is the worse for it.

				Ned
>From [email-masked]  Thu Nov 18 10:10:05 2004
From: eburger at brooktrout.com (Eric Burger)
Date: Thu Jan 20 19:32:53 2005
Subject: MIME Type Review for KPML MIME Types
Message-ID: <[email-masked]>

KPML is in the process of WGLC in the SIPPING work group.

KPML defines two new MIME types, application/kpml-request+xml and
application/kpml-response+xml .

We would greatly appreciate expert review of the definition and usage of
these new types.

The draft lives at:
http://www.ietf.org/internet-drafts/draft-ietf-sipping-kpml-06.txt

Thanks.

--
Eric Burger
>From [email-masked]  Mon Nov  1 02:49:32 2004
From: derhoermi at gmx.net (Bjoern Hoehrmann)
Date: Tue Jan  3 16:22:51 2006
Subject: SVG12: charset parameter for image/svg+xml
Message-ID: <[email-masked]>

Dear Scalable Vector Graphics Working Group,

  http://www.w3.org/TR/2004/WD-SVG12-20041027/mimereg.html attempts to
register the "image/svg+xml" MIME Type but the registration lacks the
charset parameter as defined in RFC 3023. This defeats the purpose of
the +xml convention which attempts to provide a means for generic XML
processing.

Generic XML tools such as Validators, Editors, XSLT and XQuery
processors, and full-text XML search engines would need to maintain
special knowledge to ignore the charset parameter for image/svg+xml
documents which is expensive and unlikely to happen. In fact, a number
of deployed tools already don't do that, for example the W3C Markup
Validator would need to be updated with special code for image/svg+xml
in order to comply with the registration.

Thus, please change the registration to be consistent with application/
xml as defined in RFC 3023.

regards.

From: derhoermi at gmx.net (Bjoern Hoehrmann)
Date: Tue Jan  3 16:22:52 2006
Subject: MIME Type Review Request: image/svg+xml
In-Reply-To: <[email-masked]>
References: <[email-masked]> <6.0.0.20.2.20041119083958.085ea200@localhost> <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]>
Message-ID: <[email-masked]>

* Chris Lilley wrote:
>BH> Consider a *UTF-8 encoded* document
>BH>
>BH>   Content-Type: application/xml;charset=iso-8859-1
>BH>
>BH>   <?xml version="1.0"?>
>BH>   ...
>BH>   <!--Bj?rn-->
>BH>   ...
>BH>
>BH> With no BOM and using only US-ASCII characters for the rest of the
>BH> document,

>So in this case, although the processor that generated it is non
>conforming, the content is not non conforming (but it should be) and the
>processor that receives it has two possibilities:

I've actually asked to get a better understanding on how you intend to
change RFC3023, yet I am afraid you did not really say what happens with
the document above if RFC3023bis gets approved with your changes. I
would appreciate to know just a, b, c, or what else for the various
cases.

>b) it can note that a required encoding declaration is not present, and
>throw a well formedness error.

It actually can't, 0xC3 0xB6 is a legal sequence in both UTF-8 and
ISO-8859-1, it would need to know that I meant to have "Bj?rn" in the
comment which it cannot know.

>Consider an *8859-1 encoded* document
>
>  Content-Type: application/xml;charset=UTF-8
>
>  <?xml version="1.0"?>
>  ...
>  <!--Bj?rn-->
>  ...
>
>With your proposal, would the well formedness error (bytes occur that
>cannot occur in UTF-8) be silently recovered from if the HTTP
>header overrides it, even for an XML processor, while it would continue
>to fail in other cases (such as server side processing)?

I do not really think I've made a proposal to change RFC3023 other than
that the differences between text/xml and application/xml are removed to
properly reflect running code. I can only tell you what XML 1.0 and RFC
3023 require in these cases but you know that already.

>It would sometimes be b) and sometimes c) depending on the particular
>software and whether its reading from disk on the server or over the
>net. I frankly can't understand how you consider this lack of
>interoperability to be a desirable thing.

I am in fact most interested to learn how you think this can be improved
upon which is why I asked you about the impact of your proposal for the
various cases I've mentioned. What applications currently do does not
really help me to get a better understanding of that.

From: chris at w3.org (Chris Lilley)
Date: Tue Jan  3 16:22:52 2006
Subject: MIME Type Review Request: image/svg+xml
In-Reply-To: <[email-masked]>
References: <[email-masked]> <6.0.0.20.2.20041119083958.085ea200@localhost> <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]>
Message-ID: <[email-masked]>

On Wednesday, November 24, 2004, 4:41:48 PM, Bjoern wrote:

BH> * Chris Lilley wrote:
>>As you yourself pointed out, per RFC3023
>>
>>   Processors generating XML MIME entities MUST NOT label conflicting
>>   charset information between the MIME Content-Type and the XML
>>   declaration.
>>
>>such content is already non conforming.

BH> It does not actually apply to content...

Yes, that is an ambiguity that needs to be cleared up. It says things
that generate the content must not do that; if that were true, then
there would be no such content. Since there is, its worth splitting this
into two:

- Conformance for XML generators
- Conformance for XML messages (headers plus bodies)

>>In terms of dealing with such content if it still occurs, the XML well
>>formedness rules already handle that in an entirely satisfactory manner
>>and nothing further need be added. These are already well implemented
>>and highly interoperable.

BH> Consider a *UTF-8 encoded* document

BH>   Content-Type: application/xml;charset=iso-8859-1

Since that isn't image/svg+xml then it has a charset parameter, although
the processor that generated it is non conforming to the existing RFC
3023. But lets press on into how to detect or resolve the error.

BH>   <?xml version="1.0"?>
BH>   ...
BH>   <!--Bj?rn-->
BH>   ...

BH> With no BOM and using only US-ASCII characters for the rest of the
BH> document,

Cleverly constructed example, if the processor believes the charset the
processor will think the comment says Bj??rn. However, as soon as you
save it, your name is mis-spelled. I'm sure you would not like that,
Bj??rn.

So in this case, although the processor that generated it is non
conforming, the content is not non conforming (but it should be) and the
processor that receives it has two possibilities:

a) it can add the missing encoding declaration when processing and when
saving to disk (note that, if the xml happened to be digitally signed
and in canonical XML form, this would break the signature). See RFC 3741

b) it can note that a required encoding declaration is not present, and
throw a well formedness error.

Note that both of these choices will break some content and both of these
choices are licensed by the relevant specifications. There is thus
non-interoperability. Note further that, in the case where the charset
parameter is not present, there is 100% interoperability, no breakage,
all in conformance with the existing clauses in RFC 3023 which 3023bis
will retain, since they are proven by implementation experience with
running code to be highly robust and interoperable.

So, lets take the other case, which is more interesting.

Consider an *8859-1 encoded* document

  Content-Type: application/xml;charset=UTF-8

  <?xml version="1.0"?>
  ...
  <!--Bj?rn-->
  ...

With your proposal, would the well formedness error (bytes occur that
cannot occur in UTF-8) be silently recovered from if the HTTP
header overrides it, even for an XML processor, while it would continue
to fail in other cases (such as server side processing)?

BH> with your proposal, which of the following behaviors of
BH> implementations would be considered conforming?

(see above for discussion of b and c)

BH>   a) it fails to process the document due to RFC3023bis/XML 1.0 errors

That would be the safest course. Consider if the non-ascii character was
a euro or some other currency symbol, if the document was an invoice,
and was being processed by an accounting system not by a human being.
Accounting systems do not have the luxury of a human to look at the
invoice, go to View...Character Encoding and try various possibilities
until it seems to look right, then save the document and edit the local
copy and fix up the encoding declaration

BH>   b) it considers the comment to include "Bj??rn"
BH>   c) it considers the comment to include "Bj?rn"

BH>   * application/xhtml+xml (with no update to RFC3236)

That is an existing type and has an existing charset parameter.
Applications are thus allowed to use it, with all the complications and
breakage that this entails as described above.

BH>   * image/svg+xml (as you propose it)

There is no charset parameter. Processors that generate one and messages
that contain one are in error.

BH> For application/xml / application/xhtml+xml this would currently be b)
BH> as the document includes 0xC3 0xB6 and the encoding is determined to be
BH> ISO-8859-1 which means the sequence above represents "??".

It would sometimes be b) and sometimes c) depending on the particular
software and whether its reading from disk on the server or over the
net. I frankly can't understand how you consider this lack of
interoperability to be a desirable thing.

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

From: derhoermi at gmx.net (Bjoern Hoehrmann)
Date: Wed Nov 24 16:41:59 2004
Subject: MIME Type Review Request: image/svg+xml
In-Reply-To: <[email-masked]>
References: <[email-masked]> <6.0.0.20.2.20041119083958.085ea200@localhost> <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]>
Message-ID: <[email-masked]>

* Chris Lilley wrote:
>As you yourself pointed out, per RFC3023
>
>   Processors generating XML MIME entities MUST NOT label conflicting
>   charset information between the MIME Content-Type and the XML
>   declaration.
>
>such content is already non conforming.

It does not actually apply to content...

>In terms of dealing with such content if it still occurs, the XML well
>formedness rules already handle that in an entirely satisfactory manner
>and nothing further need be added. These are already well implemented
>and highly interoperable.

Consider a *UTF-8 encoded* document

  Content-Type: application/xml;charset=iso-8859-1

  <?xml version="1.0"?>
  ...
  <!--Bj?rn-->
  ...

With no BOM and using only US-ASCII characters for the rest of the
document, with your proposal, which of the following behaviors of
implementations would be considered conforming?

  a) it fails to process the document due to RFC3023bis/XML 1.0 errors
  b) it considers the comment to include "Bj??rn"
  c) it considers the comment to include "Bj?rn"

If none of these behaviors would be conforming, what would be conforming
instead? What would be the answers for your proposal if application/xml
is replaced by the following types and proper content as defined above:

  * application/xhtml+xml (with no update to RFC3236)
  * image/svg+xml (as you propose it)

For application/xml / application/xhtml+xml this would currently be b)
as the document includes 0xC3 0xB6 and the encoding is determined to be
ISO-8859-1 which means the sequence above represents "??".
>From [email-masked]  Wed Nov 24 17:54:56 2004
From: chris at w3.org (Chris Lilley)
Date: Wed Nov 24 17:55:05 2004
Subject: MIME Type Review Request: image/svg+xml
In-Reply-To: <[email-masked]>
References: <[email-masked]>
	<6.0.0.20.2.20041119083958.085ea200@localhost>
	<[email-masked]>
	<[email-masked]>
	<[email-masked]>
	<[email-masked]>
	<[email-masked]>
	<[email-masked]>
Message-ID: <[email-masked]>

On Wednesday, November 24, 2004, 4:41:48 PM, Bjoern wrote:

BH> * Chris Lilley wrote:
>>As you yourself pointed out, per RFC3023
>>
>>   Processors generating XML MIME entities MUST NOT label conflicting
>>   charset information between the MIME Content-Type and the XML
>>   declaration.
>>
>>such content is already non conforming.

BH> It does not actually apply to content...

Yes, that is an ambiguity that needs to be cleared up. It says things
that generate the content must not do that; if that were true, then
there would be no such content. Since there is, its worth splitting this
into two:

- Conformance for XML generators
- Conformance for XML messages (headers plus bodies)

>>In terms of dealing with such content if it still occurs, the XML well
>>formedness rules already handle that in an entirely satisfactory manner
>>and nothing further need be added. These are already well implemented
>>and highly interoperable.

BH> Consider a *UTF-8 encoded* document

BH>   Content-Type: application/xml;charset=iso-8859-1

Since that isn't image/svg+xml then it has a charset parameter, although
the processor that generated it is non conforming to the existing RFC
3023. But lets press on into how to detect or resolve the error.

BH>   <?xml version="1.0"?>
BH>   ...
BH>   <!--Bj?rn-->
BH>   ...

BH> With no BOM and using only US-ASCII characters for the rest of the
BH> document,

Cleverly constructed example, if the processor believes the charset the
processor will think the comment says Bj??rn. However, as soon as you
save it, your name is mis-spelled. I'm sure you would not like that,
Bj??rn.

So in this case, although the processor that generated it is non
conforming, the content is not non conforming (but it should be) and the
processor that receives it has two possibilities:

a) it can add the missing encoding declaration when processing and when
saving to disk (note that, if the xml happened to be digitally signed
and in canonical XML form, this would break the signature). See RFC 3741

b) it can note that a required encoding declaration is not present, and
throw a well formedness error.

Note that both of these choices will break some content and both of these
choices are licensed by the relevant specifications. There is thus
non-interoperability. Note further that, in the case where the charset
parameter is not present, there is 100% interoperability, no breakage,
all in conformance with the existing clauses in RFC 3023 which 3023bis
will retain, since they are proven by implementation experience with
running code to be highly robust and interoperable.

So, lets take the other case, which is more interesting.

Consider an *8859-1 encoded* document

  Content-Type: application/xml;charset=UTF-8

  <?xml version="1.0"?>
  ...
  <!--Bj?rn-->
  ...

With your proposal, would the well formedness error (bytes occur that
cannot occur in UTF-8) be silently recovered from if the HTTP
header overrides it, even for an XML processor, while it would continue
to fail in other cases (such as server side processing)?

BH> with your proposal, which of the following behaviors of
BH> implementations would be considered conforming?

(see above for discussion of b and c)

BH>   a) it fails to process the document due to RFC3023bis/XML 1.0 errors

That would be the safest course. Consider if the non-ascii character was
a euro or some other currency symbol, if the document was an invoice,
and was being processed by an accounting system not by a human being.
Accounting systems do not have the luxury of a human to look at the
invoice, go to View...Character Encoding and try various possibilities
until it seems to look right, then save the document and edit the local
copy and fix up the encoding declaration

BH>   b) it considers the comment to include "Bj??rn"
BH>   c) it considers the comment to include "Bj?rn"

BH>   * application/xhtml+xml (with no update to RFC3236)

That is an existing type and has an existing charset parameter.
Applications are thus allowed to use it, with all the complications and
breakage that this entails as described above.

BH>   * image/svg+xml (as you propose it)

There is no charset parameter. Processors that generate one and messages
that contain one are in error.

BH> For application/xml / application/xhtml+xml this would currently be b)
BH> as the document includes 0xC3 0xB6 and the encoding is determined to be
BH> ISO-8859-1 which means the sequence above represents "??".

It would sometimes be b) and sometimes c) depending on the particular
software and whether its reading from disk on the server or over the
net. I frankly can't understand how you consider this lack of
interoperability to be a desirable thing.

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

From: derhoermi at gmx.net (Bjoern Hoehrmann)
Date: Tue Jan  3 16:22:52 2006
Subject: MIME Type Review Request: image/svg+xml
In-Reply-To: <[email-masked]>
References: <[email-masked]> <6.0.0.20.2.20041119083958.085ea200@localhost> <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]>
Message-ID: <[email-masked]>

* Chris Lilley wrote:
>As you yourself pointed out, per RFC3023
>
>   Processors generating XML MIME entities MUST NOT label conflicting
>   charset information between the MIME Content-Type and the XML
>   declaration.
>
>such content is already non conforming.

It does not actually apply to content...

>In terms of dealing with such content if it still occurs, the XML well
>formedness rules already handle that in an entirely satisfactory manner
>and nothing further need be added. These are already well implemented
>and highly interoperable.

Consider a *UTF-8 encoded* document

  Content-Type: application/xml;charset=iso-8859-1

  <?xml version="1.0"?>
  ...
  <!--Bj?rn-->
  ...

With no BOM and using only US-ASCII characters for the rest of the
document, with your proposal, which of the following behaviors of
implementations would be considered conforming?

  a) it fails to process the document due to RFC3023bis/XML 1.0 errors
  b) it considers the comment to include "Bj??rn"
  c) it considers the comment to include "Bj?rn"

If none of these behaviors would be conforming, what would be conforming
instead? What would be the answers for your proposal if application/xml
is replaced by the following types and proper content as defined above:

  * application/xhtml+xml (with no update to RFC3236)
  * image/svg+xml (as you propose it)

For application/xml / application/xhtml+xml this would currently be b)
as the document includes 0xC3 0xB6 and the encoding is determined to be
ISO-8859-1 which means the sequence above represents "??".

From: chris at w3.org (Chris Lilley)
Date: Tue Jan  3 16:22:52 2006
Subject: MIME Type Review Request: image/svg+xml
In-Reply-To: <[email-masked]>
References: <[email-masked]> <6.0.0.20.2.20041119083958.085ea200@localhost> <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]>
Message-ID: <[email-masked]>

On Wednesday, November 24, 2004, 3:18:50 PM, Bjoern wrote:

BH> * Chris Lilley wrote:
>>BH> Your proposals so far render all applications for which RFC3023 would
>>BH> be relevant non-compliant regardless of whether they implement only
>>BH> some part of RFC3023, the entire specification or implement it not at
>>BH> all.
>>
>>That is incorrect. You seem to miss that once RFC3023 is updated to
>>ensure that the encoding and the charset are the same, the *sole* use of
>>a charset parameter is for non-xml applications.

BH> The use of the charset parameter so far does not seem actually relevant
BH> to this discussion. If I understand correctly that you propose to make

BH>   Content-Type: application/xml;charset=iso-8859-1

BH>   <?xml version="1.0" encoding="utf-8"?>
BH>   ... iso-8859-1 content ...

BH> non-conforming,

As you yourself pointed out, per RFC3023

   Processors generating XML MIME entities MUST NOT label conflicting
   charset information between the MIME Content-Type and the XML
   declaration.

such content is already non conforming.

BH> I would expect that your proposal includes a requirement for
BH> implementations to detect this error and probably also a requirement
BH> to reject such resources.

Since its already non conforming, we just have to deal with the
non-conforming situation. My solution further discourages such content
and is consistent with the architectural principle that silent recovery
from error is harmful

http://www.w3.org/TR/webarch/#no-silent-recovery

In terms of dealing with such content if it still occurs, the XML well
formedness rules already handle that in an entirely satisfactory manner
and nothing further need be added. These are already well implemented
and highly interoperable.

BH> Both requirements would render implementations
BH> of RFC3023 non-conforming since none of them do this.

Thats right, they don't raise an error. They either silently recover by
considering the charset authoritative or they silently recover by
considering the encoding declaration authoritative. Both
interpretations are observed in running code. In addition, when saving
to disk some (a few) alter the inconsistent xml encoding declaration to
make it correct, others (most) do not, thus depositing a non-well-formed
instance in local storage. And you are ok with that messy,
non-interoperable state of affairs?

>>And thus, what use is the redundant declaration? Note that currently
>>there is great variability in what processors do when reading and saving
>>content that has conflicting declarations. Removing the source of the
>>conflict brings us onto safer ground to the area where all
>>implementations behave the same. Surely you can see that this is good
>>and results in more robust, interoperable behavior?

BH> What do you consider the source of the conflict here? As far as I can
BH> tell that would be the charset parameter and as long as implementations
BH> are required to consider it to detect the character encoding the source
BH> of conflict is not removed.

This is doubtless why RFC 3023 says that people should not generate
content that has this conflict, and why TAG says the same thing, not to
generate it unless it is known to be correct. However, implementation
experience since RFC 3023 was issues shows that people do it anyway, and
its a significant problem; so it needs to be fixed. Pretending there is
no problem does not help the situation in any way.

BH> Maybe your point is that people will stop
BH> using the charset parameter in a way that creates potential problems if
BH> RFC3023bis has some conformance rules they make that seem reasonable to
BH> expect?

Right. That would include discouraging the use of an optional and
inconsistently implemented charset parameter for new registrations.

Existing registrations that use it we can do nothing about, although I
would like to see more testing of what processors do in the case of
inconsistent, non-conforming content.

BH> Maybe you can draft an improved proposal to change RFC3023 and post it
BH> to the relevant lists? That would certainly help the discussion.

Excellent suggestion, I will do exactly that (which is, of course, why I
took the action from the TAG to become co-editor. Its much more
effective for the TAG to say something is wrong, and help fix it, than
merely to say it is wrong).

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

From: derhoermi at gmx.net (Bjoern Hoehrmann)
Date: Wed Nov 24 15:19:02 2004
Subject: MIME Type Review Request: image/svg+xml
In-Reply-To: <[email-masked]>
References: <[email-masked]> <6.0.0.20.2.20041119083958.085ea200@localhost> <[email-masked]> <[email-masked]> <[email-masked]>
Message-ID: <[email-masked]>

* Chris Lilley wrote:
>BH> Your proposals so far render all applications for which RFC3023 would
>BH> be relevant non-compliant regardless of whether they implement only
>BH> some part of RFC3023, the entire specification or implement it not at
>BH> all.
>
>That is incorrect. You seem to miss that once RFC3023 is updated to
>ensure that the encoding and the charset are the same, the *sole* use of
>a charset parameter is for non-xml applications.

The use of the charset parameter so far does not seem actually relevant
to this discussion. If I understand correctly that you propose to make

  Content-Type: application/xml;charset=iso-8859-1

  <?xml version="1.0" encoding="utf-8"?>
  ... iso-8859-1 content ...

non-conforming, I would expect that your proposal includes a requirement
for implementations to detect this error and probably also a requirement
to reject such resources. Both requirements would render implementations
of RFC3023 non-conforming since none of them do this. So it would seem
your proposal does not include such requirements, is that correct? In
case this is correct, what is the point of disallowing this and yet to
specify how implementations must process such content (i.e., consider
the resource above ISO-8859-1 encoded)? Or does your proposal also in-
clude changes to how implementations must determine the character en-
coding? It would seem it does not.

>And thus, what use is the redundant declaration? Note that currently
>there is great variability in what processors do when reading and saving
>content that has conflicting declarations. Removing the source of the
>conflict brings us onto safer ground to the area where all
>implementations behave the same. Surely you can see that this is good
>and results in more robust, interoperable behavior?

What do you consider the source of the conflict here? As far as I can
tell that would be the charset parameter and as long as implementations
are required to consider it to detect the character encoding the source
of conflict is not removed. Maybe your point is that people will stop
using the charset parameter in a way that creates potential problems if
RFC3023bis has some conformance rules they make that seem reasonable to
expect?

Maybe you can draft an improved proposal to change RFC3023 and post it
to the relevant lists? That would certainly help the discussion.
>From [email-masked]  Wed Nov 24 15:44:06 2004
From: chris at w3.org (Chris Lilley)
Date: Wed Nov 24 15:44:12 2004
Subject: MIME Type Review Request: image/svg+xml
In-Reply-To: <[email-masked]>
References: <[email-masked]>
	<6.0.0.20.2.20041119083958.085ea200@localhost>
	<[email-masked]>
	<[email-masked]>
	<[email-masked]>
	<[email-masked]>
Message-ID: <[email-masked]>

On Wednesday, November 24, 2004, 3:18:50 PM, Bjoern wrote:

BH> * Chris Lilley wrote:
>>BH> Your proposals so far render all applications for which RFC3023 would
>>BH> be relevant non-compliant regardless of whether they implement only
>>BH> some part of RFC3023, the entire specification or implement it not at
>>BH> all.
>>
>>That is incorrect. You seem to miss that once RFC3023 is updated to
>>ensure that the encoding and the charset are the same, the *sole* use of
>>a charset parameter is for non-xml applications.

BH> The use of the charset parameter so far does not seem actually relevant
BH> to this discussion. If I understand correctly that you propose to make

BH>   Content-Type: application/xml;charset=iso-8859-1

BH>   <?xml version="1.0" encoding="utf-8"?>
BH>   ... iso-8859-1 content ...

BH> non-conforming,

As you yourself pointed out, per RFC3023

   Processors generating XML MIME entities MUST NOT label conflicting
   charset information between the MIME Content-Type and the XML
   declaration.

such content is already non conforming.

BH> I would expect that your proposal includes a requirement for
BH> implementations to detect this error and probably also a requirement
BH> to reject such resources.

Since its already non conforming, we just have to deal with the
non-conforming situation. My solution further discourages such content
and is consistent with the architectural principle that silent recovery
from error is harmful

http://www.w3.org/TR/webarch/#no-silent-recovery

In terms of dealing with such content if it still occurs, the XML well
formedness rules already handle that in an entirely satisfactory manner
and nothing further need be added. These are already well implemented
and highly interoperable.

BH> Both requirements would render implementations
BH> of RFC3023 non-conforming since none of them do this.

Thats right, they don't raise an error. They either silently recover by
considering the charset authoritative or they silently recover by
considering the encoding declaration authoritative. Both
interpretations are observed in running code. In addition, when saving
to disk some (a few) alter the inconsistent xml encoding declaration to
make it correct, others (most) do not, thus depositing a non-well-formed
instance in local storage. And you are ok with that messy,
non-interoperable state of affairs?

>>And thus, what use is the redundant declaration? Note that currently
>>there is great variability in what processors do when reading and saving
>>content that has conflicting declarations. Removing the source of the
>>conflict brings us onto safer ground to the area where all
>>implementations behave the same. Surely you can see that this is good
>>and results in more robust, interoperable behavior?

BH> What do you consider the source of the conflict here? As far as I can
BH> tell that would be the charset parameter and as long as implementations
BH> are required to consider it to detect the character encoding the source
BH> of conflict is not removed.

This is doubtless why RFC 3023 says that people should not generate
content that has this conflict, and why TAG says the same thing, not to
generate it unless it is known to be correct. However, implementation
experience since RFC 3023 was issues shows that people do it anyway, and
its a significant problem; so it needs to be fixed. Pretending there is
no problem does not help the situation in any way.

BH> Maybe your point is that people will stop
BH> using the charset parameter in a way that creates potential problems if
BH> RFC3023bis has some conformance rules they make that seem reasonable to
BH> expect?

Right. That would include discouraging the use of an optional and
inconsistently implemented charset parameter for new registrations.

Existing registrations that use it we can do nothing about, although I
would like to see more testing of what processors do in the case of
inconsistent, non-conforming content.

BH> Maybe you can draft an improved proposal to change RFC3023 and post it
BH> to the relevant lists? That would certainly help the discussion.

Excellent suggestion, I will do exactly that (which is, of course, why I
took the action from the TAG to become co-editor. Its much more
effective for the TAG to say something is wrong, and help fix it, than
merely to say it is wrong).

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

From: derhoermi at gmx.net (Bjoern Hoehrmann)
Date: Tue Jan  3 16:22:52 2006
Subject: MIME Type Review Request: image/svg+xml
In-Reply-To: <[email-masked]>
References: <[email-masked]> <6.0.0.20.2.20041119083958.085ea200@localhost> <[email-masked]> <[email-masked]> <[email-masked]>
Message-ID: <[email-masked]>

* Chris Lilley wrote:
>BH> Your proposals so far render all applications for which RFC3023 would
>BH> be relevant non-compliant regardless of whether they implement only
>BH> some part of RFC3023, the entire specification or implement it not at
>BH> all.
>
>That is incorrect. You seem to miss that once RFC3023 is updated to
>ensure that the encoding and the charset are the same, the *sole* use of
>a charset parameter is for non-xml applications.

The use of the charset parameter so far does not seem actually relevant
to this discussion. If I understand correctly that you propose to make

  Content-Type: application/xml;charset=iso-8859-1

  <?xml version="1.0" encoding="utf-8"?>
  ... iso-8859-1 content ...

non-conforming, I would expect that your proposal includes a requirement
for implementations to detect this error and probably also a requirement
to reject such resources. Both requirements would render implementations
of RFC3023 non-conforming since none of them do this. So it would seem
your proposal does not include such requirements, is that correct? In
case this is correct, what is the point of disallowing this and yet to
specify how implementations must process such content (i.e., consider
the resource above ISO-8859-1 encoded)? Or does your proposal also in-
clude changes to how implementations must determine the character en-
coding? It would seem it does not.

>And thus, what use is the redundant declaration? Note that currently
>there is great variability in what processors do when reading and saving
>content that has conflicting declarations. Removing the source of the
>conflict brings us onto safer ground to the area where all
>implementations behave the same. Surely you can see that this is good
>and results in more robust, interoperable behavior?

What do you consider the source of the conflict here? As far as I can
tell that would be the charset parameter and as long as implementations
are required to consider it to detect the character encoding the source
of conflict is not removed. Maybe your point is that people will stop
using the charset parameter in a way that creates potential problems if
RFC3023bis has some conformance rules they make that seem reasonable to
expect?

Maybe you can draft an improved proposal to change RFC3023 and post it
to the relevant lists? That would certainly help the discussion.

From: chris at w3.org (Chris Lilley)
Date: Tue Jan  3 16:22:52 2006
Subject: MIME Type Review Request: image/svg+xml
In-Reply-To: <[email-masked]>
References: <[email-masked]> <6.0.0.20.2.20041119083958.085ea200@localhost> <[email-masked]> <[email-masked]>
Message-ID: <[email-masked]>

On Wednesday, November 24, 2004, 7:32:59 AM, Bjoern wrote:

BH> * Chris Lilley wrote:
>>Its much more productive to fix RFC3023 to not be in conflict with Web
>>Architecture which (as co-editor) i am involved in doing.

BH> If your goal is to feel good when ignoring reality then that may be so,
BH> if you are more concerned about interoperability of running code, which
BH> is slightly more common in IETF discussions, then maybe not.

Bjoern, that seems uncalled for. Lets try to be civil here. I don't
describe your proposals as fleeing from reality, please do me the same
courtesy. And my reasoning in all of this is, of course, existing
implementations and interoperability.

BH> Your pro-
BH> posals so far render all applications for which RFC3023 would be rele-
BH> vant non-compliant regardless of whether they implement only some part
BH> of RFC3023, the entire specification or implement it not at all.

That is incorrect. You seem to miss that once RFC3023 is updated to
ensure that the encoding and the charset are the same, the *sole* use of
a charset parameter is for non-xml applications.

BH> Some of your proposals even
BH> seem out of scope of RFC3023bis as they in essence make it a fatal error
BH> as defined in XML 1.0 if higher-level protocol information affects the
BH> detection of the character encoding of the XML entity which contradicts
BH> XML 1.0. It rather seems you want to change the XML specifications in
BH> which case you should talk to the W3C XML Core Working Group.

No, you mis-state my position. Incidentally, since you bring up the XML
Core WG, you realise that the text I cited in the ASrchitecture document
was written by Tim Bray, co-editor of the XML specification?

BH> Of course, assuming that I actually understand your proposals,

I suspect that you do not, which would explain both the content and the
tone of your comments.

BH> none of
BH> them has really been clear yet, you sometimes give the impression that
BH> the requirements your propose to add to RFC3023bis just render some
BH> content non-compliant without any actual effect on conforming
BH> implementations, that would then be even worse as it would have no
BH> effect in practise other than complicating theory even more. In fact,
BH> in that case one would even wonder what you are actually trying to
BH> achieve, as RFC 3023 already states

BH>   Processors generating XML MIME entities MUST NOT label conflicting
BH>   charset information between the MIME Content-Type and the XML
BH>   declaration.

And thus, what use is the redundant declaration? Note that currently
there is great variability in what processors do when reading and saving
content that has conflicting declarations. Removing the source of the
conflict brings us onto safer ground to the area where all
implementations behave the same. Surely you can see that this is good
and results in more robust, interoperable behavior?

I am frankly puzzled by your insistence on retaining the woolly
non-interoperable area while simultaneously claiming that i am
unrealistic and do not care for interoperability.....

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

From: derhoermi at gmx.net (Bjoern Hoehrmann)
Date: Tue Jan  3 16:22:52 2006
Subject: MIME Type Review Request: image/svg+xml
In-Reply-To: <[email-masked]>
References: <[email-masked]> <6.0.0.20.2.20041119083958.085ea200@localhost> <[email-masked]>
Message-ID: <[email-masked]>

* Chris Lilley wrote:
>Its much more productive to fix RFC3023 to not be in conflict with Web
>Architecture which (as co-editor) i am involved in doing.

If your goal is to feel good when ignoring reality then that may be so,
if you are more concerned about interoperability of running code, which
is slightly more common in IETF discussions, then maybe not. Your pro-
posals so far render all applications for which RFC3023 would be rele-
vant non-compliant regardless of whether they implement only some part
of RFC3023, the entire specification or implement it not at all. That's
not going to help interoperability much. Some of your proposals even
seem out of scope of RFC3023bis as they in essence make it a fatal error
as defined in XML 1.0 if higher-level protocol information affects the
detection of the character encoding of the XML entity which contradicts
XML 1.0. It rather seems you want to change the XML specifications in
which case you should talk to the W3C XML Core Working Group.

Of course, assuming that I actually understand your proposals, none of
them has really been clear yet, you sometimes give the impression that
the requirements your propose to add to RFC3023bis just render some
content non-compliant without any actual effect on conforming
implementations, that would then be even worse as it would have no
effect in practise other than complicating theory even more. In fact,
in that case one would even wonder what you are actually trying to
achieve, as RFC 3023 already states

  Processors generating XML MIME entities MUST NOT label conflicting
  charset information between the MIME Content-Type and the XML
  declaration.

>Actually no. The sole use case for the charset, given that in the
>revision of 3023 is required to be the same as what the xml encoding
>declaration says, is for *non* xml processors. XML processors will know
>how to read and interpret the xml encoding declaration.

It is not really acceptable to make the image/svg+xml registration
dependant on a possible revision of some other document, especially if
it seems unlikely that such a revision will pass IETF/IESG review which
seems to be the case so far.

>Your proposal to add a redundant charset parameter merely complicates
>server setup, requires authoring tools to be specially configured to
>understand server setup, and requires xml instances to be rewritten wen
>saved to local disk. All this to benefit *non xml aware* processors
>which are going to save to local disk anyway - and if they do, and use
>the charset parameter, they still have to understand enough of the xml
>syntax to reliably rewrite the encoding declaration. It also results in
>xml that is not well formed sitting on the server, making it much harder
>to do server side processing.

The point Martin and others are making is that image/svg+xml should not
be different from all other XML MIME types, none of the arguments you
cite is actually relevant to that case, they rather discuss why having a
charset parameter in the first place is a bad idea for some formats. If
your point is that image/svg+xml should be better than all the other
types, do not use the +xml convention as that convention implies a
charset parameter with well-defined processing semantics. Note that even
with your proposals to change RFC3023 image/svg+xml would still be
different from all other types if it does not define the semantics of
the charset parameter for the type.

From: blilly at erols.com (Bruce Lilly)
Date: Wed Nov 24 01:21:42 2004
Subject: Testing the waters for text/troff
In-Reply-To: <6.0.0.20.2.20041123084754.05f1b608@localhost>
References: <[email-masked]> <6.0.0.20.2.20041123084754.05f1b608@localhost>
Message-ID: <[email-masked]>

On Mon November 22 2004 18:51, Martin Duerst wrote:
> I don't remember anything. I guess an explanation for this would
> be that nroff/troff isn't usually passed to applications directly
> (i.e. neither for mailers nor for browsers).

Curiously, the original Content-Type specification (RFC 1049) did
mention troff.   I definitely wouldn't want to encourage automatic
passing of content to applications, as there are security implications.
Nevertheless, the textual content (ignoring formatting
directives) is still comprehensible when viewed as ordinary text,
comparable to (some would say better than) SGML and its
variants.  Having a registered label as a text media subtype
provides a way to indicate the content type as text (with markup)
as opposed to an opaque blob (application/octet-stream).

> But if you think it's 
> something you and others want to use, please go ahead and write a
> draft.

I've started one.

> At the momement, I can't immagine anything that would lead 
> to a rejection of a well-written proposal. The main issues that
> I can immagine (although I'm not an expert on ?roff stuff) you will
> have to deal with would probably have to do with versioning.

There are certainly version and other compatibility (application-
level interoperability) issues, but I believe that they're manageable.
Regarding the mechanics of dealing with the registration template,
the biggest problem seems to be finding something appropriate for
some of the obscure things asked for; for example, I have no idea
what "Macintosh File Type Code(s)" is supposed to mean
[searching for "Macintosh File Type Code" on the Apple web site
yielded zero useful results].
>From [email-masked]  Wed Nov 24 07:32:59 2004
From: derhoermi at gmx.net (Bjoern Hoehrmann)
Date: Wed Nov 24 07:33:11 2004
Subject: MIME Type Review Request: image/svg+xml
In-Reply-To: <[email-masked]>
References: <[email-masked]>
	<6.0.0.20.2.20041119083958.085ea200@localhost>
	<[email-masked]>
Message-ID: <[email-masked]>

* Chris Lilley wrote:
>Its much more productive to fix RFC3023 to not be in conflict with Web
>Architecture which (as co-editor) i am involved in doing.

If your goal is to feel good when ignoring reality then that may be so,
if you are more concerned about interoperability of running code, which
is slightly more common in IETF discussions, then maybe not. Your pro-
posals so far render all applications for which RFC3023 would be rele-
vant non-compliant regardless of whether they implement only some part
of RFC3023, the entire specification or implement it not at all. That's
not going to help interoperability much. Some of your proposals even
seem out of scope of RFC3023bis as they in essence make it a fatal error
as defined in XML 1.0 if higher-level protocol information affects the
detection of the character encoding of the XML entity which contradicts
XML 1.0. It rather seems you want to change the XML specifications in
which case you should talk to the W3C XML Core Working Group.

Of course, assuming that I actually understand your proposals, none of
them has really been clear yet, you sometimes give the impression that
the requirements your propose to add to RFC3023bis just render some
content non-compliant without any actual effect on conforming
implementations, that would then be even worse as it would have no
effect in practise other than complicating theory even more. In fact,
in that case one would even wonder what you are actually trying to
achieve, as RFC 3023 already states

  Processors generating XML MIME entities MUST NOT label conflicting
  charset information between the MIME Content-Type and the XML
  declaration.

>Actually no. The sole use case for the charset, given that in the
>revision of 3023 is required to be the same as what the xml encoding
>declaration says, is for *non* xml processors. XML processors will know
>how to read and interpret the xml encoding declaration.

It is not really acceptable to make the image/svg+xml registration
dependant on a possible revision of some other document, especially if
it seems unlikely that such a revision will pass IETF/IESG review which
seems to be the case so far.

>Your proposal to add a redundant charset parameter merely complicates
>server setup, requires authoring tools to be specially configured to
>understand server setup, and requires xml instances to be rewritten wen
>saved to local disk. All this to benefit *non xml aware* processors
>which are going to save to local disk anyway - and if they do, and use
>the charset parameter, they still have to understand enough of the xml
>syntax to reliably rewrite the encoding declaration. It also results in
>xml that is not well formed sitting on the server, making it much harder
>to do server side processing.

The point Martin and others are making is that image/svg+xml should not
be different from all other XML MIME types, none of the arguments you
cite is actually relevant to that case, they rather discuss why having a
charset parameter in the first place is a bad idea for some formats. If
your point is that image/svg+xml should be better than all the other
types, do not use the +xml convention as that convention implies a
charset parameter with well-defined processing semantics. Note that even
with your proposals to change RFC3023 image/svg+xml would still be
different from all other types if it does not define the semantics of
the charset parameter for the type.
>From [email-masked]  Wed Nov 24 12:30:25 2004
From: chris at w3.org (Chris Lilley)
Date: Wed Nov 24 12:30:32 2004
Subject: MIME Type Review Request: image/svg+xml
In-Reply-To: <[email-masked]>
References: <[email-masked]>
	<6.0.0.20.2.20041119083958.085ea200@localhost>
	<[email-masked]>
	<[email-masked]>
Message-ID: <[email-masked]>

On Wednesday, November 24, 2004, 7:32:59 AM, Bjoern wrote:

BH> * Chris Lilley wrote:
>>Its much more productive to fix RFC3023 to not be in conflict with Web
>>Architecture which (as co-editor) i am involved in doing.

BH> If your goal is to feel good when ignoring reality then that may be so,
BH> if you are more concerned about interoperability of running code, which
BH> is slightly more common in IETF discussions, then maybe not.

Bjoern, that seems uncalled for. Lets try to be civil here. I don't
describe your proposals as fleeing from reality, please do me the same
courtesy. And my reasoning in all of this is, of course, existing
implementations and interoperability.

BH> Your pro-
BH> posals so far render all applications for which RFC3023 would be rele-
BH> vant non-compliant regardless of whether they implement only some part
BH> of RFC3023, the entire specification or implement it not at all.

That is incorrect. You seem to miss that once RFC3023 is updated to
ensure that the encoding and the charset are the same, the *sole* use of
a charset parameter is for non-xml applications.

BH> Some of your proposals even
BH> seem out of scope of RFC3023bis as they in essence make it a fatal error
BH> as defined in XML 1.0 if higher-level protocol information affects the
BH> detection of the character encoding of the XML entity which contradicts
BH> XML 1.0. It rather seems you want to change the XML specifications in
BH> which case you should talk to the W3C XML Core Working Group.

No, you mis-state my position. Incidentally, since you bring up the XML
Core WG, you realise that the text I cited in the ASrchitecture document
was written by Tim Bray, co-editor of the XML specification?

BH> Of course, assuming that I actually understand your proposals,

I suspect that you do not, which would explain both the content and the
tone of your comments.

BH> none of
BH> them has really been clear yet, you sometimes give the impression that
BH> the requirements your propose to add to RFC3023bis just render some
BH> content non-compliant without any actual effect on conforming
BH> implementations, that would then be even worse as it would have no
BH> effect in practise other than complicating theory even more. In fact,
BH> in that case one would even wonder what you are actually trying to
BH> achieve, as RFC 3023 already states

BH>   Processors generating XML MIME entities MUST NOT label conflicting
BH>   charset information between the MIME Content-Type and the XML
BH>   declaration.

And thus, what use is the redundant declaration? Note that currently
there is great variability in what processors do when reading and saving
content that has conflicting declarations. Removing the source of the
conflict brings us onto safer ground to the area where all
implementations behave the same. Surely you can see that this is good
and results in more robust, interoperable behavior?

I am frankly puzzled by your insistence on retaining the woolly
non-interoperable area while simultaneously claiming that i am
unrealistic and do not care for interoperability.....

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

From: blilly at erols.com (Bruce Lilly)
Date: Tue Jan  3 16:22:52 2006
Subject: Testing the waters for text/troff
In-Reply-To: <6.0.0.20.2.20041123084754.05f1b608@localhost>
References: <[email-masked]> <6.0.0.20.2.20041123084754.05f1b608@localhost>
Message-ID: <[email-masked]>

On Mon November 22 2004 18:51, Martin Duerst wrote:
> I don't remember anything. I guess an explanation for this would
> be that nroff/troff isn't usually passed to applications directly
> (i.e. neither for mailers nor for browsers).

Curiously, the original Content-Type specification (RFC 1049) did
mention troff.   I definitely wouldn't want to encourage automatic
passing of content to applications, as there are security implications.
Nevertheless, the textual content (ignoring formatting
directives) is still comprehensible when viewed as ordinary text,
comparable to (some would say better than) SGML and its
variants.  Having a registered label as a text media subtype
provides a way to indicate the content type as text (with markup)
as opposed to an opaque blob (application/octet-stream).

> But if you think it's 
> something you and others want to use, please go ahead and write a
> draft.

I've started one.

> At the momement, I can't immagine anything that would lead 
> to a rejection of a well-written proposal. The main issues that
> I can immagine (although I'm not an expert on ?roff stuff) you will
> have to deal with would probably have to do with versioning.

There are certainly version and other compatibility (application-
level interoperability) issues, but I believe that they're manageable.
Regarding the mechanics of dealing with the registration template,
the biggest problem seems to be finding something appropriate for
some of the obscure things asked for; for example, I have no idea
what "Macintosh File Type Code(s)" is supposed to mean
[searching for "Macintosh File Type Code" on the Apple web site
yielded zero useful results].

From: chris at w3.org (Chris Lilley)
Date: Tue Nov 23 19:28:34 2004
Subject: MIME Type Review Request: image/svg+xml
In-Reply-To: <6.0.0.20.2.20041119083958.085ea200@localhost>
References: <[email-masked]> <6.0.0.20.2.20041119083958.085ea200@localhost>
Message-ID: <[email-masked]>

On Friday, November 19, 2004, 1:08:27 AM, Martin wrote:

MD> Sorry this is late. Here are some comments on this registration:

MD> - Some of the ideas discussed at
MD>   
MD> http://eikenes.alvestrand.no/pipermail/ietf-types/2004-July/000298.html
MD>    might help improve the specification.

Thanks, I will take a look.

MD> - The text below was produced by using an HTML-to-text conversion.
MD>    Ideally, it should be possible to use the registration template
MD>    directly as plain text, i.e. the most important URIs should
MD>    appear in plain text.

Thats certainly a possibility. Or the conversion could be trimmed by
hand. i was trying to ensure that exactly the same text was in te W3C
appendix and the registration.

MD> - On the other hand, there is no need to provide URIs for RFCs.
MD>    Something like "... [6]RFC3023 ..."
MD>        [6] http://www.w3.org/TR/SVG12/references
MD>    in an IETF context, is quite confusing.

Yes.

MD> - "Published specification:
MD>           This media type registration is extracted from Appendix G of
MD>           the SVG 1.2 specification."
MD>    This sounds like it's the wrong way round. "Published specification"
MD>    doesn't mean the specification of the registration template, but
MD>    the specification of the format.

Yes this could have ben better worded. I was trying to say "the
published specification is SVG 1.2, of which this registration forms
appendix G.

MD> - Last but not least, I agree with comments already made in this venue
MD>    that this media type should allow the 'charset' parameter as defined
MD>    in RFC 3023. As argued in detail at
MD>    http://lists.w3.org/Archives/Public/www-tag/2004Nov/0034.html,
MD>    I do not see any way to justify removing the 'charset' parameter

In that case, perhaps you could examine
http://lists.w3.org/Archives/Public/www-tag/2004Oct/0016.html

and argue against the points made there, saying why the approved TAG
findings and the Architecture of the World Wide Web are incorrect.

Its much more productive to fix RFC3023 to not be in conflict with Web
Architecture which (as co-editor) i am involved in doing.

MD> Continuing to allow the 'charset' parameter (or in this case,
MD> putting it back in)

Neither of those are correct. it is not a case of putting it back in,
since it was never there; it is not a case of continuing to allow it,
since it is not there.

MD> will make it easier to use generic tools (both on the producer side
MD> (databases, java servlets,...) and on the client side (xml editors,
MD> validators,...), which is one of the main advantages of +xml.

Actually no. The sole use case for the charset, given that in the
revision of 3023 is required to be the same as what the xml encoding
declaration says, is for *non* xml processors. XML processors will know
how to read and interpret the xml encoding declaration.

 >>   Optional parameters:
 >>          None
 >>
 >>          The encoding of an SVG document is determined by the XML
 >>          encoding declaration. This has identical semantics to the
 >>          application/xml media type in the case where the charset
 >>          parameter is omitted, as specified in [6]RFC3023 sections 8.9,
 >>          8.10 and 8.11.

The cases stated there are entirely adequate for robust, interoperable
encoding declaration and are widely, indeed ubiquitously, implemented.
They can confidently be generated by all authoring tools without
knowledge of the precise server configuration.

Your proposal to add a redundant charset parameter merely complicates
server setup, requires authoring tools to be specially configured to
understand server setup, and requires xml instances to be rewritten wen
saved to local disk. All this to benefit *non xml aware* processors
which are going to save to local disk anyway - and if they do, and use
the charset parameter, they still have to understand enough of the xml
syntax to reliably rewrite the encoding declaration. It also results in
xml that is not well formed sitting on the server, making it much harder
to do server side processing.

In conclusion your proposed addition increases complexity, decreases
interoperability, is contrary to existing practice, and provides no
benefit. I thus find it a less than compelling addition.
 
-- 
 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:52 2006
Subject: MIME Type Review Request: image/svg+xml
In-Reply-To: <6.0.0.20.2.20041119083958.085ea200@localhost>
References: <[email-masked]> <6.0.0.20.2.20041119083958.085ea200@localhost>
Message-ID: <[email-masked]>

On Friday, November 19, 2004, 1:08:27 AM, Martin wrote:

MD> Sorry this is late. Here are some comments on this registration:

MD> - Some of the ideas discussed at
MD>   
MD> http://eikenes.alvestrand.no/pipermail/ietf-types/2004-July/000298.html
MD>    might help improve the specification.

Thanks, I will take a look.

MD> - The text below was produced by using an HTML-to-text conversion.
MD>    Ideally, it should be possible to use the registration template
MD>    directly as plain text, i.e. the most important URIs should
MD>    appear in plain text.

Thats certainly a possibility. Or the conversion could be trimmed by
hand. i was trying to ensure that exactly the same text was in te W3C
appendix and the registration.

MD> - On the other hand, there is no need to provide URIs for RFCs.
MD>    Something like "... [6]RFC3023 ..."
MD>        [6] http://www.w3.org/TR/SVG12/references
MD>    in an IETF context, is quite confusing.

Yes.

MD> - "Published specification:
MD>           This media type registration is extracted from Appendix G of
MD>           the SVG 1.2 specification."
MD>    This sounds like it's the wrong way round. "Published specification"
MD>    doesn't mean the specification of the registration template, but
MD>    the specification of the format.

Yes this could have ben better worded. I was trying to say "the
published specification is SVG 1.2, of which this registration forms
appendix G.

MD> - Last but not least, I agree with comments already made in this venue
MD>    that this media type should allow the 'charset' parameter as defined
MD>    in RFC 3023. As argued in detail at
MD>    http://lists.w3.org/Archives/Public/www-tag/2004Nov/0034.html,
MD>    I do not see any way to justify removing the 'charset' parameter

In that case, perhaps you could examine
http://lists.w3.org/Archives/Public/www-tag/2004Oct/0016.html

and argue against the points made there, saying why the approved TAG
findings and the Architecture of the World Wide Web are incorrect.

Its much more productive to fix RFC3023 to not be in conflict with Web
Architecture which (as co-editor) i am involved in doing.

MD> Continuing to allow the 'charset' parameter (or in this case,
MD> putting it back in)

Neither of those are correct. it is not a case of putting it back in,
since it was never there; it is not a case of continuing to allow it,
since it is not there.

MD> will make it easier to use generic tools (both on the producer side
MD> (databases, java servlets,...) and on the client side (xml editors,
MD> validators,...), which is one of the main advantages of +xml.

Actually no. The sole use case for the charset, given that in the
revision of 3023 is required to be the same as what the xml encoding
declaration says, is for *non* xml processors. XML processors will know
how to read and interpret the xml encoding declaration.

 >>   Optional parameters:
 >>          None
 >>
 >>          The encoding of an SVG document is determined by the XML
 >>          encoding declaration. This has identical semantics to the
 >>          application/xml media type in the case where the charset
 >>          parameter is omitted, as specified in [6]RFC3023 sections 8.9,
 >>          8.10 and 8.11.

The cases stated there are entirely adequate for robust, interoperable
encoding declaration and are widely, indeed ubiquitously, implemented.
They can confidently be generated by all authoring tools without
knowledge of the precise server configuration.

Your proposal to add a redundant charset parameter merely complicates
server setup, requires authoring tools to be specially configured to
understand server setup, and requires xml instances to be rewritten wen
saved to local disk. All this to benefit *non xml aware* processors
which are going to save to local disk anyway - and if they do, and use
the charset parameter, they still have to understand enough of the xml
syntax to reliably rewrite the encoding declaration. It also results in
xml that is not well formed sitting on the server, making it much harder
to do server side processing.

In conclusion your proposed addition increases complexity, decreases
interoperability, is contrary to existing practice, and provides no
benefit. I thus find it a less than compelling addition.
 
-- 
 Chris Lilley                    mailto:[email-masked]
 Chair, W3C SVG Working Group
 Member, W3C Technical Architecture Group

From: duerst at w3.org (Martin Duerst)
Date: Tue Jan  3 16:22:52 2006
Subject: Testing the waters for text/troff
In-Reply-To: <[email-masked]>
References: <[email-masked]>
Message-ID: <6.0.0.20.2.20041123084754.05f1b608@localhost>

I don't remember anything. I guess an explanation for this would
be that nroff/troff isn't usually passed to applications directly
(i.e. neither for mailers nor for browsers). But if you think it's
something you and others want to use, please go ahead and write a
draft. At the momement, I can't immagine anything that would lead
to a rejection of a well-written proposal. The main issues that
I can immagine (although I'm not an expert on ?roff stuff) you will
have to deal with would probably have to do with versioning.

Regards,    Martin.

At 04:54 04/11/23, Bruce Lilly wrote:
 >I am quite surprised that there is no registered MIME media type for
 >text with nroff/troff markup, especially as that format has traditionally
 >been used for RFC and Internet Draft documents (RFC 2223).  I
 >could find no record in the archives of this mailing list of any
 >discussion on the matter.  Has there been any proposal for such a
 >text subtype, and if so, what were the reasons that have prevented
 >it from being approved? 

From: blilly at erols.com (Bruce Lilly)
Date: Mon Nov 22 20:55:39 2004
Subject: Testing the waters for text/troff
Message-ID: <[email-masked]>

I am quite surprised that there is no registered MIME media type for
text with nroff/troff markup, especially as that format has traditionally
been used for RFC and Internet Draft documents (RFC 2223).  I
could find no record in the archives of this mailing list of any
discussion on the matter.  Has there been any proposal for such a
text subtype, and if so, what were the reasons that have prevented
it from being approved? 
>From [email-masked]  Tue Nov 23 00:51:15 2004
From: duerst at w3.org (Martin Duerst)
Date: Tue Nov 23 02:18:12 2004
Subject: Testing the waters for text/troff
In-Reply-To: <[email-masked]>
References: <[email-masked]>
Message-ID: <6.0.0.20.2.20041123084754.05f1b608@localhost>

I don't remember anything. I guess an explanation for this would
be that nroff/troff isn't usually passed to applications directly
(i.e. neither for mailers nor for browsers). But if you think it's
something you and others want to use, please go ahead and write a
draft. At the momement, I can't immagine anything that would lead
to a rejection of a well-written proposal. The main issues that
I can immagine (although I'm not an expert on ?roff stuff) you will
have to deal with would probably have to do with versioning.

Regards,    Martin.

At 04:54 04/11/23, Bruce Lilly wrote:
 >I am quite surprised that there is no registered MIME media type for
 >text with nroff/troff markup, especially as that format has traditionally
 >been used for RFC and Internet Draft documents (RFC 2223).  I
 >could find no record in the archives of this mailing list of any
 >discussion on the matter.  Has there been any proposal for such a
 >text subtype, and if so, what were the reasons that have prevented
 >it from being approved? 

From: blilly at erols.com (Bruce Lilly)
Date: Tue Jan  3 16:22:52 2006
Subject: Testing the waters for text/troff
Message-ID: <[email-masked]>

I am quite surprised that there is no registered MIME media type for
text with nroff/troff markup, especially as that format has traditionally
been used for RFC and Internet Draft documents (RFC 2223).  I
could find no record in the archives of this mailing list of any
discussion on the matter.  Has there been any proposal for such a
text subtype, and if so, what were the reasons that have prevented
it from being approved? 

From: jeanluc.mc at wanadoo.fr (jeanluc borla)
Date: Sat Nov 20 18:37:52 2004
Subject: XMF mime type
References: <[email-masked]>
Message-ID: <002401c4cf27$99d0f920$3205a8c0@8030cwh20156>

Hi,
Could someone give me infos about XMF (0,1,2) mime types.

It seems that  XMF 0,1,2 correspond to MIDI type 0 (no track data), 1
(track data), 2 (DLS).

They all should have same mime type but it's my understanding that several
mime type exist, which are:
audio/mobile-xmf, audio/x-xmf, audio/xmf and perhaps audio/x-midi

The models which support XMF are: Sendo X, Siemens SX1, Motorola A1000,
Motorola E 1000

So could you tell me what mime type correspond to each XMF format and each
model mobile

Best Regards,

Jean Luc Borla

From: jeanluc.mc at wanadoo.fr (jeanluc borla)
Date: Tue Jan  3 16:22:52 2006
Subject: XMF mime type
References: <[email-masked]>
Message-ID: <002401c4cf27$99d0f920$3205a8c0@8030cwh20156>

Hi,
Could someone give me infos about XMF (0,1,2) mime types.

It seems that  XMF 0,1,2 correspond to MIDI type 0 (no track data), 1
(track data), 2 (DLS).

They all should have same mime type but it's my understanding that several
mime type exist, which are:
audio/mobile-xmf, audio/x-xmf, audio/xmf and perhaps audio/x-midi

The models which support XMF are: Sendo X, Siemens SX1, Motorola A1000,
Motorola E 1000

So could you tell me what mime type correspond to each XMF format and each
model mobile

Best Regards,

Jean Luc Borla

From: Paul.Sandoz at Sun.COM (Paul Sandoz)
Date: Fri Nov 19 12:31:25 2004
Subject: FWS and FI MIME types <was> Re: MIME types for preliminary community review
In-Reply-To: <[email-masked]>
References: <[email-masked]> <[email-masked]>
Message-ID: <[email-masked]>

Ben Morrow wrote:
> At  9pm on 11/11/04 you (Paul Sandoz) wrote:
> 
> 
>>MIME media type name:
>>application
>>
>>MIME subtype name:
>>soap+fastinfoset
> 
> 
> This is an incorrect generalization of the name 'soap+xml'. Names with +
> in them are (IIRC) currently reserved, except for the case of '+xml' to
> indicate an format which uses XML. The name should be
> 'soap-fastinfoset', or you should propose that the IETF extend the
> '+xml' syntax to other types (such as fastinfoset) and get an IANA
> registry set up for such types... personally, I think that would be a
> very good idea (I can think of at least two other uses for this
> convention: '+zip' for formats which are a zip file with a specific
> layout, such as JAR, Perl's PAR, mozilla.org's XPI and Quake's pk3; and
> '+gzip'/'+bzip2' to denote a gzip compressed version of a format), but
> it would need proper discussion and specification.
>

After some browsing: nowhere in the the new MIME specification and 
registration draft [1], RFC 2048 [2] or RFC 3023 [3] does it state that 
names with '+' in them are reserved. But i think what you are getting at 
is that '+' may now be commonly accepted as a mechanism in MIME even 
though this is not specified?

 From RFC 3023, A.12:

"It was thought that '+' expressed the semantics that a MIME type can be 
treated (for example) as both scalable vector graphics AND ALSO as XML; 
it is both simultaneously."

It is in that same reasoning that 'soap+fastinfoset' was chosen because 
it can be treated as both SOAP and also as a fast infoset document.

The intention was not to specify a naming convention as in section 7 of 
RFC 3023. I think it way to premature for this. However, it would be 
good to be consistent with existing patterns if such a convention were 
deemed appropriate in the future.

> 
>>Magic number(s):
>>A W3C SOAP message infoset serialized as a fast infoset document may begin 
>>with one of the following byte sequences:
>>
>>- a byte sequence that corresponds to a UTF-8 encoded XML declaration of the 
>>string "<?xml version='1.0' encoding='finf'", the first five bytes of which 
>>are hexadecimal 3C 3F 78 6D 6C;
> 
> 
> The first five bytes here are not the relevant ones; the important bytes
> are the 66 69 6e 66 at position 31; perhaps a sentence to the effect of
> 'fast infoset documents can be XML documents with an encoding of 'finf'
> specified in the XML declaration' with a reference to the XML
> registration for how to identify and parse an XML document.

Good point, the first four bytes will only indicate a UTF-8 encoded XML 
document or a fast infoset document.

In the Fast Infoset specification we declare 9 possible character 
strings encoded in UTF-8:

<?xml encoding='finf'?>
<?xml encoding='finf' standalone='yes'?>
<?xml encoding='finf' standalone='no'?>
<?xml version='1.0' encoding='finf'?>
<?xml version='1.0' encoding='finf' standalone='yes'?>
<?xml version='1.0' encoding='finf' standalone='no'?>
<?xml version='1.1' encoding='finf'?>
<?xml version='1.1' encoding='finf' standalone='yes'?>
<?xml version='1.1' encoding='finf' standalone='no'?>

I think it best to be explicit and list these directly.

> Also, this
> does not identify specifically a soap fast infoset entity, merely a
> generic fast infoset entity, so this whole section should probably just
> reference the next registration unless there is a way to reliably
> identify those fast infosets used in SOAP.
>

Referencing the generic MIME type is a good idea.

After successful identification of a fast infoset document one would 
have to look at the properties of the root element information by 
parsing the document (the same applies to soap+xml) and checking it 
conforms to the SOAP Envelope element information item [4]. I should 
recheck the SOAP 1.2 MIME type to see what it says.

> I'm a little worried about 'bytes' as opposed to 'octets': what's the
> IETF position on this? 'octets' is definitely less ambiguous.
>

I will change to use 'octets', making it consistent with what is used in 
the normative parts of the Fast Infoset specification.

> 
>>MIME media type name:
>>application
>>
>>MIME subtype name:
>>fastinfoset
> 
> 
> Is it worth registering two separate types, 'application/fastinfoset'
> and 'application/fastinfoset+xml' for fast infosets that are not and are
> encoded as XML documents, respectively?
>

The latter would not make any sense. A fast infoset document and an XML 
document are two distinct serializations of an XML infoset. The infoset 
may have been produced by parsing an XML document, a fast infoset 
document, or by other means (a synthetic infoset). An infoset produced 
by parsing a fast infoset document may be serialized to an XML document. 
So it is possible to convert between fast infoset documents and XML 
documents and round trip an infoset (and also the serializations if 
using canonical forms). Thus 'application/fastinfoset+xml' would be 
equivalent to 'text/xml'.

Paul.

[1] http://www.ietf.org/internet-drafts/draft-freed-media-type-reg-01.txt
[2] http://rfc.net/rfc2048.html
[3] http://rfc.net/rfc3023.html
[4] http://www.w3.org/TR/soap12-part1/#soapenvelope

-- 
| ? + ? = To question
----------------\
    Paul Sandoz
         x38109
+33-4-76188109

From: Paul.Sandoz at Sun.COM (Paul Sandoz)
Date: Tue Jan  3 16:22:52 2006
Subject: FWS and FI MIME types <was> Re: MIME types for preliminary community review
In-Reply-To: <[email-masked]>
References: <[email-masked]> <[email-masked]>
Message-ID: <[email-masked]>

Ben Morrow wrote:
> At  9pm on 11/11/04 you (Paul Sandoz) wrote:
> 
> 
>>MIME media type name:
>>application
>>
>>MIME subtype name:
>>soap+fastinfoset
> 
> 
> This is an incorrect generalization of the name 'soap+xml'. Names with +
> in them are (IIRC) currently reserved, except for the case of '+xml' to
> indicate an format which uses XML. The name should be
> 'soap-fastinfoset', or you should propose that the IETF extend the
> '+xml' syntax to other types (such as fastinfoset) and get an IANA
> registry set up for such types... personally, I think that would be a
> very good idea (I can think of at least two other uses for this
> convention: '+zip' for formats which are a zip file with a specific
> layout, such as JAR, Perl's PAR, mozilla.org's XPI and Quake's pk3; and
> '+gzip'/'+bzip2' to denote a gzip compressed version of a format), but
> it would need proper discussion and specification.
>

After some browsing: nowhere in the the new MIME specification and 
registration draft [1], RFC 2048 [2] or RFC 3023 [3] does it state that 
names with '+' in them are reserved. But i think what you are getting at 
is that '+' may now be commonly accepted as a mechanism in MIME even 
though this is not specified?

 From RFC 3023, A.12:

"It was thought that '+' expressed the semantics that a MIME type can be 
treated (for example) as both scalable vector graphics AND ALSO as XML; 
it is both simultaneously."

It is in that same reasoning that 'soap+fastinfoset' was chosen because 
it can be treated as both SOAP and also as a fast infoset document.

The intention was not to specify a naming convention as in section 7 of 
RFC 3023. I think it way to premature for this. However, it would be 
good to be consistent with existing patterns if such a convention were 
deemed appropriate in the future.

> 
>>Magic number(s):
>>A W3C SOAP message infoset serialized as a fast infoset document may begin 
>>with one of the following byte sequences:
>>
>>- a byte sequence that corresponds to a UTF-8 encoded XML declaration of the 
>>string "<?xml version='1.0' encoding='finf'", the first five bytes of which 
>>are hexadecimal 3C 3F 78 6D 6C;
> 
> 
> The first five bytes here are not the relevant ones; the important bytes
> are the 66 69 6e 66 at position 31; perhaps a sentence to the effect of
> 'fast infoset documents can be XML documents with an encoding of 'finf'
> specified in the XML declaration' with a reference to the XML
> registration for how to identify and parse an XML document.

Good point, the first four bytes will only indicate a UTF-8 encoded XML 
document or a fast infoset document.

In the Fast Infoset specification we declare 9 possible character 
strings encoded in UTF-8:

<?xml encoding='finf'?>
<?xml encoding='finf' standalone='yes'?>
<?xml encoding='finf' standalone='no'?>
<?xml version='1.0' encoding='finf'?>
<?xml version='1.0' encoding='finf' standalone='yes'?>
<?xml version='1.0' encoding='finf' standalone='no'?>
<?xml version='1.1' encoding='finf'?>
<?xml version='1.1' encoding='finf' standalone='yes'?>
<?xml version='1.1' encoding='finf' standalone='no'?>

I think it best to be explicit and list these directly.

> Also, this
> does not identify specifically a soap fast infoset entity, merely a
> generic fast infoset entity, so this whole section should probably just
> reference the next registration unless there is a way to reliably
> identify those fast infosets used in SOAP.
>

Referencing the generic MIME type is a good idea.

After successful identification of a fast infoset document one would 
have to look at the properties of the root element information by 
parsing the document (the same applies to soap+xml) and checking it 
conforms to the SOAP Envelope element information item [4]. I should 
recheck the SOAP 1.2 MIME type to see what it says.

> I'm a little worried about 'bytes' as opposed to 'octets': what's the
> IETF position on this? 'octets' is definitely less ambiguous.
>

I will change to use 'octets', making it consistent with what is used in 
the normative parts of the Fast Infoset specification.

> 
>>MIME media type name:
>>application
>>
>>MIME subtype name:
>>fastinfoset
> 
> 
> Is it worth registering two separate types, 'application/fastinfoset'
> and 'application/fastinfoset+xml' for fast infosets that are not and are
> encoded as XML documents, respectively?
>

The latter would not make any sense. A fast infoset document and an XML 
document are two distinct serializations of an XML infoset. The infoset 
may have been produced by parsing an XML document, a fast infoset 
document, or by other means (a synthetic infoset). An infoset produced 
by parsing a fast infoset document may be serialized to an XML document. 
So it is possible to convert between fast infoset documents and XML 
documents and round trip an infoset (and also the serializations if 
using canonical forms). Thus 'application/fastinfoset+xml' would be 
equivalent to 'text/xml'.

Paul.

[1] http://www.ietf.org/internet-drafts/draft-freed-media-type-reg-01.txt
[2] http://rfc.net/rfc2048.html
[3] http://rfc.net/rfc3023.html
[4] http://www.w3.org/TR/soap12-part1/#soapenvelope

-- 
| ? + ? = To question
----------------\
    Paul Sandoz
         x38109
+33-4-76188109

From: duerst at w3.org (Martin Duerst)
Date: Tue Jan  3 16:22:52 2006
Subject: MIME Type Review Request: image/svg+xml
In-Reply-To: <[email-masked]>
References: <[email-masked]>
Message-ID: <6.0.0.20.2.20041119083958.085ea200@localhost>

Sorry this is late. Here are some comments on this registration:

- Some of the ideas discussed at
   http://eikenes.alvestrand.no/pipermail/ietf-types/2004-July/000298.html
   might help improve the specification.

- The text below was produced by using an HTML-to-text conversion.
   Ideally, it should be possible to use the registration template
   directly as plain text, i.e. the most important URIs should
   appear in plain text.

- On the other hand, there is no need to provide URIs for RFCs.
   Something like "... [6]RFC3023 ..."
       [6] http://www.w3.org/TR/SVG12/references
   in an IETF context, is quite confusing.

- "Published specification:
          This media type registration is extracted from Appendix G of
          the SVG 1.2 specification."
   This sounds like it's the wrong way round. "Published specification"
   doesn't mean the specification of the registration template, but
   the specification of the format. This is in many ways the most important
   part of the mime registration. It tells a reader "if you get something
   of type image/svg+xml, here is the spec that tells you how to interprete
   that media type".
   Saying that the media type registration itself is in Appendix G
   is additional information worth mentioning, but much less important.

- Last but not least, I agree with comments already made in this venue
   that this media type should allow the 'charset' parameter as defined
   in RFC 3023. As argued in detail at
   http://lists.w3.org/Archives/Public/www-tag/2004Nov/0034.html,
   I do not see any way to justify removing the 'charset' parameter
   based on 'good practice' advice in the Web Architecture document
   (http://www.w3.org/TR/2004/PR-webarch-20041105/#no-charset).
   (Boris Zbarsky made essentially the same argument, but much shorter.)
   Continuing to allow the 'charset' parameter (or in this case, putting
   it back in) will make it easier to use generic tools (both on the
   producer side (databases, java servlets,...) and on the client side
   (xml editors, validators,...), which is one of the main advantages
   of +xml.

Regards,    Martin.

At 01:22 04/11/03, Chris Lilley wrote:
 >
 >
 >Please review the Media Type registration template described below. It
 >is available in HTML [1] or in plain text form [2] and relates to the
 >SVG specification [3]. Registration of this Media Type in the standards
 >tree is requested, in conformance with [4] and [5].
 >
 >      [1] http://www.w3.org/TR/SVG12/mimereg.html
 >      [2] http://www.w3.org/TR/SVG12/mimereg.html,text
 >      [3] http://www.w3.org/TR/SVG12/
 >      [4] http://www.ietf.org/internet-drafts/draft-freed-media-type-reg-01.txt
 >      [5] http://www.w3.org/2002/06/registering-mediatype
 >
 >
 >Registration of Media Type image/svg+xml
 >
 >   MIME media type name:
 >          image
 >
 >   MIME subtype name:
 >          svg+xml
 >
 >   Required parameters:
 >          None.
 >
 >   Optional parameters:
 >          None
 >
 >          The encoding of an SVG document is determined by the XML
 >          encoding declaration. This has identical semantics to the
 >          application/xml media type in the case where the charset
 >          parameter is omitted, as specified in [6]RFC3023 sections 8.9,
 >          8.10 and 8.11.
 >
 >      [6] http://www.w3.org/TR/SVG12/references
 >
 >   Encoding considerations:
 >          Same as for application/xml. See [7]RFC3023 , section 3.2.
 >
 >      [7] http://www.w3.org/TR/SVG12/references
 >
 >   Restrictions on usage:
 >          None
 >
 >   Security considerations:
 >          As with other XML types and as noted in [8]RFC3023 section 10,
 >          repeated expansion of maliciously constructed XML entities can
 >          be used to consume large amounts of memory, which may cause XML
 >          processors in constrained environments to fail.
 >
 >      [8] http://www.w3.org/TR/SVG12/references
 >
 >          SVG documents may be transmitted in compressed form using gzip
 >          compression. For systems which employ MIME-like mechanisms,
 >          such as HTTP, this is indicated by the
 >          Content-Transfer-Encoding header; for systems which do not,
 >          such as direct filesystem access, this is indicated by the
 >          filename extension and by the Macintosh File Type Codes. In
 >          addition, gzip compressed content is readily recognised by the
 >          initial byte sequence as described in [9]RFC1952 section 2.3.1.
 >
 >      [9] http://www.w3.org/TR/SVG12/references
 >
 >          Several SVG elements may cause arbitrary URIs to be referenced.
 >          In this case, the security issues of [10]RFC2396, section 7,
 >          should be considered.
 >
 >     [10] http://www.w3.org/TR/SVG12/references
 >
 >          In common with HTML, SVG documents may reference external media
 >          such as images, audio, video, style sheets, and scripting
 >          languages. Scripting languages are executable content. In this
 >          case, the security considerations in the Media Type
 >          registrations for those formats apply.
 >
 >          In addition, because of the extensibility features for SVG and
 >          of XML in general, it is possible that "image/svg+xml" may
 >          describe content that has security implications beyond those
 >          described here. However, if the processor follows only the
 >          normative semantics of this specification, this content will be
 >          outside the SVG namespace and will be ignored. Only in the case
 >          where the processor recognizes and processes the additional
 >          content, or where further processing of that content is
 >          dispatched to other processors, would security issues
 >          potentially arise. And in that case, they would fall outside
 >          the domain of this registration document.
 >
 >   Interoperability considerations:
 >          This specification describes processing semantics that dictate
 >          behavior that must be followed when dealing with, among other
 >          things, unrecognized elements and attributes, both in the SVG
 >          namespace and in other namespaces.
 >
 >          Because SVG is extensible, conformant "image/svg+xml"
 >          processors must expect that content received is well-formed
 >          XML, but it cannot be guaranteed that the content is valid to a
 >          particular DTD or Schema or that the processor will recognize
 >          all of the elements and attributes in the document.
 >
 >          SVG has a published Test Suite and associated implementation
 >          report showing which implementations passed which tests at the
 >          time of the report. This information is periodically updated as
 >          new tests are added or as implementations improve.
 >
 >   Published specification:
 >          This media type registration is extracted from Appendix G of
 >          the SVG 1.2 specification.
 >
 >   Additional information:
 >
 >   Person & email address to contact for further information:
 >          Dean Jackson, ([email-masked]).
 >
 >   Intended usage:
 >          COMMON
 >
 >   Author/Change controller:
 >          The SVG specification is a work product of the World Wide Web
 >          Consortium's SVG Working Group. The W3C has change control over
 >          these specifications.
 >
 >--
 > Chris Lilley                    mailto:[email-masked]
 > Chair, W3C SVG Working Group
 > Member, W3C Technical Architecture Group 

From: mankin at psg.com (Allison Mankin)
Date: Thu Nov 18 23:09:44 2004
Subject: Review of update of text/t140
Message-ID: <[email-masked]>

The IESG has received a request for publication of 
draft-ietf-avt-rfc2793bis-09.txt, which includes updating the
registration of text/t140.  This a minor update, primarily to
include an optional parameter, cps.  Please consider giving
a review of the update, in parallel with the IETF Last Call.

Thanks,

Allison
>From [email-masked]  Fri Nov 19 01:08:27 2004
From: duerst at w3.org (Martin Duerst)
Date: Fri Nov 19 01:21:07 2004
Subject: MIME Type Review Request: image/svg+xml
In-Reply-To: <[email-masked]>
References: <[email-masked]>
Message-ID: <6.0.0.20.2.20041119083958.085ea200@localhost>

Sorry this is late. Here are some comments on this registration:

- Some of the ideas discussed at
   http://eikenes.alvestrand.no/pipermail/ietf-types/2004-July/000298.html
   might help improve the specification.

- The text below was produced by using an HTML-to-text conversion.
   Ideally, it should be possible to use the registration template
   directly as plain text, i.e. the most important URIs should
   appear in plain text.

- On the other hand, there is no need to provide URIs for RFCs.
   Something like "... [6]RFC3023 ..."
       [6] http://www.w3.org/TR/SVG12/references
   in an IETF context, is quite confusing.

- "Published specification:
          This media type registration is extracted from Appendix G of
          the SVG 1.2 specification."
   This sounds like it's the wrong way round. "Published specification"
   doesn't mean the specification of the registration template, but
   the specification of the format. This is in many ways the most important
   part of the mime registration. It tells a reader "if you get something
   of type image/svg+xml, here is the spec that tells you how to interprete
   that media type".
   Saying that the media type registration itself is in Appendix G
   is additional information worth mentioning, but much less important.

- Last but not least, I agree with comments already made in this venue
   that this media type should allow the 'charset' parameter as defined
   in RFC 3023. As argued in detail at
   http://lists.w3.org/Archives/Public/www-tag/2004Nov/0034.html,
   I do not see any way to justify removing the 'charset' parameter
   based on 'good practice' advice in the Web Architecture document
   (http://www.w3.org/TR/2004/PR-webarch-20041105/#no-charset).
   (Boris Zbarsky made essentially the same argument, but much shorter.)
   Continuing to allow the 'charset' parameter (or in this case, putting
   it back in) will make it easier to use generic tools (both on the
   producer side (databases, java servlets,...) and on the client side
   (xml editors, validators,...), which is one of the main advantages
   of +xml.

Regards,    Martin.

At 01:22 04/11/03, Chris Lilley wrote:
 >
 >
 >Please review the Media Type registration template described below. It
 >is available in HTML [1] or in plain text form [2] and relates to the
 >SVG specification [3]. Registration of this Media Type in the standards
 >tree is requested, in conformance with [4] and [5].
 >
 >      [1] http://www.w3.org/TR/SVG12/mimereg.html
 >      [2] http://www.w3.org/TR/SVG12/mimereg.html,text
 >      [3] http://www.w3.org/TR/SVG12/
 >      [4] http://www.ietf.org/internet-drafts/draft-freed-media-type-reg-01.txt
 >      [5] http://www.w3.org/2002/06/registering-mediatype
 >
 >
 >Registration of Media Type image/svg+xml
 >
 >   MIME media type name:
 >          image
 >
 >   MIME subtype name:
 >          svg+xml
 >
 >   Required parameters:
 >          None.
 >
 >   Optional parameters:
 >          None
 >
 >          The encoding of an SVG document is determined by the XML
 >          encoding declaration. This has identical semantics to the
 >          application/xml media type in the case where the charset
 >          parameter is omitted, as specified in [6]RFC3023 sections 8.9,
 >          8.10 and 8.11.
 >
 >      [6] http://www.w3.org/TR/SVG12/references
 >
 >   Encoding considerations:
 >          Same as for application/xml. See [7]RFC3023 , section 3.2.
 >
 >      [7] http://www.w3.org/TR/SVG12/references
 >
 >   Restrictions on usage:
 >          None
 >
 >   Security considerations:
 >          As with other XML types and as noted in [8]RFC3023 section 10,
 >          repeated expansion of maliciously constructed XML entities can
 >          be used to consume large amounts of memory, which may cause XML
 >          processors in constrained environments to fail.
 >
 >      [8] http://www.w3.org/TR/SVG12/references
 >
 >          SVG documents may be transmitted in compressed form using gzip
 >          compression. For systems which employ MIME-like mechanisms,
 >          such as HTTP, this is indicated by the
 >          Content-Transfer-Encoding header; for systems which do not,
 >          such as direct filesystem access, this is indicated by the
 >          filename extension and by the Macintosh File Type Codes. In
 >          addition, gzip compressed content is readily recognised by the
 >          initial byte sequence as described in [9]RFC1952 section 2.3.1.
 >
 >      [9] http://www.w3.org/TR/SVG12/references
 >
 >          Several SVG elements may cause arbitrary URIs to be referenced.
 >          In this case, the security issues of [10]RFC2396, section 7,
 >          should be considered.
 >
 >     [10] http://www.w3.org/TR/SVG12/references
 >
 >          In common with HTML, SVG documents may reference external media
 >          such as images, audio, video, style sheets, and scripting
 >          languages. Scripting languages are executable content. In this
 >          case, the security considerations in the Media Type
 >          registrations for those formats apply.
 >
 >          In addition, because of the extensibility features for SVG and
 >          of XML in general, it is possible that "image/svg+xml" may
 >          describe content that has security implications beyond those
 >          described here. However, if the processor follows only the
 >          normative semantics of this specification, this content will be
 >          outside the SVG namespace and will be ignored. Only in the case
 >          where the processor recognizes and processes the additional
 >          content, or where further processing of that content is
 >          dispatched to other processors, would security issues
 >          potentially arise. And in that case, they would fall outside
 >          the domain of this registration document.
 >
 >   Interoperability considerations:
 >          This specification describes processing semantics that dictate
 >          behavior that must be followed when dealing with, among other
 >          things, unrecognized elements and attributes, both in the SVG
 >          namespace and in other namespaces.
 >
 >          Because SVG is extensible, conformant "image/svg+xml"
 >          processors must expect that content received is well-formed
 >          XML, but it cannot be guaranteed that the content is valid to a
 >          particular DTD or Schema or that the processor will recognize
 >          all of the elements and attributes in the document.
 >
 >          SVG has a published Test Suite and associated implementation
 >          report showing which implementations passed which tests at the
 >          time of the report. This information is periodically updated as
 >          new tests are added or as implementations improve.
 >
 >   Published specification:
 >          This media type registration is extracted from Appendix G of
 >          the SVG 1.2 specification.
 >
 >   Additional information:
 >
 >   Person & email address to contact for further information:
 >          Dean Jackson, ([email-masked]).
 >
 >   Intended usage:
 >          COMMON
 >
 >   Author/Change controller:
 >          The SVG specification is a work product of the World Wide Web
 >          Consortium's SVG Working Group. The W3C has change control over
 >          these specifications.
 >
 >--
 > Chris Lilley                    mailto:[email-masked]
 > Chair, W3C SVG Working Group
 > Member, W3C Technical Architecture Group 

From: mankin at psg.com (Allison Mankin)
Date: Tue Jan  3 16:22:52 2006
Subject: Review of update of text/t140
Message-ID: <[email-masked]>

The IESG has received a request for publication of 
draft-ietf-avt-rfc2793bis-09.txt, which includes updating the
registration of text/t140.  This a minor update, primarily to
include an optional parameter, cps.  Please consider giving
a review of the update, in parallel with the IETF Last Call.

Thanks,

Allison

From: claus at xn--frber-gra.muc.de (=?ISO-8859-1?Q?Claus_F=E4rber?=)
Date: Thu Nov 18 13:10:26 2004
Subject: MIME types for preliminary community review
References: <[email-masked]> <[email-masked]> <[email-masked]>
Message-ID: <[email-masked]>

Chris Lilley <[email-masked]> schrieb/wrote:
> For the first of those yes as its a file format; for the second, no -
> remember the attempt at application/gzip and then the introduction of
> Content-Encoding. Something which is gzipped should indicate its
> actual media type, and use Content-Encoding to indicate that it is
> gzipped.

What if you don't have a Content-Encoding header, for example if you use  
MIME instead of HTTP?

Claus
-- 
http://www.faerber.muc.de

From: claus at xn--frber-gra.muc.de (=?ISO-8859-1?Q?Claus_F=E4rber?=)
Date: Tue Jan  3 16:22:51 2006
Subject: MIME types for preliminary community review
References: <[email-masked]> <[email-masked]> <[email-masked]>
Message-ID: <[email-masked]>

Chris Lilley <[email-masked]> schrieb/wrote:
> For the first of those yes as its a file format; for the second, no -
> remember the attempt at application/gzip and then the introduction of
> Content-Encoding. Something which is gzipped should indicate its
> actual media type, and use Content-Encoding to indicate that it is
> gzipped.

What if you don't have a Content-Encoding header, for example if you use  
MIME instead of HTTP?

Claus
-- 
http://www.faerber.muc.de

From: chris at w3.org (Chris Lilley)
Date: Tue Jan  3 16:22:51 2006
Subject: MIME types for preliminary community review
In-Reply-To: <[email-masked]>
References: <[email-masked]> <[email-masked]>
Message-ID: <[email-masked]>

On Wednesday, November 17, 2004, 6:24:17 PM, Ben wrote:

BM> [...] (I can think of at least two other uses for this
BM> convention: '+zip' for formats which are a zip file with a specific
BM> layout, such as JAR, Perl's PAR, mozilla.org's XPI and Quake's pk3; and
BM> '+gzip'/'+bzip2' to denote a gzip compressed version of a format), but
BM> it would need proper discussion and specification.

For the first of those yes as its a file format; for the second, no -
remember the attempt at application/gzip and then the introduction of
Content-Encoding. Something which is gzipped should indicate its actual
media type, and use Content-Encoding to indicate that it is gzipped.

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

From: eburger at brooktrout.com (Eric Burger)
Date: Tue Jan  3 16:22:53 2006
Subject: MIME Type Review for KPML MIME Types
Message-ID: <[email-masked]>

KPML is in the process of WGLC in the SIPPING work group.

KPML defines two new MIME types, application/kpml-request+xml and
application/kpml-response+xml .

We would greatly appreciate expert review of the definition and usage of
these new types.

The draft lives at:
http://www.ietf.org/internet-drafts/draft-ietf-sipping-kpml-06.txt

Thanks.

--
Eric Burger

From: magnus.westerlund at ericsson.com (Magnus Westerlund)
Date: Mon Nov 15 16:11:40 2004
Subject: Updated MIME type proposal for 3GPP DRM RTP payload format
Message-ID: <[email-masked]>

Hi,

Based on some of the feedback received on this list, I have included a 
proposal for an updated MIME type definition for 3GPP TS 26.234 Annex K. 
I have not defined a procedure for defining a single media type 
(application) and then secondary used media types that are indicated in 
SDP. The reason is that I think it makes it more difficult to find these 
in the registry. Also being the first doing this in a non IETF document 
seems to be problematic. Also having a lot of discussion and changing 
things for a basically approved specification is difficult. I think that 
3GPP can suffice using the so far done IETF procedures.

Changes done:

- Renamed sub type name: rtp.enc.aescm128 to rtp-enc-aescm128

- Removed media type "image" and "application"

Any feedback is desired as quickly as possible. The 3GPP SA4 which owns 
this specification will meet next week, and any feedback received before 
next Wednesday will be much simpler to incorporate. Sorry for the short 
heads up.

Thanks

Magnus

---- START OF MEDIA TYPE ----

MIME media type name: audio, video, text

MIME subtype name: rtp-enc-aescm128

Required parameters:

   opt: 	The payload type number of the payload type contained in
	the encrypted payload. An integer value between 0-127.

   rate: The timestamp rate of this payload type, which shall be
	the same as that of the original payload type. This is an
	integer value between 1 and 2^32.

   ContentID: The OMA DRM content ID [75] used to identify the
	content when establishing a crypto context. The value is an RFC
	2396 [60] URI, which shall be quoted using <">.

   RightsIssuerURL: The right issuer URL as defined by OMA
	DRM [75]. The value is an URI in accordance with RFC 2396 [60],
	which shall be quoted using <">.

   IVnonce: The value of this parameter is the nonce
	that forms the IV as specified by the crypto transform, encoded
	using Base 64 [69].

Optional parameters:

   SelectiveEncryption: Indicates if this stream is selectively
	encrypted. Allowed values are 0 (false) and 1 (true). If not
	present, selective encryption shall not be used. Please note
	that unless this indicator is integrity protected, it fulfils no
	purpose.

Encoding considerations:

	This type is only defined for transfer via RTP (RFC 3550).

Security considerations:

See considerations raised in RTP RFC 3550 [9] and any applicable profile
like RFC 3551 [10] or RFC 3711 [72]. Further see 3GPP TS 26.234, Release
6, Annex K for comments on security issues. The main issues that exists
are:

    - This RTP payload format only confidentiality protects the RTP
      payload, thus header information is leaked, similarly to SRTP.

    - The use of stream ciphers as AES CM and no integrity protection
      allows an attacker to purposefully attack the content of the
      encrypted RTP payload by switching individual bits.

    - The usage of selective encryption without integrity protection
      allows for an attacker to perform any replacements of complete RTP
      payloads and packets it desires. -	The payload format makes the
      receiver vulnerable to denial of service attacks that inserts RTP
      packets into the stream, that the receiver then interprets as being
      encrypted thus wasting computational resources. To prevent this
      attack, authentication needs to be used.

Interoperability considerations:

Published specification:

3GPP TS 26.234, Release 6.
Open Mobile Alliance DRM Content Format V2.0

Applications which use this media type:

Third Generation Partnership Project (3GPP) Packet-switched Streaming
Service (PSS) clients and servers, which supports the Open Mobile
Alliance's specification of Digital Rights Management version 2.0.

Additional information:

Magic number(s): N/A

File extension(s): N/A

Macintosh File Type Code(s): N/A

Person & email address to contact for further information:
[email-masked]

Intended usage: Common

Author/Change controller:

3GPP TSG SA

---- END OF MEDIA TYPE ----

Cheers

Magnus Westerlund

Multimedia Technologies, Ericsson Research EAB/TVA/A
----------------------------------------------------------------------
Ericsson AB                | Phone +46 8 4048287
Torshamsgatan 23           | Fax   +46 8 7575550
S-164 80 Stockholm, Sweden | mailto: [email-masked]

From: magnus.westerlund at ericsson.com (Magnus Westerlund)
Date: Tue Jan  3 16:22:51 2006
Subject: Updated MIME type proposal for 3GPP DRM RTP payload format
Message-ID: <[email-masked]>

Hi,

Based on some of the feedback received on this list, I have included a 
proposal for an updated MIME type definition for 3GPP TS 26.234 Annex K. 
I have not defined a procedure for defining a single media type 
(application) and then secondary used media types that are indicated in 
SDP. The reason is that I think it makes it more difficult to find these 
in the registry. Also being the first doing this in a non IETF document 
seems to be problematic. Also having a lot of discussion and changing 
things for a basically approved specification is difficult. I think that 
3GPP can suffice using the so far done IETF procedures.

Changes done:

- Renamed sub type name: rtp.enc.aescm128 to rtp-enc-aescm128

- Removed media type "image" and "application"

Any feedback is desired as quickly as possible. The 3GPP SA4 which owns 
this specification will meet next week, and any feedback received before 
next Wednesday will be much simpler to incorporate. Sorry for the short 
heads up.

Thanks

Magnus

---- START OF MEDIA TYPE ----

MIME media type name: audio, video, text

MIME subtype name: rtp-enc-aescm128

Required parameters:

   opt: 	The payload type number of the payload type contained in
	the encrypted payload. An integer value between 0-127.

   rate: The timestamp rate of this payload type, which shall be
	the same as that of the original payload type. This is an
	integer value between 1 and 2^32.

   ContentID: The OMA DRM content ID [75] used to identify the
	content when establishing a crypto context. The value is an RFC
	2396 [60] URI, which shall be quoted using <">.

   RightsIssuerURL: The right issuer URL as defined by OMA
	DRM [75]. The value is an URI in accordance with RFC 2396 [60],
	which shall be quoted using <">.

   IVnonce: The value of this parameter is the nonce
	that forms the IV as specified by the crypto transform, encoded
	using Base 64 [69].

Optional parameters:

   SelectiveEncryption: Indicates if this stream is selectively
	encrypted. Allowed values are 0 (false) and 1 (true). If not
	present, selective encryption shall not be used. Please note
	that unless this indicator is integrity protected, it fulfils no
	purpose.

Encoding considerations:

	This type is only defined for transfer via RTP (RFC 3550).

Security considerations:

See considerations raised in RTP RFC 3550 [9] and any applicable profile
like RFC 3551 [10] or RFC 3711 [72]. Further see 3GPP TS 26.234, Release
6, Annex K for comments on security issues. The main issues that exists
are:

    - This RTP payload format only confidentiality protects the RTP
      payload, thus header information is leaked, similarly to SRTP.

    - The use of stream ciphers as AES CM and no integrity protection
      allows an attacker to purposefully attack the content of the
      encrypted RTP payload by switching individual bits.

    - The usage of selective encryption without integrity protection
      allows for an attacker to perform any replacements of complete RTP
      payloads and packets it desires. -	The payload format makes the
      receiver vulnerable to denial of service attacks that inserts RTP
      packets into the stream, that the receiver then interprets as being
      encrypted thus wasting computational resources. To prevent this
      attack, authentication needs to be used.

Interoperability considerations:

Published specification:

3GPP TS 26.234, Release 6.
Open Mobile Alliance DRM Content Format V2.0

Applications which use this media type:

Third Generation Partnership Project (3GPP) Packet-switched Streaming
Service (PSS) clients and servers, which supports the Open Mobile
Alliance's specification of Digital Rights Management version 2.0.

Additional information:

Magic number(s): N/A

File extension(s): N/A

Macintosh File Type Code(s): N/A

Person & email address to contact for further information:
[email-masked]

Intended usage: Common

Author/Change controller:

3GPP TSG SA

---- END OF MEDIA TYPE ----

Cheers

Magnus Westerlund

Multimedia Technologies, Ericsson Research EAB/TVA/A
----------------------------------------------------------------------
Ericsson AB                | Phone +46 8 4048287
Torshamsgatan 23           | Fax   +46 8 7575550
S-164 80 Stockholm, Sweden | mailto: [email-masked]

From: onno at ecma-international.org (Onno Elzinga)
Date: Wed Nov 17 08:39:38 2004
Subject: MIME Type Review Request: text/CSTA-type
Message-ID: <[email-masked]>

Dear reviewers,

Thanks for your constructive feedback.

Task Group 11 has reviewed your comments and agrees that both MIME types are meant for machines. Therefore they propose to change the second MIME type from "text/CSTA-types" to "application/CSTAdata+xml".

Hope this helps. 
We are meeting all week, so we would appreciate your speedy feedback.

Thanks,
Onno.

-----Original Message-----
From: Bruce Lilly [mailto:[email-masked]]
Sent: Saturday, November 06, 2004 6:22 PM
To: [email-masked]
Cc: Onno Elzinga; [email-masked]'; [email-masked]';
Hollenbeck, Scott
Subject: Re: MIME Type Review Request: text/CSTA-type

On Tue November 2 2004 08:54, Hollenbeck, Scott wrote:
> Please review the MIME type registration template described below.  The IESG
> has received a request to register this MIME type in the standards tree.  It
> is a product of Ecma International.  A URL for the formal specification is
> included in the template.
> 
> -Scott-
> ----------
> MIME media type name: text
> 
> MIME subtype name: CSTA-type
[...]
> Security considerations:
> This content type is designed to carry CSTA data types over network
> protocols. Appropriate precautions should be taken to insure that
> applications observing these CSTA objects are authorized to do so.
[...]
> Applications which use this media type:
> The text/CSTA-type MIME type is used to carry CSTA data types specified in
> CSTA XML (ECMA-323) over various types of network protocols.
> 
> Additional information:
> CSTA XML (ECMA-323) is an application level protocol that enables an
> application to control and observe communications involving various types of
> media (voice calls, video calls, instant messages, Email, SMS, Page, etc.)
> and devices associated with the media.

Why is this being proposed for registration in the text media type tree?
As far as I can tell, this media type appears to be an application data
format containing control data, not textual information (in the sense
of the use of "text" in the MIME standards (RFC 2046) and Internet
Best Current Practice (RFC 2277):

RFC 2046:
   The five discrete top-level media types are:

    (1)   text -- textual information.  The subtype "plain" in
          particular indicates plain text containing no
          formatting commands or directives of any sort. Plain
          text is intended to be displayed "as-is". No special
          software is required to get the full meaning of the
          text, aside from support for the indicated character
          set. Other subtypes are to be used for enriched text in
          forms where application software may enhance the
          appearance of the text, but such software must not be
          required in order to get the general idea of the
          content.  Possible subtypes of "text" thus include any
          word processor format that can be read without
          resorting to software that understands the format.  In
          particular, formats that employ embeddded binary
          formatting information are not considered directly
          readable. A very simple and portable subtype,
          "richtext", was defined in RFC 1341, with a further
          revision in RFC 1896 under the name "enriched".

RFC 2277:

   All human-readable text has a language.

   Many operations, including high quality formatting, text-to-speech
   synthesis, searching, hyphenation, spellchecking and so on benefit
   greatly from access to information about the language of a piece of
   text. [WC 3.1.1.4].

   Humans have some tolerance for foreign languages, but are generally
   very unhappy with being presented text in a language they do not
   understand; this is why negotiation of language is needed.

   In most cases, machines will not be able to deduce the language of a
   transmitted text by themselves; the protocol must specify how to
   transfer the language information if it is to be available at all.

   The interaction between language and processing is complex; for
   instance, if I compare "name-of-thing(lang=en)" to "name-of-
   thing(lang=no)" for equality, I will generally expect a match, while
   the word "ask(no)" is a kind of tree, and is hardly useful as a
   command verb.

 4.2.  Requirement for language tagging

   Protocols that transfer text MUST provide for carrying information
   about the language of that text.

Buried in an Annex in the 530-page referenced ECMA document one finds:

This annex specifies a schema for CSTA data types that can be used to encapulatate CSTA data objects so that they can be carried over various types of network protocols such as SIP. A specific MIME media type, text/CSTA-type is designed to contain these data objects. The formats of the data types are specified in Clause 9.

I can see nothing in the proposed media type registration or in the
referenced document that indicates that the media type is to be
used to convey human-readable natural language text as
opposed to application-specific data type, nor do I see any provision
for carrying information about language of text as required by
RFC 2277.

A concrete example of how the proposed media type would be
used to convey human-readable text in some specified language
would help to provide justification for registration of the
proposed subtype in the text media type tree.
>From [email-masked]  Thu Nov 11 21:15:58 2004
From: Paul.Sandoz at Sun.COM (Paul Sandoz)
Date: Wed Nov 17 08:39:41 2004
Subject: MIME types for preliminary community review
Message-ID: <[email-masked]>

Hi,

Attached are three MIME types for prelimiary community review before 
registration. Any feedback would be most welcome.

I understand the new 'Media Type Specifications and Registration 
Procedures' [1], which obsoletes RFC 2048, is in effect even though no 
new RFC number has been assigned.

The MIME types are specified in the following:

ITU-T Rec. X.891 | ISO/IEC 24824-1 (Fast Infoset) [2]
ITU-T Rec. X.892 | ISO/IEC 24824-2 (Fast Web Services) [3]

both of which are Final Committee Drafts under ballot in ISO. The ballot 
finishes on the 1st Feb 2005.

If there are any changes required as a result of review then i can 
incorporate these into an ISO ballot comment.

I plan to sumbit the MIME types to IANA ([email-masked]) in about 2 weeks 
time.

Thanks,
Paul.

[1] http://www.ietf.org/internet-drafts/draft-freed-media-type-reg-01.txt
[2] 
http://www.iso.org/iso/en/CatalogueDetailPage.CatalogueDetail?CSNUMBER=41327&scopelist=PROGRAMME
[3] 
http://www.iso.org/iso/en/CatalogueDetailPage.CatalogueDetail?CSNUMBER=41328&scopelist=PROGRAMME

-- 
| ? + ? = To question
----------------\
    Paul Sandoz
         x38109
+33-4-76188109

-------------- next part --------------
MIME media type name:
application

MIME subtype name:
soap+fastinfoset

Required parameters:
None.

Optional parameters:
"action": This parameter shall be used to identify the intent of the W3C SOAP 
message infoset as specified for the "action" parameter of the W3C SOAP 1.2 
"application/soap+xml" MIME media type (see W3C SOAP 1.2 Part 2, Appendix A). The 
value of the "action" parameter shall be an absolute URI-reference as specified in 
IETF RFC 2396. No restriction shall be placed on the specificity of the URI or that 
it is resolvable.

Encoding considerations:
This media type is used to identify W3C SOAP message infosets serialized as fast 
infoset documents as specified in ITU-T Rec. X.892 | ISO/IEC 24824-2.

Use of this MIME media type will require additional specification if used on 
transports that do not provide 8-bit binary transparency.  (For the purposes of 
Fast Web Services, ITU-T Rec. X.892 | ISO/IEC 24824-2, this media type is always 
used with HTTP as the transport mechanism, and no further specification is needed.)

Security considerations:
Because W3C SOAP message infosets can carry application defined data whose 
semantics is independent from that of any MIME wrapper (or context within which the 
MIME wrapper is used), one should not expect to be able to understand the semantics 
of the W3C SOAP message infoset based on the semantics of the MIME wrapper alone. 
Therefore, whenever using the "application/soap+fastinfoset" media type, it is 
strongly recommended that the security implications of the context within which the 
W3C SOAP message infoset is used is fully understood. The security implications are 
likely to involve the specific SOAP binding to an underlying protocol as well as 
the application-defined semantics of the data carried in the W3C SOAP message 
infoset.

Interoperability considerations:
There are no known interoperability issues.

Published specification:
ITU-T Rec. X.892 | ISO/IEC 24824-2
  
Applications which use this media type:
No known applications that use this media type.

Additional information:
Magic number(s):
A W3C SOAP message infoset serialized as a fast infoset document may begin 
with one of the following byte sequences:

- a byte sequence that corresponds to a UTF-8 encoded XML declaration of the 
string "<?xml version='1.0' encoding='finf'", the first five bytes of which 
are hexadecimal 3C 3F 78 6D 6C;

- a byte sequence that corresponds to a UTF-8 encoded XML declaration of the 
string "<?xml version='1.1' encoding='finf'", the first five bytes of which 
are also hexadecimal 3C 3F 78 6D 6C;

- a byte sequence of hexadecimal E0 00 00 01.

File extension(s):
W3C SOAP message infosets serialized as fast infoset documents are not 
required or expected to be stored as files.

Person & email address to contact for further information:
ITU-T ASN.1 Rapporteur (contact via [email-masked])
ISO/IEC JTC1/SC6 ASN.1 Rapporteur (contact via [email-masked])

Intended usage:
COMMON

Author/Change controller:
Joint ITU-T | ISO/IEC balloting procedures in accordance with ITU-T Rec. A.23 
Collaboration with the International Organization for Standardization (ISO) and the 
International Electrotechnical Commission (IEC) on information technology, Annex A 
and ISO/IEC JTC1 Directives, Annex K.
-------------- next part --------------
MIME media type name:
application

MIME subtype name:
fastinfoset

Required parameters:
None.

Optional parameters:
None.

Encoding considerations:
XML infosets encoded as fast infoset documents will result in the production of 
binary data. This MIME media type may require further encoding on transports not 
capable of handling binary data.

Security considerations:
Because XML infosets encoded as fast infoset documents can carry application 
defined data whose semantics is independent from that of any MIME wrapper (or 
context within which the MIME wrapper is used), one should not expect to be able to 
understand the semantics of the fast infoset document based on the semantics of the 
MIME wrapper alone. Therefore, whenever using the "application/fastinfoset" media 
type, it is strongly recommended that the security implications of the context 
within which the fast infoset document is used is fully understood.

Interoperability considerations:
There are no known interoperability issues.

Published specification:
ITU-T Rec. X.891 | ISO/IEC 24824-1
  
Applications which use this media type:
No known applications currently use this media type.

Additional information:

Magic number(s):
A fast infoset document may begin with one of the following byte sequences:

- a byte sequence that corresponds to a UTF-8 encoded XML declaration of the 
string "<?xml version='1.0' encoding='finf'", the first five bytes of which 
are hexadecimal 3C 3F 78 6D 6C;

- a byte sequence that corresponds to a UTF-8 encoded XML declaration of the 
string "<?xml version='1.1' encoding='finf'", the first five bytes of which 
are also hexadecimal 3C 3F 78 6D 6C;

- a byte sequence of hexadecimal E0 00 00 01.

File extension(s):
*.finf

Person & email address to contact for further information:
ITU-T ASN.1 Rapporteur (contact via [email-masked])
ISO/IEC JTC1/SC6 ASN.1 Rapporteur (contact via [email-masked])

Intended usage:
COMMON

Author/Change controller:
Joint ITU-T | ISO/IEC balloting procedures in accordance with ITU-T Rec. A.23 
Collaboration with the International Organization for Standardization (ISO) and the 
International Electrotechnical Commission (IEC) on information technology, Annex A 
and ISO/IEC JTC1 Directives, Annex K.
-------------- next part --------------
MIME media type name:
application

MIME subtype name:
fastsoap

Required parameters:
None.

Optional parameters:
"action": This parameter shall be used to identify the intent of the ASN.1 SOAP 
message as specified for the "action" parameter of the W3C SOAP 1.2 
"application/soap+xml" MIME media type (see W3C SOAP 1.2 Part 2, Appendix A). The 
value of the "action" parameter shall be an absolute URI-reference as specified in 
IETF RFC 2396. No restriction shall be placed on the specificity of the URI or that 
it is resolvable.

Encoding considerations:
This media type is used to identify content that is a value of the ASN.1 Envelope 
type specified in the ASN1SOAP module of ITU-T Rec. X.892 | ISO/IEC 24824-2, 
encoded using Basic Aligned Packed Encoding Rule specified in ITU-T Rec. X.691 | 
ISO/IEC 8825-2.

Use of this MIME media type will require additional specification if used on 
transports that do not provide 8-bit binary transparency.  (For the purposes of 
Fast Web Services, ITU-T Rec. X.892 | ISO/IEC 24824-2, this media type is always 
used with the Basic Aligned Packed Encoding Rule and with HTTP as the transport 
mechanism, and no further specification is needed.)

Security considerations:
Because ASN.1 SOAP messages can carry application-defined data whose semantics is 
independent from that of any MIME wrapper (or context within which the MIME wrapper 
is used), one should not expect to be able to understand the semantics of the ASN.1 
SOAP message based on the semantics of the MIME wrapper alone. Therefore, whenever 
using the "application/fastsoap" media type, it is strongly recommended that the 
security implications of the context within which the ASN.1 SOAP message is used is 
fully understood. The security implications are likely to involve the specific 
ASN.1 SOAP binding to an underlying protocol as well as the application-defined 
semantics of the data carried in the ASN.1 SOAP message.

Interoperability considerations:
There are no known interoperability issues.

Published specification:
	ITU-T Rec. X.892 | ISO/IEC 24824-2
  
Applications which use this media type:
No known applications that use this media type.

Additional information:
File extension(s):
ASN.1 SOAP messages are not required or expected to be stored as files.

Person & email address to contact for further information:
ITU-T ASN.1 Rapporteur (contact via [email-masked])
ISO/IEC JTC1/SC6 ASN.1 Rapporteur (contact via [email-masked])

Intended usage:
COMMON

Author/Change controller:
Joint ITU-T | ISO/IEC balloting procedures in accordance with ITU-T Rec. A.23 
Collaboration with the International Organization for Standardization (ISO) and the 
International Electrotechnical Commission (IEC) on information technology, Annex A 
and ISO/IEC JTC1 Directives, Annex K.
>From [email-masked]  Wed Nov 17 18:24:17 2004
From: ben at morrow.me.uk (Ben Morrow)
Date: Wed Nov 17 21:59:32 2004
Subject: MIME types for preliminary community review
In-Reply-To: <[email-masked]>
References: <[email-masked]>
Message-ID: <[email-masked]>

At  9pm on 11/11/04 you (Paul Sandoz) wrote:

> MIME media type name:
> application
> 
> MIME subtype name:
> soap+fastinfoset

This is an incorrect generalization of the name 'soap+xml'. Names with +
in them are (IIRC) currently reserved, except for the case of '+xml' to
indicate an format which uses XML. The name should be
'soap-fastinfoset', or you should propose that the IETF extend the
'+xml' syntax to other types (such as fastinfoset) and get an IANA
registry set up for such types... personally, I think that would be a
very good idea (I can think of at least two other uses for this
convention: '+zip' for formats which are a zip file with a specific
layout, such as JAR, Perl's PAR, mozilla.org's XPI and Quake's pk3; and
'+gzip'/'+bzip2' to denote a gzip compressed version of a format), but
it would need proper discussion and specification.

> Magic number(s):
> A W3C SOAP message infoset serialized as a fast infoset document may begin 
> with one of the following byte sequences:
> 
> - a byte sequence that corresponds to a UTF-8 encoded XML declaration of the 
> string "<?xml version='1.0' encoding='finf'", the first five bytes of which 
> are hexadecimal 3C 3F 78 6D 6C;

The first five bytes here are not the relevant ones; the important bytes
are the 66 69 6e 66 at position 31; perhaps a sentence to the effect of
'fast infoset documents can be XML documents with an encoding of 'finf'
specified in the XML declaration' with a reference to the XML
registration for how to identify and parse an XML document. Also, this
does not identify specifically a soap fast infoset entity, merely a
generic fast infoset entity, so this whole section should probably just
reference the next registration unless there is a way to reliably
identify those fast infosets used in SOAP.

I'm a little worried about 'bytes' as opposed to 'octets': what's the
IETF position on this? 'octets' is definitely less ambiguous.

> MIME media type name:
> application
> 
> MIME subtype name:
> fastinfoset

Is it worth registering two separate types, 'application/fastinfoset'
and 'application/fastinfoset+xml' for fast infosets that are not and are
encoded as XML documents, respectively?

Ben

-- 
Every twenty-four hours about 34k children die from the effects of poverty.
Meanwhile, the latest estimate is that 2800 people died on 9/11, so it's like
that image, that ghastly, grey-billowing, double-barrelled fall, repeated
twelve times every day. Full of children. [Iain Banks]         [email-masked]
>From [email-masked]  Thu Nov 18 11:13:22 2004
From: chris at w3.org (Chris Lilley)
Date: Thu Nov 18 11:13:27 2004
Subject: MIME types for preliminary community review
In-Reply-To: <[email-masked]>
References: <[email-masked]>
	<[email-masked]>
Message-ID: <[email-masked]>

On Wednesday, November 17, 2004, 6:24:17 PM, Ben wrote:

BM> [...] (I can think of at least two other uses for this
BM> convention: '+zip' for formats which are a zip file with a specific
BM> layout, such as JAR, Perl's PAR, mozilla.org's XPI and Quake's pk3; and
BM> '+gzip'/'+bzip2' to denote a gzip compressed version of a format), but
BM> it would need proper discussion and specification.

For the first of those yes as its a file format; for the second, no -
remember the attempt at application/gzip and then the introduction of
Content-Encoding. Something which is gzipped should indicate its actual
media type, and use Content-Encoding to indicate that it is gzipped.

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

From: onno at ecma-international.org (Onno Elzinga)
Date: Tue Jan  3 16:22:51 2006
Subject: MIME Type Review Request: text/CSTA-type
Message-ID: <[email-masked]>

Dear reviewers,

Thanks for your constructive feedback.

Task Group 11 has reviewed your comments and agrees that both MIME types are meant for machines. Therefore they propose to change the second MIME type from "text/CSTA-types" to "application/CSTAdata+xml".

Hope this helps. 
We are meeting all week, so we would appreciate your speedy feedback.

Thanks,
Onno.

-----Original Message-----
From: Bruce Lilly [mailto:[email-masked]]
Sent: Saturday, November 06, 2004 6:22 PM
To: [email-masked]
Cc: Onno Elzinga; [email-masked]'; [email-masked]';
Hollenbeck, Scott
Subject: Re: MIME Type Review Request: text/CSTA-type

On Tue November 2 2004 08:54, Hollenbeck, Scott wrote:
> Please review the MIME type registration template described below.  The IESG
> has received a request to register this MIME type in the standards tree.  It
> is a product of Ecma International.  A URL for the formal specification is
> included in the template.
> 
> -Scott-
> ----------
> MIME media type name: text
> 
> MIME subtype name: CSTA-type
[...]
> Security considerations:
> This content type is designed to carry CSTA data types over network
> protocols. Appropriate precautions should be taken to insure that
> applications observing these CSTA objects are authorized to do so.
[...]
> Applications which use this media type:
> The text/CSTA-type MIME type is used to carry CSTA data types specified in
> CSTA XML (ECMA-323) over various types of network protocols.
> 
> Additional information:
> CSTA XML (ECMA-323) is an application level protocol that enables an
> application to control and observe communications involving various types of
> media (voice calls, video calls, instant messages, Email, SMS, Page, etc.)
> and devices associated with the media.

Why is this being proposed for registration in the text media type tree?
As far as I can tell, this media type appears to be an application data
format containing control data, not textual information (in the sense
of the use of "text" in the MIME standards (RFC 2046) and Internet
Best Current Practice (RFC 2277):

RFC 2046:
   The five discrete top-level media types are:

    (1)   text -- textual information.  The subtype "plain" in
          particular indicates plain text containing no
          formatting commands or directives of any sort. Plain
          text is intended to be displayed "as-is". No special
          software is required to get the full meaning of the
          text, aside from support for the indicated character
          set. Other subtypes are to be used for enriched text in
          forms where application software may enhance the
          appearance of the text, but such software must not be
          required in order to get the general idea of the
          content.  Possible subtypes of "text" thus include any
          word processor format that can be read without
          resorting to software that understands the format.  In
          particular, formats that employ embeddded binary
          formatting information are not considered directly
          readable. A very simple and portable subtype,
          "richtext", was defined in RFC 1341, with a further
          revision in RFC 1896 under the name "enriched".

RFC 2277:

   All human-readable text has a language.

   Many operations, including high quality formatting, text-to-speech
   synthesis, searching, hyphenation, spellchecking and so on benefit
   greatly from access to information about the language of a piece of
   text. [WC 3.1.1.4].

   Humans have some tolerance for foreign languages, but are generally
   very unhappy with being presented text in a language they do not
   understand; this is why negotiation of language is needed.

   In most cases, machines will not be able to deduce the language of a
   transmitted text by themselves; the protocol must specify how to
   transfer the language information if it is to be available at all.

   The interaction between language and processing is complex; for
   instance, if I compare "name-of-thing(lang=en)" to "name-of-
   thing(lang=no)" for equality, I will generally expect a match, while
   the word "ask(no)" is a kind of tree, and is hardly useful as a
   command verb.

 4.2.  Requirement for language tagging

   Protocols that transfer text MUST provide for carrying information
   about the language of that text.

Buried in an Annex in the 530-page referenced ECMA document one finds:

This annex specifies a schema for CSTA data types that can be used to encapulatate CSTA data objects so that they can be carried over various types of network protocols such as SIP. A specific MIME media type, text/CSTA-type is designed to contain these data objects. The formats of the data types are specified in Clause 9.

I can see nothing in the proposed media type registration or in the
referenced document that indicates that the media type is to be
used to convey human-readable natural language text as
opposed to application-specific data type, nor do I see any provision
for carrying information about language of text as required by
RFC 2277.

A concrete example of how the proposed media type would be
used to convey human-readable text in some specified language
would help to provide justification for registration of the
proposed subtype in the text media type tree.
>From [email-masked]  Thu Nov 11 21:15:58 2004
From: Paul.Sandoz at Sun.COM (Paul Sandoz)
Date: Tue Jan  3 16:22:51 2006
Subject: MIME types for preliminary community review
Message-ID: <[email-masked]>

Hi,

Attached are three MIME types for prelimiary community review before 
registration. Any feedback would be most welcome.

I understand the new 'Media Type Specifications and Registration 
Procedures' [1], which obsoletes RFC 2048, is in effect even though no 
new RFC number has been assigned.

The MIME types are specified in the following:

ITU-T Rec. X.891 | ISO/IEC 24824-1 (Fast Infoset) [2]
ITU-T Rec. X.892 | ISO/IEC 24824-2 (Fast Web Services) [3]

both of which are Final Committee Drafts under ballot in ISO. The ballot 
finishes on the 1st Feb 2005.

If there are any changes required as a result of review then i can 
incorporate these into an ISO ballot comment.

I plan to sumbit the MIME types to IANA ([email-masked]) in about 2 weeks 
time.

Thanks,
Paul.

[1] http://www.ietf.org/internet-drafts/draft-freed-media-type-reg-01.txt
[2] 
http://www.iso.org/iso/en/CatalogueDetailPage.CatalogueDetail?CSNUMBER=41327&scopelist=PROGRAMME
[3] 
http://www.iso.org/iso/en/CatalogueDetailPage.CatalogueDetail?CSNUMBER=41328&scopelist=PROGRAMME

-- 
| ? + ? = To question
----------------\
    Paul Sandoz
         x38109
+33-4-76188109

-------------- next part --------------
MIME media type name:
application

MIME subtype name:
soap+fastinfoset

Required parameters:
None.

Optional parameters:
"action": This parameter shall be used to identify the intent of the W3C SOAP 
message infoset as specified for the "action" parameter of the W3C SOAP 1.2 
"application/soap+xml" MIME media type (see W3C SOAP 1.2 Part 2, Appendix A). The 
value of the "action" parameter shall be an absolute URI-reference as specified in 
IETF RFC 2396. No restriction shall be placed on the specificity of the URI or that 
it is resolvable.

Encoding considerations:
This media type is used to identify W3C SOAP message infosets serialized as fast 
infoset documents as specified in ITU-T Rec. X.892 | ISO/IEC 24824-2.

Use of this MIME media type will require additional specification if used on 
transports that do not provide 8-bit binary transparency.  (For the purposes of 
Fast Web Services, ITU-T Rec. X.892 | ISO/IEC 24824-2, this media type is always 
used with HTTP as the transport mechanism, and no further specification is needed.)

Security considerations:
Because W3C SOAP message infosets can carry application defined data whose 
semantics is independent from that of any MIME wrapper (or context within which the 
MIME wrapper is used), one should not expect to be able to understand the semantics 
of the W3C SOAP message infoset based on the semantics of the MIME wrapper alone. 
Therefore, whenever using the "application/soap+fastinfoset" media type, it is 
strongly recommended that the security implications of the context within which the 
W3C SOAP message infoset is used is fully understood. The security implications are 
likely to involve the specific SOAP binding to an underlying protocol as well as 
the application-defined semantics of the data carried in the W3C SOAP message 
infoset.

Interoperability considerations:
There are no known interoperability issues.

Published specification:
ITU-T Rec. X.892 | ISO/IEC 24824-2
  
Applications which use this media type:
No known applications that use this media type.

Additional information:
Magic number(s):
A W3C SOAP message infoset serialized as a fast infoset document may begin 
with one of the following byte sequences:

- a byte sequence that corresponds to a UTF-8 encoded XML declaration of the 
string "<?xml version='1.0' encoding='finf'", the first five bytes of which 
are hexadecimal 3C 3F 78 6D 6C;

- a byte sequence that corresponds to a UTF-8 encoded XML declaration of the 
string "<?xml version='1.1' encoding='finf'", the first five bytes of which 
are also hexadecimal 3C 3F 78 6D 6C;

- a byte sequence of hexadecimal E0 00 00 01.

File extension(s):
W3C SOAP message infosets serialized as fast infoset documents are not 
required or expected to be stored as files.

Person & email address to contact for further information:
ITU-T ASN.1 Rapporteur (contact via [email-masked])
ISO/IEC JTC1/SC6 ASN.1 Rapporteur (contact via [email-masked])

Intended usage:
COMMON

Author/Change controller:
Joint ITU-T | ISO/IEC balloting procedures in accordance with ITU-T Rec. A.23 
Collaboration with the International Organization for Standardization (ISO) and the 
International Electrotechnical Commission (IEC) on information technology, Annex A 
and ISO/IEC JTC1 Directives, Annex K.
-------------- next part --------------
MIME media type name:
application

MIME subtype name:
fastinfoset

Required parameters:
None.

Optional parameters:
None.

Encoding considerations:
XML infosets encoded as fast infoset documents will result in the production of 
binary data. This MIME media type may require further encoding on transports not 
capable of handling binary data.

Security considerations:
Because XML infosets encoded as fast infoset documents can carry application 
defined data whose semantics is independent from that of any MIME wrapper (or 
context within which the MIME wrapper is used), one should not expect to be able to 
understand the semantics of the fast infoset document based on the semantics of the 
MIME wrapper alone. Therefore, whenever using the "application/fastinfoset" media 
type, it is strongly recommended that the security implications of the context 
within which the fast infoset document is used is fully understood.

Interoperability considerations:
There are no known interoperability issues.

Published specification:
ITU-T Rec. X.891 | ISO/IEC 24824-1
  
Applications which use this media type:
No known applications currently use this media type.

Additional information:

Magic number(s):
A fast infoset document may begin with one of the following byte sequences:

- a byte sequence that corresponds to a UTF-8 encoded XML declaration of the 
string "<?xml version='1.0' encoding='finf'", the first five bytes of which 
are hexadecimal 3C 3F 78 6D 6C;

- a byte sequence that corresponds to a UTF-8 encoded XML declaration of the 
string "<?xml version='1.1' encoding='finf'", the first five bytes of which 
are also hexadecimal 3C 3F 78 6D 6C;

- a byte sequence of hexadecimal E0 00 00 01.

File extension(s):
*.finf

Person & email address to contact for further information:
ITU-T ASN.1 Rapporteur (contact via [email-masked])
ISO/IEC JTC1/SC6 ASN.1 Rapporteur (contact via [email-masked])

Intended usage:
COMMON

Author/Change controller:
Joint ITU-T | ISO/IEC balloting procedures in accordance with ITU-T Rec. A.23 
Collaboration with the International Organization for Standardization (ISO) and the 
International Electrotechnical Commission (IEC) on information technology, Annex A 
and ISO/IEC JTC1 Directives, Annex K.
-------------- next part --------------
MIME media type name:
application

MIME subtype name:
fastsoap

Required parameters:
None.

Optional parameters:
"action": This parameter shall be used to identify the intent of the ASN.1 SOAP 
message as specified for the "action" parameter of the W3C SOAP 1.2 
"application/soap+xml" MIME media type (see W3C SOAP 1.2 Part 2, Appendix A). The 
value of the "action" parameter shall be an absolute URI-reference as specified in 
IETF RFC 2396. No restriction shall be placed on the specificity of the URI or that 
it is resolvable.

Encoding considerations:
This media type is used to identify content that is a value of the ASN.1 Envelope 
type specified in the ASN1SOAP module of ITU-T Rec. X.892 | ISO/IEC 24824-2, 
encoded using Basic Aligned Packed Encoding Rule specified in ITU-T Rec. X.691 | 
ISO/IEC 8825-2.

Use of this MIME media type will require additional specification if used on 
transports that do not provide 8-bit binary transparency.  (For the purposes of 
Fast Web Services, ITU-T Rec. X.892 | ISO/IEC 24824-2, this media type is always 
used with the Basic Aligned Packed Encoding Rule and with HTTP as the transport 
mechanism, and no further specification is needed.)

Security considerations:
Because ASN.1 SOAP messages can carry application-defined data whose semantics is 
independent from that of any MIME wrapper (or context within which the MIME wrapper 
is used), one should not expect to be able to understand the semantics of the ASN.1 
SOAP message based on the semantics of the MIME wrapper alone. Therefore, whenever 
using the "application/fastsoap" media type, it is strongly recommended that the 
security implications of the context within which the ASN.1 SOAP message is used is 
fully understood. The security implications are likely to involve the specific 
ASN.1 SOAP binding to an underlying protocol as well as the application-defined 
semantics of the data carried in the ASN.1 SOAP message.

Interoperability considerations:
There are no known interoperability issues.

Published specification:
	ITU-T Rec. X.892 | ISO/IEC 24824-2
  
Applications which use this media type:
No known applications that use this media type.

Additional information:
File extension(s):
ASN.1 SOAP messages are not required or expected to be stored as files.

Person & email address to contact for further information:
ITU-T ASN.1 Rapporteur (contact via [email-masked])
ISO/IEC JTC1/SC6 ASN.1 Rapporteur (contact via [email-masked])

Intended usage:
COMMON

Author/Change controller:
Joint ITU-T | ISO/IEC balloting procedures in accordance with ITU-T Rec. A.23 
Collaboration with the International Organization for Standardization (ISO) and the 
International Electrotechnical Commission (IEC) on information technology, Annex A 
and ISO/IEC JTC1 Directives, Annex K.
>From [email-masked]  Wed Nov 17 18:24:17 2004
From: ben at morrow.me.uk (Ben Morrow)
Date: Tue Jan  3 16:22:51 2006
Subject: MIME types for preliminary community review
In-Reply-To: <[email-masked]>
References: <[email-masked]>
Message-ID: <[email-masked]>

At  9pm on 11/11/04 you (Paul Sandoz) wrote:

> MIME media type name:
> application
> 
> MIME subtype name:
> soap+fastinfoset

This is an incorrect generalization of the name 'soap+xml'. Names with +
in them are (IIRC) currently reserved, except for the case of '+xml' to
indicate an format which uses XML. The name should be
'soap-fastinfoset', or you should propose that the IETF extend the
'+xml' syntax to other types (such as fastinfoset) and get an IANA
registry set up for such types... personally, I think that would be a
very good idea (I can think of at least two other uses for this
convention: '+zip' for formats which are a zip file with a specific
layout, such as JAR, Perl's PAR, mozilla.org's XPI and Quake's pk3; and
'+gzip'/'+bzip2' to denote a gzip compressed version of a format), but
it would need proper discussion and specification.

> Magic number(s):
> A W3C SOAP message infoset serialized as a fast infoset document may begin 
> with one of the following byte sequences:
> 
> - a byte sequence that corresponds to a UTF-8 encoded XML declaration of the 
> string "<?xml version='1.0' encoding='finf'", the first five bytes of which 
> are hexadecimal 3C 3F 78 6D 6C;

The first five bytes here are not the relevant ones; the important bytes
are the 66 69 6e 66 at position 31; perhaps a sentence to the effect of
'fast infoset documents can be XML documents with an encoding of 'finf'
specified in the XML declaration' with a reference to the XML
registration for how to identify and parse an XML document. Also, this
does not identify specifically a soap fast infoset entity, merely a
generic fast infoset entity, so this whole section should probably just
reference the next registration unless there is a way to reliably
identify those fast infosets used in SOAP.

I'm a little worried about 'bytes' as opposed to 'octets': what's the
IETF position on this? 'octets' is definitely less ambiguous.

> MIME media type name:
> application
> 
> MIME subtype name:
> fastinfoset

Is it worth registering two separate types, 'application/fastinfoset'
and 'application/fastinfoset+xml' for fast infosets that are not and are
encoded as XML documents, respectively?

Ben

-- 
Every twenty-four hours about 34k children die from the effects of poverty.
Meanwhile, the latest estimate is that 2800 people died on 9/11, so it's like
that image, that ghastly, grey-billowing, double-barrelled fall, repeated
twelve times every day. Full of children. [Iain Banks]         [email-masked]

From: chris at w3.org (Chris Lilley)
Date: Tue Jan  3 16:22:51 2006
Subject: MIME Type Review Request: text/CSTA-type
In-Reply-To: <[email-masked]>
References: <[email-masked]> <[email-masked]>
Message-ID: <[email-masked]>

On Saturday, November 6, 2004, 6:22:11 PM, Bruce wrote:

BL> On Tue November 2 2004 08:54, Hollenbeck, Scott wrote:
>> Please review the MIME type registration template described below.  The IESG
>> has received a request to register this MIME type in the standards tree.  It
>> is a product of Ecma International.  A URL for the formal specification is
>> included in the template.
>> 
>> -Scott-
>> ----------
>> MIME media type name: text
>> 
>> MIME subtype name: CSTA-type
BL> [...]
>> Security considerations:
>> This content type is designed to carry CSTA data types over network
>> protocols. Appropriate precautions should be taken to insure that
>> applications observing these CSTA objects are authorized to do so.
BL> [...]
>> Applications which use this media type:
>> The text/CSTA-type MIME type is used to carry CSTA data types specified in
>> CSTA XML (ECMA-323) over various types of network protocols.
>> 
>> Additional information:
>> CSTA XML (ECMA-323) is an application level protocol that enables an
>> application to control and observe communications involving various types of
>> media (voice calls, video calls, instant messages, Email, SMS, Page, etc.)
>> and devices associated with the media.

BL> Why is this being proposed for registration in the text media type tree?
BL> As far as I can tell, this media type appears to be an application data
BL> format containing control data, not textual information (in the sense
BL> of the use of "text" in the MIME standards (RFC 2046) and Internet
BL> Best Current Practice (RFC 2277):

In addition, its an XML media type so

- it should use the +xml  convention
- it should not use text/*

The latter is currently allowed by RFC 3023 but that is being revised to
deperecate use of text/* for XML types.

So, more reasons it should be application/CSTA-type+xml

BL> I can see nothing in the proposed media type registration or in the
BL> referenced document that indicates that the media type is to be
BL> used to convey human-readable natural language text as
BL> opposed to application-specific data type,

Agreed

BL> nor do I see any provision
BL> for carrying information about language of text as required by
BL> RFC 2277.

(If its xml, that would be done with xml:lang attributes)

BL> A concrete example of how the proposed media type would be
BL> used to convey human-readable text in some specified language
BL> would help to provide justification for registration of the
BL> proposed subtype in the text media type tree.
 
And even then, I would argue it should not be in the text tree.

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

From: blilly at erols.com (Bruce Lilly)
Date: Sat Nov  6 20:24:45 2004
Subject: MIME Type Review Request: text/CSTA-type
In-Reply-To: <[email-masked]>
References: <[email-masked]>
Message-ID: <[email-masked]>

On Tue November 2 2004 08:54, Hollenbeck, Scott wrote:
> Please review the MIME type registration template described below.  The IESG
> has received a request to register this MIME type in the standards tree.  It
> is a product of Ecma International.  A URL for the formal specification is
> included in the template.
> 
> -Scott-
> ----------
> MIME media type name: text
> 
> MIME subtype name: CSTA-type
[...]
> Security considerations:
> This content type is designed to carry CSTA data types over network
> protocols. Appropriate precautions should be taken to insure that
> applications observing these CSTA objects are authorized to do so.
[...]
> Applications which use this media type:
> The text/CSTA-type MIME type is used to carry CSTA data types specified in
> CSTA XML (ECMA-323) over various types of network protocols.
> 
> Additional information:
> CSTA XML (ECMA-323) is an application level protocol that enables an
> application to control and observe communications involving various types of
> media (voice calls, video calls, instant messages, Email, SMS, Page, etc.)
> and devices associated with the media.

Why is this being proposed for registration in the text media type tree?
As far as I can tell, this media type appears to be an application data
format containing control data, not textual information (in the sense
of the use of "text" in the MIME standards (RFC 2046) and Internet
Best Current Practice (RFC 2277):

RFC 2046:
   The five discrete top-level media types are:

    (1)   text -- textual information.  The subtype "plain" in
          particular indicates plain text containing no
          formatting commands or directives of any sort. Plain
          text is intended to be displayed "as-is". No special
          software is required to get the full meaning of the
          text, aside from support for the indicated character
          set. Other subtypes are to be used for enriched text in
          forms where application software may enhance the
          appearance of the text, but such software must not be
          required in order to get the general idea of the
          content.  Possible subtypes of "text" thus include any
          word processor format that can be read without
          resorting to software that understands the format.  In
          particular, formats that employ embeddded binary
          formatting information are not considered directly
          readable. A very simple and portable subtype,
          "richtext", was defined in RFC 1341, with a further
          revision in RFC 1896 under the name "enriched".

RFC 2277:

   All human-readable text has a language.

   Many operations, including high quality formatting, text-to-speech
   synthesis, searching, hyphenation, spellchecking and so on benefit
   greatly from access to information about the language of a piece of
   text. [WC 3.1.1.4].

   Humans have some tolerance for foreign languages, but are generally
   very unhappy with being presented text in a language they do not
   understand; this is why negotiation of language is needed.

   In most cases, machines will not be able to deduce the language of a
   transmitted text by themselves; the protocol must specify how to
   transfer the language information if it is to be available at all.

   The interaction between language and processing is complex; for
   instance, if I compare "name-of-thing(lang=en)" to "name-of-
   thing(lang=no)" for equality, I will generally expect a match, while
   the word "ask(no)" is a kind of tree, and is hardly useful as a
   command verb.

 4.2.  Requirement for language tagging

   Protocols that transfer text MUST provide for carrying information
   about the language of that text.

Buried in an Annex in the 530-page referenced ECMA document one finds:

This annex specifies a schema for CSTA data types that can be used to encapulatate CSTA data objects so that they can be carried over various types of network protocols such as SIP. A specific MIME media type, text/CSTA-type is designed to contain these data objects. The formats of the data types are specified in Clause 9.

I can see nothing in the proposed media type registration or in the
referenced document that indicates that the media type is to be
used to convey human-readable natural language text as
opposed to application-specific data type, nor do I see any provision
for carrying information about language of text as required by
RFC 2277.

A concrete example of how the proposed media type would be
used to convey human-readable text in some specified language
would help to provide justification for registration of the
proposed subtype in the text media type tree.
>From [email-masked]  Sat Nov  6 20:38:51 2004
From: chris at w3.org (Chris Lilley)
Date: Sat Nov  6 20:38:55 2004
Subject: MIME Type Review Request: text/CSTA-type
In-Reply-To: <[email-masked]>
References: <[email-masked]>
	<[email-masked]>
Message-ID: <[email-masked]>

On Saturday, November 6, 2004, 6:22:11 PM, Bruce wrote:

BL> On Tue November 2 2004 08:54, Hollenbeck, Scott wrote:
>> Please review the MIME type registration template described below.  The IESG
>> has received a request to register this MIME type in the standards tree.  It
>> is a product of Ecma International.  A URL for the formal specification is
>> included in the template.
>> 
>> -Scott-
>> ----------
>> MIME media type name: text
>> 
>> MIME subtype name: CSTA-type
BL> [...]
>> Security considerations:
>> This content type is designed to carry CSTA data types over network
>> protocols. Appropriate precautions should be taken to insure that
>> applications observing these CSTA objects are authorized to do so.
BL> [...]
>> Applications which use this media type:
>> The text/CSTA-type MIME type is used to carry CSTA data types specified in
>> CSTA XML (ECMA-323) over various types of network protocols.
>> 
>> Additional information:
>> CSTA XML (ECMA-323) is an application level protocol that enables an
>> application to control and observe communications involving various types of
>> media (voice calls, video calls, instant messages, Email, SMS, Page, etc.)
>> and devices associated with the media.

BL> Why is this being proposed for registration in the text media type tree?
BL> As far as I can tell, this media type appears to be an application data
BL> format containing control data, not textual information (in the sense
BL> of the use of "text" in the MIME standards (RFC 2046) and Internet
BL> Best Current Practice (RFC 2277):

In addition, its an XML media type so

- it should use the +xml  convention
- it should not use text/*

The latter is currently allowed by RFC 3023 but that is being revised to
deperecate use of text/* for XML types.

So, more reasons it should be application/CSTA-type+xml

BL> I can see nothing in the proposed media type registration or in the
BL> referenced document that indicates that the media type is to be
BL> used to convey human-readable natural language text as
BL> opposed to application-specific data type,

Agreed

BL> nor do I see any provision
BL> for carrying information about language of text as required by
BL> RFC 2277.

(If its xml, that would be done with xml:lang attributes)

BL> A concrete example of how the proposed media type would be
BL> used to convey human-readable text in some specified language
BL> would help to provide justification for registration of the
BL> proposed subtype in the text media type tree.
 
And even then, I would argue it should not be in the text tree.

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

From: blilly at erols.com (Bruce Lilly)
Date: Tue Jan  3 16:22:51 2006
Subject: MIME Type Review Request: text/CSTA-type
In-Reply-To: <[email-masked]>
References: <[email-masked]>
Message-ID: <[email-masked]>

On Tue November 2 2004 08:54, Hollenbeck, Scott wrote:
> Please review the MIME type registration template described below.  The IESG
> has received a request to register this MIME type in the standards tree.  It
> is a product of Ecma International.  A URL for the formal specification is
> included in the template.
> 
> -Scott-
> ----------
> MIME media type name: text
> 
> MIME subtype name: CSTA-type
[...]
> Security considerations:
> This content type is designed to carry CSTA data types over network
> protocols. Appropriate precautions should be taken to insure that
> applications observing these CSTA objects are authorized to do so.
[...]
> Applications which use this media type:
> The text/CSTA-type MIME type is used to carry CSTA data types specified in
> CSTA XML (ECMA-323) over various types of network protocols.
> 
> Additional information:
> CSTA XML (ECMA-323) is an application level protocol that enables an
> application to control and observe communications involving various types of
> media (voice calls, video calls, instant messages, Email, SMS, Page, etc.)
> and devices associated with the media.

Why is this being proposed for registration in the text media type tree?
As far as I can tell, this media type appears to be an application data
format containing control data, not textual information (in the sense
of the use of "text" in the MIME standards (RFC 2046) and Internet
Best Current Practice (RFC 2277):

RFC 2046:
   The five discrete top-level media types are:

    (1)   text -- textual information.  The subtype "plain" in
          particular indicates plain text containing no
          formatting commands or directives of any sort. Plain
          text is intended to be displayed "as-is". No special
          software is required to get the full meaning of the
          text, aside from support for the indicated character
          set. Other subtypes are to be used for enriched text in
          forms where application software may enhance the
          appearance of the text, but such software must not be
          required in order to get the general idea of the
          content.  Possible subtypes of "text" thus include any
          word processor format that can be read without
          resorting to software that understands the format.  In
          particular, formats that employ embeddded binary
          formatting information are not considered directly
          readable. A very simple and portable subtype,
          "richtext", was defined in RFC 1341, with a further
          revision in RFC 1896 under the name "enriched".

RFC 2277:

   All human-readable text has a language.

   Many operations, including high quality formatting, text-to-speech
   synthesis, searching, hyphenation, spellchecking and so on benefit
   greatly from access to information about the language of a piece of
   text. [WC 3.1.1.4].

   Humans have some tolerance for foreign languages, but are generally
   very unhappy with being presented text in a language they do not
   understand; this is why negotiation of language is needed.

   In most cases, machines will not be able to deduce the language of a
   transmitted text by themselves; the protocol must specify how to
   transfer the language information if it is to be available at all.

   The interaction between language and processing is complex; for
   instance, if I compare "name-of-thing(lang=en)" to "name-of-
   thing(lang=no)" for equality, I will generally expect a match, while
   the word "ask(no)" is a kind of tree, and is hardly useful as a
   command verb.

 4.2.  Requirement for language tagging

   Protocols that transfer text MUST provide for carrying information
   about the language of that text.

Buried in an Annex in the 530-page referenced ECMA document one finds:

This annex specifies a schema for CSTA data types that can be used to encapulatate CSTA data objects so that they can be carried over various types of network protocols such as SIP. A specific MIME media type, text/CSTA-type is designed to contain these data objects. The formats of the data types are specified in Clause 9.

I can see nothing in the proposed media type registration or in the
referenced document that indicates that the media type is to be
used to convey human-readable natural language text as
opposed to application-specific data type, nor do I see any provision
for carrying information about language of text as required by
RFC 2277.

A concrete example of how the proposed media type would be
used to convey human-readable text in some specified language
would help to provide justification for registration of the
proposed subtype in the text media type tree.

From: duerst at w3.org (Martin Duerst)
Date: Thu Nov  4 13:10:56 2004
Subject: MIME Type Review Request: text/CSTA-type
In-Reply-To: <[email-masked] d.vrsn.com>
References: <[email-masked]>
Message-ID: <6.0.0.20.2.20041104150826.06006888@localhost>

Question/comment: Why does this registration not use the -xml converntion?

Regards,    Martin.

At 22:54 04/11/02, Hollenbeck, Scott wrote:
 >Please review the MIME type registration template described below.  The IESG
 >has received a request to register this MIME type in the standards tree.  It
 >is a product of Ecma International.  A URL for the formal specification is
 >included in the template.
 >
 >-Scott-
 >----------
 >MIME media type name: text
 >
 >MIME subtype name: CSTA-type
 >
 >Required parameters: (none)
 >
 >Optional parameters: (none)
 >
 >Encoding considerations:
 >This content type uses XML, employing UTF-8 character encoding.
 >
 >Security considerations:
 >This content type is designed to carry CSTA data types over network
 >protocols. Appropriate precautions should be taken to insure that
 >applications observing these CSTA objects are authorized to do so.
 >
 >Interoperability considerations:
 >text/CSTA-type documents are specified by the XML schemas standardized in
 >ECMA-323.
 >
 >Published specification:
 >The published Standard ECMA-323 is available at:
 >http://www.ecma-international.org/publications/standards/Ecma-323.htm
 >
 >Applications which use this media type:
 >The text/CSTA-type MIME type is used to carry CSTA data types specified in
 >CSTA XML (ECMA-323) over various types of network protocols.
 >
 >Additional information:
 >CSTA XML (ECMA-323) is an application level protocol that enables an
 >application to control and observe communications involving various types of
 >media (voice calls, video calls, instant messages, Email, SMS, Page, etc.)
 >and devices associated with the media.
 >
 >Person & email address to contact for further information:
 >Ecma Secretariat
 >Rue du Rhone114
 >CH-1204 Geneva
 >Switzerland
 >[email-masked]
 >
 >Intended usage: common
 >
 >Author/change controller:
 >The ECMA-323 Standard is developed and maintained by the Ecma TC32/TG11
 >Working Group. 

From: duerst at w3.org (Martin Duerst)
Date: Tue Jan  3 16:22:51 2006
Subject: MIME Type Review Request: text/CSTA-type
In-Reply-To: <[email-masked] d.vrsn.com>
References: <[email-masked]>
Message-ID: <6.0.0.20.2.20041104150826.06006888@localhost>

Question/comment: Why does this registration not use the -xml converntion?

Regards,    Martin.

At 22:54 04/11/02, Hollenbeck, Scott wrote:
 >Please review the MIME type registration template described below.  The IESG
 >has received a request to register this MIME type in the standards tree.  It
 >is a product of Ecma International.  A URL for the formal specification is
 >included in the template.
 >
 >-Scott-
 >----------
 >MIME media type name: text
 >
 >MIME subtype name: CSTA-type
 >
 >Required parameters: (none)
 >
 >Optional parameters: (none)
 >
 >Encoding considerations:
 >This content type uses XML, employing UTF-8 character encoding.
 >
 >Security considerations:
 >This content type is designed to carry CSTA data types over network
 >protocols. Appropriate precautions should be taken to insure that
 >applications observing these CSTA objects are authorized to do so.
 >
 >Interoperability considerations:
 >text/CSTA-type documents are specified by the XML schemas standardized in
 >ECMA-323.
 >
 >Published specification:
 >The published Standard ECMA-323 is available at:
 >http://www.ecma-international.org/publications/standards/Ecma-323.htm
 >
 >Applications which use this media type:
 >The text/CSTA-type MIME type is used to carry CSTA data types specified in
 >CSTA XML (ECMA-323) over various types of network protocols.
 >
 >Additional information:
 >CSTA XML (ECMA-323) is an application level protocol that enables an
 >application to control and observe communications involving various types of
 >media (voice calls, video calls, instant messages, Email, SMS, Page, etc.)
 >and devices associated with the media.
 >
 >Person & email address to contact for further information:
 >Ecma Secretariat
 >Rue du Rhone114
 >CH-1204 Geneva
 >Switzerland
 >[email-masked]
 >
 >Intended usage: common
 >
 >Author/change controller:
 >The ECMA-323 Standard is developed and maintained by the Ecma TC32/TG11
 >Working Group. 

From: iana at iana.org ([email-masked])
Date: Thu Nov  4 02:23:53 2004
Subject: ConfirmSystem: [email-masked] [[71f18dfe1e15cc09]]
Message-ID: <[email-masked]>

Thank you for your message.

The [email-masked] address collects a tremendous amount of spam, and we
have been forced to implement protective measures.  In order to process
your message we need to confirm that it came from a real email address. 
To confirm your message, you can either:

  1) Reply to this message, without altering the subject line 
    The "Re: " added by many mail clients is OK, but please note
    that this method is *not* foolproof.  

or

  2) Visit the URL
        <http://confirm.icann.org/?s=71f18dfe1e15cc09&l=[email-masked]>

If you want to be very sure that your message gets through, do both steps
above -- it does no harm to confirm more than once.

For your reference, the subject of the message you sent was:

  "{Filename?} Re: Thanks :)"
       
and it arrived at IANA approximately at Wed Nov  3 17:23:44 2004.

---------------------------------------------------------------
ConfirmSystem: [email-masked] [[71f18dfe1e15cc09]]
1

From: iana at iana.org ([email-masked])
Date: Tue Jan  3 16:22:51 2006
Subject: ConfirmSystem: [email-masked] [[71f18dfe1e15cc09]]
Message-ID: <[email-masked]>

Thank you for your message.

The [email-masked] address collects a tremendous amount of spam, and we
have been forced to implement protective measures.  In order to process
your message we need to confirm that it came from a real email address. 
To confirm your message, you can either:

  1) Reply to this message, without altering the subject line 
    The "Re: " added by many mail clients is OK, but please note
    that this method is *not* foolproof.  

or

  2) Visit the URL
        <http://confirm.icann.org/?s=71f18dfe1e15cc09&l=[email-masked]>

If you want to be very sure that your message gets through, do both steps
above -- it does no harm to confirm more than once.

For your reference, the subject of the message you sent was:

  "{Filename?} Re: Thanks :)"
       
and it arrived at IANA approximately at Wed Nov  3 17:23:44 2004.

---------------------------------------------------------------
ConfirmSystem: [email-masked] [[71f18dfe1e15cc09]]
1

From: chris at w3.org (Chris Lilley)
Date: Tue Nov  2 17:22:36 2004
Subject: MIME Type Review Request: image/svg+xml
Message-ID: <[email-masked]>

Please review the Media Type registration template described below. It
is available in HTML [1] or in plain text form [2] and relates to the
SVG specification [3]. Registration of this Media Type in the standards
tree is requested, in conformance with [4] and [5].
   
      [1] http://www.w3.org/TR/SVG12/mimereg.html
      [2] http://www.w3.org/TR/SVG12/mimereg.html,text
      [3] http://www.w3.org/TR/SVG12/
      [4] http://www.ietf.org/internet-drafts/draft-freed-media-type-reg-01.txt
      [5] http://www.w3.org/2002/06/registering-mediatype

Registration of Media Type image/svg+xml

   MIME media type name:
          image

   MIME subtype name:
          svg+xml

   Required parameters:
          None.

   Optional parameters:
          None

          The encoding of an SVG document is determined by the XML
          encoding declaration. This has identical semantics to the
          application/xml media type in the case where the charset
          parameter is omitted, as specified in [6]RFC3023 sections 8.9,
          8.10 and 8.11.

      [6] http://www.w3.org/TR/SVG12/references

   Encoding considerations:
          Same as for application/xml. See [7]RFC3023 , section 3.2.

      [7] http://www.w3.org/TR/SVG12/references

   Restrictions on usage:
          None

   Security considerations:
          As with other XML types and as noted in [8]RFC3023 section 10,
          repeated expansion of maliciously constructed XML entities can
          be used to consume large amounts of memory, which may cause XML
          processors in constrained environments to fail.

      [8] http://www.w3.org/TR/SVG12/references

          SVG documents may be transmitted in compressed form using gzip
          compression. For systems which employ MIME-like mechanisms,
          such as HTTP, this is indicated by the
          Content-Transfer-Encoding header; for systems which do not,
          such as direct filesystem access, this is indicated by the
          filename extension and by the Macintosh File Type Codes. In
          addition, gzip compressed content is readily recognised by the
          initial byte sequence as described in [9]RFC1952 section 2.3.1.

      [9] http://www.w3.org/TR/SVG12/references

          Several SVG elements may cause arbitrary URIs to be referenced.
          In this case, the security issues of [10]RFC2396, section 7,
          should be considered.

     [10] http://www.w3.org/TR/SVG12/references

          In common with HTML, SVG documents may reference external media
          such as images, audio, video, style sheets, and scripting
          languages. Scripting languages are executable content. In this
          case, the security considerations in the Media Type
          registrations for those formats apply.

          In addition, because of the extensibility features for SVG and
          of XML in general, it is possible that "image/svg+xml" may
          describe content that has security implications beyond those
          described here. However, if the processor follows only the
          normative semantics of this specification, this content will be
          outside the SVG namespace and will be ignored. Only in the case
          where the processor recognizes and processes the additional
          content, or where further processing of that content is
          dispatched to other processors, would security issues
          potentially arise. And in that case, they would fall outside
          the domain of this registration document.

   Interoperability considerations:
          This specification describes processing semantics that dictate
          behavior that must be followed when dealing with, among other
          things, unrecognized elements and attributes, both in the SVG
          namespace and in other namespaces.

          Because SVG is extensible, conformant "image/svg+xml"
          processors must expect that content received is well-formed
          XML, but it cannot be guaranteed that the content is valid to a
          particular DTD or Schema or that the processor will recognize
          all of the elements and attributes in the document.

          SVG has a published Test Suite and associated implementation
          report showing which implementations passed which tests at the
          time of the report. This information is periodically updated as
          new tests are added or as implementations improve.

   Published specification:
          This media type registration is extracted from Appendix G of
          the SVG 1.2 specification.

   Additional information:

   Person & email address to contact for further information:
          Dean Jackson, ([email-masked]).

   Intended usage:
          COMMON

   Author/Change controller:
          The SVG specification is a work product of the World Wide Web
          Consortium's SVG Working Group. The W3C has change control over
          these specifications.

-- 
 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:51 2006
Subject: MIME Type Review Request: image/svg+xml
Message-ID: <[email-masked]>

Please review the Media Type registration template described below. It
is available in HTML [1] or in plain text form [2] and relates to the
SVG specification [3]. Registration of this Media Type in the standards
tree is requested, in conformance with [4] and [5].
   
      [1] http://www.w3.org/TR/SVG12/mimereg.html
      [2] http://www.w3.org/TR/SVG12/mimereg.html,text
      [3] http://www.w3.org/TR/SVG12/
      [4] http://www.ietf.org/internet-drafts/draft-freed-media-type-reg-01.txt
      [5] http://www.w3.org/2002/06/registering-mediatype

Registration of Media Type image/svg+xml

   MIME media type name:
          image

   MIME subtype name:
          svg+xml

   Required parameters:
          None.

   Optional parameters:
          None

          The encoding of an SVG document is determined by the XML
          encoding declaration. This has identical semantics to the
          application/xml media type in the case where the charset
          parameter is omitted, as specified in [6]RFC3023 sections 8.9,
          8.10 and 8.11.

      [6] http://www.w3.org/TR/SVG12/references

   Encoding considerations:
          Same as for application/xml. See [7]RFC3023 , section 3.2.

      [7] http://www.w3.org/TR/SVG12/references

   Restrictions on usage:
          None

   Security considerations:
          As with other XML types and as noted in [8]RFC3023 section 10,
          repeated expansion of maliciously constructed XML entities can
          be used to consume large amounts of memory, which may cause XML
          processors in constrained environments to fail.

      [8] http://www.w3.org/TR/SVG12/references

          SVG documents may be transmitted in compressed form using gzip
          compression. For systems which employ MIME-like mechanisms,
          such as HTTP, this is indicated by the
          Content-Transfer-Encoding header; for systems which do not,
          such as direct filesystem access, this is indicated by the
          filename extension and by the Macintosh File Type Codes. In
          addition, gzip compressed content is readily recognised by the
          initial byte sequence as described in [9]RFC1952 section 2.3.1.

      [9] http://www.w3.org/TR/SVG12/references

          Several SVG elements may cause arbitrary URIs to be referenced.
          In this case, the security issues of [10]RFC2396, section 7,
          should be considered.

     [10] http://www.w3.org/TR/SVG12/references

          In common with HTML, SVG documents may reference external media
          such as images, audio, video, style sheets, and scripting
          languages. Scripting languages are executable content. In this
          case, the security considerations in the Media Type
          registrations for those formats apply.

          In addition, because of the extensibility features for SVG and
          of XML in general, it is possible that "image/svg+xml" may
          describe content that has security implications beyond those
          described here. However, if the processor follows only the
          normative semantics of this specification, this content will be
          outside the SVG namespace and will be ignored. Only in the case
          where the processor recognizes and processes the additional
          content, or where further processing of that content is
          dispatched to other processors, would security issues
          potentially arise. And in that case, they would fall outside
          the domain of this registration document.

   Interoperability considerations:
          This specification describes processing semantics that dictate
          behavior that must be followed when dealing with, among other
          things, unrecognized elements and attributes, both in the SVG
          namespace and in other namespaces.

          Because SVG is extensible, conformant "image/svg+xml"
          processors must expect that content received is well-formed
          XML, but it cannot be guaranteed that the content is valid to a
          particular DTD or Schema or that the processor will recognize
          all of the elements and attributes in the document.

          SVG has a published Test Suite and associated implementation
          report showing which implementations passed which tests at the
          time of the report. This information is periodically updated as
          new tests are added or as implementations improve.

   Published specification:
          This media type registration is extracted from Appendix G of
          the SVG 1.2 specification.

   Additional information:

   Person & email address to contact for further information:
          Dean Jackson, ([email-masked]).

   Intended usage:
          COMMON

   Author/Change controller:
          The SVG specification is a work product of the World Wide Web
          Consortium's SVG Working Group. The W3C has change control over
          these specifications.

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

From: chris at w3.org (Chris Lilley)
Date: Tue Nov  2 17:22:24 2004
Subject: SVG12: charset parameter for image/svg+xml
In-Reply-To: <[email-masked]>
References: <[email-masked]> <[email-masked]> <[email-masked]>
Message-ID: <[email-masked]>

On Tuesday, November 2, 2004, 4:45:40 PM, MURATA wrote:

MM> On Mon, 1 Nov 2004 20:03:17 +0100
MM> Chris Lilley <[email-masked]> wrote:

>> I was able to discuss this with Murata-san in Tokyo at SVG Open, and he
>> agreed that the +xml convention, plus the deprecation of text/xml and
>> associated charset handling weirdness of required us-ascii fallback,
>> allows consistent handling

MM> No, I did not agree to drop the charset parameter.

What I said was that you agreed that there was consistent handling in
the case where there was no charset parameter.  Do you recall discussing
that over lunch? Jon was there, too.

We also discussed consistent handling of encoding among all media types;
you had earlier stated that this was particularly needed for simple
transcoders that did not know enough about xml not to break it. At that
meeting, I suggested (and you agreed) that the presence of the +xml
convention allowed such transcoders to reliably detect all xml media
types whether the precise media type was recognized or not.

I further suggested (and you seemed to agree) that two types of
processing were desirable:

a) (minimally) xml-aware transcoders - transcode, and update the xml
encoding declaration so that it is consistent
b) xml-unaware transcoders - not break xml well formednes, not transcode
xml
and a third type of processing was undesirable
c) xml unaware transcoders that take well formed documents and make them
malformed.

Transcoders already do something similar, for example they do not
attempt to transcode the bytes of JPEG images.

MM> I did agree to deprecate text/xml.

Yes, that part is already in the next draft (and the other text/* xml
types)

MM> I do believe that image/svg+xml should allow the charset parameter.

So we still have some discussion to do.

-- 
 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:51 2006
Subject: SVG12: charset parameter for image/svg+xml
In-Reply-To: <[email-masked]>
References: <[email-masked]> <[email-masked]> <[email-masked]>
Message-ID: <[email-masked]>

On Tuesday, November 2, 2004, 4:45:40 PM, MURATA wrote:

MM> On Mon, 1 Nov 2004 20:03:17 +0100
MM> Chris Lilley <[email-masked]> wrote:

>> I was able to discuss this with Murata-san in Tokyo at SVG Open, and he
>> agreed that the +xml convention, plus the deprecation of text/xml and
>> associated charset handling weirdness of required us-ascii fallback,
>> allows consistent handling

MM> No, I did not agree to drop the charset parameter.

What I said was that you agreed that there was consistent handling in
the case where there was no charset parameter.  Do you recall discussing
that over lunch? Jon was there, too.

We also discussed consistent handling of encoding among all media types;
you had earlier stated that this was particularly needed for simple
transcoders that did not know enough about xml not to break it. At that
meeting, I suggested (and you agreed) that the presence of the +xml
convention allowed such transcoders to reliably detect all xml media
types whether the precise media type was recognized or not.

I further suggested (and you seemed to agree) that two types of
processing were desirable:

a) (minimally) xml-aware transcoders - transcode, and update the xml
encoding declaration so that it is consistent
b) xml-unaware transcoders - not break xml well formednes, not transcode
xml
and a third type of processing was undesirable
c) xml unaware transcoders that take well formed documents and make them
malformed.

Transcoders already do something similar, for example they do not
attempt to transcode the bytes of JPEG images.

MM> I did agree to deprecate text/xml.

Yes, that part is already in the next draft (and the other text/* xml
types)

MM> I do believe that image/svg+xml should allow the charset parameter.

So we still have some discussion to do.

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

From: murata at hokkaido.email.ne.jp (MURATA Makoto)
Date: Tue Jan  3 16:22:51 2006
Subject: SVG12: charset parameter for image/svg+xml
In-Reply-To: <[email-masked]>
References: <[email-masked]> <[email-masked]>
Message-ID: <[email-masked]>

On Mon, 1 Nov 2004 20:03:17 +0100
Chris Lilley <[email-masked]> wrote:

> I was able to discuss this with Murata-san in Tokyo at SVG Open, and he
> agreed that the +xml convention, plus the deprecation of text/xml and
> associated charset handling weirdness of required us-ascii fallback,
> allows consistent handling

No, I did not agree to drop the charset parameter.  I did agree 
to deprecate text/xml.

I do believe that image/svg+xml should allow the charset parameter.

Cheers,

-- 
MURATA Makoto <[email-masked]>

From: shollenbeck at verisign.com (Hollenbeck, Scott)
Date: Tue Jan  3 16:22:51 2006
Subject: MIME Type Review Request: text/CSTA-type
Message-ID: <[email-masked]>

Please review the MIME type registration template described below.  The IESG
has received a request to register this MIME type in the standards tree.  It
is a product of Ecma International.  A URL for the formal specification is
included in the template.

-Scott-
----------
MIME media type name: text

MIME subtype name: CSTA-type

Required parameters: (none)

Optional parameters: (none)

Encoding considerations:
This content type uses XML, employing UTF-8 character encoding.

Security considerations:
This content type is designed to carry CSTA data types over network
protocols. Appropriate precautions should be taken to insure that
applications observing these CSTA objects are authorized to do so.

Interoperability considerations:
text/CSTA-type documents are specified by the XML schemas standardized in
ECMA-323.

Published specification:
The published Standard ECMA-323 is available at:
http://www.ecma-international.org/publications/standards/Ecma-323.htm

Applications which use this media type:
The text/CSTA-type MIME type is used to carry CSTA data types specified in
CSTA XML (ECMA-323) over various types of network protocols.

Additional information:
CSTA XML (ECMA-323) is an application level protocol that enables an
application to control and observe communications involving various types of
media (voice calls, video calls, instant messages, Email, SMS, Page, etc.)
and devices associated with the media.

Person & email address to contact for further information:
Ecma Secretariat
Rue du Rhone114
CH-1204 Geneva
Switzerland
[email-masked]

Intended usage: common

Author/change controller:
The ECMA-323 Standard is developed and maintained by the Ecma TC32/TG11
Working Group.

From: shollenbeck at verisign.com (Hollenbeck, Scott)
Date: Tue Nov  2 14:54:49 2004
Subject: MIME Type Review Request: application/csta+xml
Message-ID: <[email-masked]>

Please review the MIME type registration template described below.  The IESG
has received a request to register this MIME type in the standards tree.  It
is a product of Ecma International.  A URL for the formal specification is
included in the template.

-Scott-
----------
MIME media type name: application

MIME subtype name: csta+xml

Required parameters: (none)

Optional parameters: (none)

Encoding considerations:
This content type uses XML, employing UTF-8 character encoding.

Security considerations:
This content type is designed to carry information about users involved with
communications which may be considered private information. For example, the
identity of a calling party in a voice call. This content type is also
designed to be used to control communication calls and communication devices
such as telephones.

Appropriate precautions should be taken to insure that applications
observing and controlling communications and communication devices using
CSTA are authorized to do so.

Interoperability considerations:
application/csta+xml documents are specified by the XML schemas standardized
in ECMA-323.

Published specification:
The published Standard ECMA-323 is available at:
http://www.ecma-international.org/publications/standards/Ecma-323.htm

Applications which use this media type:
The application/csta+xml MIME type can be used to identify CSTA XML
(ECMA-323) instance documents.

Additional information:
CSTA XML (ECMA-323) is an application level protocol that enables an
application to control and observe communications involving various types of
media (voice calls, video calls, instant messages, Email, SMS, Page, etc.)
and devices associated with the media.

Person & email address to contact for further information:
Ecma Secretariat
Rue du Rhone114
CH-1204 Geneva
Switzerland
[email-masked]

Intended usage: common

Author/change controller:
The ECMA-323 Standard is developed and maintained by the Ecma TC32/TG11
Working Group.
>From [email-masked]  Tue Nov  2 14:54:53 2004
From: shollenbeck at verisign.com (Hollenbeck, Scott)
Date: Tue Nov  2 14:54:59 2004
Subject: MIME Type Review Request: text/CSTA-type
Message-ID: <[email-masked]>

Please review the MIME type registration template described below.  The IESG
has received a request to register this MIME type in the standards tree.  It
is a product of Ecma International.  A URL for the formal specification is
included in the template.

-Scott-
----------
MIME media type name: text

MIME subtype name: CSTA-type

Required parameters: (none)

Optional parameters: (none)

Encoding considerations:
This content type uses XML, employing UTF-8 character encoding.

Security considerations:
This content type is designed to carry CSTA data types over network
protocols. Appropriate precautions should be taken to insure that
applications observing these CSTA objects are authorized to do so.

Interoperability considerations:
text/CSTA-type documents are specified by the XML schemas standardized in
ECMA-323.

Published specification:
The published Standard ECMA-323 is available at:
http://www.ecma-international.org/publications/standards/Ecma-323.htm

Applications which use this media type:
The text/CSTA-type MIME type is used to carry CSTA data types specified in
CSTA XML (ECMA-323) over various types of network protocols.

Additional information:
CSTA XML (ECMA-323) is an application level protocol that enables an
application to control and observe communications involving various types of
media (voice calls, video calls, instant messages, Email, SMS, Page, etc.)
and devices associated with the media.

Person & email address to contact for further information:
Ecma Secretariat
Rue du Rhone114
CH-1204 Geneva
Switzerland
[email-masked]

Intended usage: common

Author/change controller:
The ECMA-323 Standard is developed and maintained by the Ecma TC32/TG11
Working Group.
>From [email-masked]  Tue Nov  2 16:45:40 2004
From: murata at hokkaido.email.ne.jp (MURATA Makoto)
Date: Tue Nov  2 16:46:16 2004
Subject: SVG12: charset parameter for image/svg+xml
In-Reply-To: <[email-masked]>
References: <[email-masked]>
	<[email-masked]>
Message-ID: <[email-masked]>

On Mon, 1 Nov 2004 20:03:17 +0100
Chris Lilley <[email-masked]> wrote:

> I was able to discuss this with Murata-san in Tokyo at SVG Open, and he
> agreed that the +xml convention, plus the deprecation of text/xml and
> associated charset handling weirdness of required us-ascii fallback,
> allows consistent handling

No, I did not agree to drop the charset parameter.  I did agree 
to deprecate text/xml.

I do believe that image/svg+xml should allow the charset parameter.

Cheers,

-- 
MURATA Makoto <[email-masked]>

From: shollenbeck at verisign.com (Hollenbeck, Scott)
Date: Tue Jan  3 16:22:51 2006
Subject: MIME Type Review Request: application/csta+xml
Message-ID: <[email-masked]>

Please review the MIME type registration template described below.  The IESG
has received a request to register this MIME type in the standards tree.  It
is a product of Ecma International.  A URL for the formal specification is
included in the template.

-Scott-
----------
MIME media type name: application

MIME subtype name: csta+xml

Required parameters: (none)

Optional parameters: (none)

Encoding considerations:
This content type uses XML, employing UTF-8 character encoding.

Security considerations:
This content type is designed to carry information about users involved with
communications which may be considered private information. For example, the
identity of a calling party in a voice call. This content type is also
designed to be used to control communication calls and communication devices
such as telephones.

Appropriate precautions should be taken to insure that applications
observing and controlling communications and communication devices using
CSTA are authorized to do so.

Interoperability considerations:
application/csta+xml documents are specified by the XML schemas standardized
in ECMA-323.

Published specification:
The published Standard ECMA-323 is available at:
http://www.ecma-international.org/publications/standards/Ecma-323.htm

Applications which use this media type:
The application/csta+xml MIME type can be used to identify CSTA XML
(ECMA-323) instance documents.

Additional information:
CSTA XML (ECMA-323) is an application level protocol that enables an
application to control and observe communications involving various types of
media (voice calls, video calls, instant messages, Email, SMS, Page, etc.)
and devices associated with the media.

Person & email address to contact for further information:
Ecma Secretariat
Rue du Rhone114
CH-1204 Geneva
Switzerland
[email-masked]

Intended usage: common

Author/change controller:
The ECMA-323 Standard is developed and maintained by the Ecma TC32/TG11
Working Group.

From: doug at schepers.cc (Doug Schepers)
Date: Tue Jan  3 16:22:51 2006
Subject: SVG12: charset parameter for image/svg+xml
In-Reply-To: <[email-masked]>
Message-ID: <[email-masked]>

Jim Ley wrote:

<snip>
|
| > Thus, please change the registration to be consistent with 
| > application/ xml as defined in RFC 3023.
| 
| I fully agree with this, I would also like the Working Group 
| to consider registering application/svg+xml with a 
| distinction between image and application being scripting and 
| sXBL within the document.  The reasons, I've raised before, 
| but if you want me to elaborate further, I can do.

I agree with Jim here, with one caveat. The distinction between applications
and images is not quite so clear cut. An author can create a declarative
(SMIL) application, such as a game or interactive documents, that requires
no script. This will be especially true with such features as editable text
(combined with the snaphot save of ASV).

Similarly, you could have sXBL content that does not required scripting, but
will merely render a static or declarative version of some other XML (say,
an org chart). Is this an application? I don't think so; it's merely a
graphical representation of XML data.

Pragmatically speaking, however, I think Jim is correct. For the present,
any SVG document with a 'script' element or reference, be it part of sXBL or
not, should be declared an application; however, what constitutes the
distinction should remain an open issue. I think that the core issue is the
degree of threat posed to the user, and that this should be the real
shibboleth.

Regards-
-Doug 

From: derhoermi at gmx.net (Bjoern Hoehrmann)
Date: Mon Nov  1 22:56:46 2004
Subject: SVG12: charset parameter for image/svg+xml
In-Reply-To: <[email-masked]>
References: <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]>
Message-ID: <[email-masked]>

* Chris Lilley wrote:
>BH> Why does the charset parameter in the example above declare an encoding?
>BH> From http://www.w3.org/TR/2004/WD-SVG12-20041027/mimereg.html it should
>BH> be clear that the is no charset parameter and it thus cannot have such
>BH> semantics, so there is no inconsistency here.
>
>You had not stated your example very carefully. I thought we were still
>talking about what the validator implements.

We are, you said the W3C Markup Validator does not need to be changed
in order to comply with the proposed image/svg+xml registration which
however states that

[...]
  The encoding of an SVG document is determined by the XML encoding
  declaration. This has identical semantics to the application/xml media
  type in the case where the charset parameter is omitted, as specified
  in RFC3023 sections 8.9, 8.10 and 8.11. 
[...]

which is inconsistent with the behavior of the W3C Markup Validator.
>From the proposed registration it seems very clear that the behavior
of the W3C Markup Validator is non-conforming, you say it is never-
theless conforming which makes no sense to me.
>From [email-masked]  Mon Nov  1 21:46:15 2004
From: bzbarsky at MIT.EDU (Boris Zbarsky)
Date: Tue Nov  2 14:04:31 2004
Subject: SVG12: charset parameter for image/svg+xml
In-Reply-To: <[email-masked]>
References: <[email-masked]>
	<[email-masked]>
Message-ID: <[email-masked]>

Chris Lilley wrote:
> On the contrary! The +xml convention clearly indicates, for an unknown
> media type, that it is xml; thus, that an XML processor should be used;
> which will correctly determine the encoding from the xml encoding
> declaration or lack therof.

I think the concern was about what happens when someone sends the 
following HTTP header:

   Content-Type:  image/svg+xml; charset=iso-8859-1

combined with an XML document that has no encoding declaration (so 
defaulting to UTF-8).

Now per the type registration for "image/svg+xml", the above 
Content-Type header is invalid, right?  So what's a UA to do?  What 
encoding to use?  Using UTF-8 means hardcoding knowledge about the fact 
that image/svg+xml, unlike most other character-based types used today, 
doesn't have a charset parameter.

> No, they would not. RFC 3023 already allows the charset to be omitted,
> and gives rules to follow for this case. SVG follows those rules, as the
> registration document makes plain.

The problems arise when there IS a charset parameter.  I don't think 
anyone ever claimed there is a problem when the charset parameter is 
omitted.

>    In general, a representation provider SHOULD NOT specify the
>    character encoding for XML data in protocol headers since the data is
>    self-describing

Given that this is a not a MUST NOT, people will continue to do this in 
some cases (particularly as some web servers automatically tack on a 
"charset" parameter to Content-Type headers).

-Boris
>From [email-masked]  Tue Nov  2 08:58:54 2004
From: doug at schepers.cc (Doug Schepers)
Date: Tue Nov  2 14:04:33 2004
Subject: SVG12: charset parameter for image/svg+xml
In-Reply-To: <[email-masked]>
Message-ID: <[email-masked]>

Jim Ley wrote:

<snip>
|
| > Thus, please change the registration to be consistent with 
| > application/ xml as defined in RFC 3023.
| 
| I fully agree with this, I would also like the Working Group 
| to consider registering application/svg+xml with a 
| distinction between image and application being scripting and 
| sXBL within the document.  The reasons, I've raised before, 
| but if you want me to elaborate further, I can do.

I agree with Jim here, with one caveat. The distinction between applications
and images is not quite so clear cut. An author can create a declarative
(SMIL) application, such as a game or interactive documents, that requires
no script. This will be especially true with such features as editable text
(combined with the snaphot save of ASV).

Similarly, you could have sXBL content that does not required scripting, but
will merely render a static or declarative version of some other XML (say,
an org chart). Is this an application? I don't think so; it's merely a
graphical representation of XML data.

Pragmatically speaking, however, I think Jim is correct. For the present,
any SVG document with a 'script' element or reference, be it part of sXBL or
not, should be declared an application; however, what constitutes the
distinction should remain an open issue. I think that the core issue is the
degree of threat posed to the user, and that this should be the real
shibboleth.

Regards-
-Doug 

From: derhoermi at gmx.net (Bjoern Hoehrmann)
Date: Tue Jan  3 16:22:51 2006
Subject: SVG12: charset parameter for image/svg+xml
In-Reply-To: <[email-masked]>
References: <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]>
Message-ID: <[email-masked]>

* Chris Lilley wrote:
>BH> Why does the charset parameter in the example above declare an encoding?
>BH> From http://www.w3.org/TR/2004/WD-SVG12-20041027/mimereg.html it should
>BH> be clear that the is no charset parameter and it thus cannot have such
>BH> semantics, so there is no inconsistency here.
>
>You had not stated your example very carefully. I thought we were still
>talking about what the validator implements.

We are, you said the W3C Markup Validator does not need to be changed
in order to comply with the proposed image/svg+xml registration which
however states that

[...]
  The encoding of an SVG document is determined by the XML encoding
  declaration. This has identical semantics to the application/xml media
  type in the case where the charset parameter is omitted, as specified
  in RFC3023 sections 8.9, 8.10 and 8.11. 
[...]

which is inconsistent with the behavior of the W3C Markup Validator.
>From the proposed registration it seems very clear that the behavior
of the W3C Markup Validator is non-conforming, you say it is never-
theless conforming which makes no sense to me.

From: chris at w3.org (Chris Lilley)
Date: Tue Jan  3 16:22:51 2006
Subject: SVG12: charset parameter for image/svg+xml
In-Reply-To: <[email-masked]>
References: <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]>
Message-ID: <[email-masked]>

On Monday, November 1, 2004, 10:41:36 PM, Bjoern wrote:

BH> Why does the charset parameter in the example above declare an encoding?
BH> From http://www.w3.org/TR/2004/WD-SVG12-20041027/mimereg.html it should
BH> be clear that the is no charset parameter and it thus cannot have such
BH> semantics, so there is no inconsistency here.

You had not stated your example very carefully. I thought we were still
talking about what the validator implements.

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

From: derhoermi at gmx.net (Bjoern Hoehrmann)
Date: Mon Nov  1 22:42:04 2004
Subject: SVG12: charset parameter for image/svg+xml
In-Reply-To: <[email-masked]>
References: <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]>
Message-ID: <[email-masked]>

* Chris Lilley wrote:
>>>BH> The W3C Markup Validator considers resources such as
>>>
>>>BH>   Content-Type: image/svg+xml;charset=iso-8859-1
>>>
>>>BH>   <?xml version='1.0' encoding='utf-8'?>
>>>BH>   ...
>>>
>>>BH> ISO-8859-1 encoded.
>>>
>>>Yes, there are two inconsistent pieces of metadata and the markup
>>>validator correctly applies the rules to determine which to use.
>
>BH> What makes you think there is inconsistent metadata here?
>
>The encoding is declared in two places, and they are different. One is
>the charset parameter, and one is the xml encoding declaration.

Why does the charset parameter in the example above declare an encoding?
>From http://www.w3.org/TR/2004/WD-SVG12-20041027/mimereg.html it should
be clear that the is no charset parameter and it thus cannot have such
semantics, so there is no inconsistency here.
>From [email-masked]  Mon Nov  1 22:48:10 2004
From: chris at w3.org (Chris Lilley)
Date: Mon Nov  1 22:48:17 2004
Subject: SVG12: charset parameter for image/svg+xml
In-Reply-To: <[email-masked]>
References: <[email-masked]>
	<[email-masked]>
	<[email-masked]>
	<[email-masked]>
	<[email-masked]>
	<[email-masked]>
	<[email-masked]>
Message-ID: <[email-masked]>

On Monday, November 1, 2004, 10:41:36 PM, Bjoern wrote:

BH> Why does the charset parameter in the example above declare an encoding?
BH> From http://www.w3.org/TR/2004/WD-SVG12-20041027/mimereg.html it should
BH> be clear that the is no charset parameter and it thus cannot have such
BH> semantics, so there is no inconsistency here.

You had not stated your example very carefully. I thought we were still
talking about what the validator implements.

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

From: derhoermi at gmx.net (Bjoern Hoehrmann)
Date: Tue Jan  3 16:22:51 2006
Subject: SVG12: charset parameter for image/svg+xml
In-Reply-To: <[email-masked]>
References: <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]>
Message-ID: <[email-masked]>

* Chris Lilley wrote:
>>>BH> The W3C Markup Validator considers resources such as
>>>
>>>BH>   Content-Type: image/svg+xml;charset=iso-8859-1
>>>
>>>BH>   <?xml version='1.0' encoding='utf-8'?>
>>>BH>   ...
>>>
>>>BH> ISO-8859-1 encoded.
>>>
>>>Yes, there are two inconsistent pieces of metadata and the markup
>>>validator correctly applies the rules to determine which to use.
>
>BH> What makes you think there is inconsistent metadata here?
>
>The encoding is declared in two places, and they are different. One is
>the charset parameter, and one is the xml encoding declaration.

Why does the charset parameter in the example above declare an encoding?
>From http://www.w3.org/TR/2004/WD-SVG12-20041027/mimereg.html it should
be clear that the is no charset parameter and it thus cannot have such
semantics, so there is no inconsistency here.

From: chris at w3.org (Chris Lilley)
Date: Tue Jan  3 16:22:51 2006
Subject: SVG12: charset parameter for image/svg+xml
In-Reply-To: <[email-masked]>
References: <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]>
Message-ID: <[email-masked]>

On Monday, November 1, 2004, 10:19:01 PM, Bjoern wrote:

BH> * Chris Lilley wrote:
>>BH> The W3C Markup Validator considers resources such as
>>
>>BH>   Content-Type: image/svg+xml;charset=iso-8859-1
>>
>>BH>   <?xml version='1.0' encoding='utf-8'?>
>>BH>   ...
>>
>>BH> ISO-8859-1 encoded.
>>
>>Yes, there are two inconsistent pieces of metadata and the markup
>>validator correctly applies the rules to determine which to use.

BH> What makes you think there is inconsistent metadata here?

The encoding is declared in two places, and they are different. One is
the charset parameter, and one is the xml encoding declaration.

BH> The charset parameter in the example above has no semantics that
BH> could be inconsistent with other information.

Its clearly inconsistent! The encoding declaration has the same
semantic. It agree that there is a mechanism to *resolve* the ambiguity,
but the inconsistency is clearly there.

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

From: derhoermi at gmx.net (Bjoern Hoehrmann)
Date: Mon Nov  1 22:19:29 2004
Subject: SVG12: charset parameter for image/svg+xml
In-Reply-To: <[email-masked]>
References: <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]>
Message-ID: <[email-masked]>

* Chris Lilley wrote:
>BH> The W3C Markup Validator considers resources such as
>
>BH>   Content-Type: image/svg+xml;charset=iso-8859-1
>
>BH>   <?xml version='1.0' encoding='utf-8'?>
>BH>   ...
>
>BH> ISO-8859-1 encoded.
>
>Yes, there are two inconsistent pieces of metadata and the markup
>validator correctly applies the rules to determine which to use.

What makes you think there is inconsistent metadata here? The
charset parameter in the example above has no semantics that
could be inconsistent with other information.
>From [email-masked]  Mon Nov  1 22:35:42 2004
From: chris at w3.org (Chris Lilley)
Date: Mon Nov  1 22:35:46 2004
Subject: SVG12: charset parameter for image/svg+xml
In-Reply-To: <[email-masked]>
References: <[email-masked]>
	<[email-masked]>
	<[email-masked]>
	<[email-masked]>
	<[email-masked]>
Message-ID: <[email-masked]>

On Monday, November 1, 2004, 10:19:01 PM, Bjoern wrote:

BH> * Chris Lilley wrote:
>>BH> The W3C Markup Validator considers resources such as
>>
>>BH>   Content-Type: image/svg+xml;charset=iso-8859-1
>>
>>BH>   <?xml version='1.0' encoding='utf-8'?>
>>BH>   ...
>>
>>BH> ISO-8859-1 encoded.
>>
>>Yes, there are two inconsistent pieces of metadata and the markup
>>validator correctly applies the rules to determine which to use.

BH> What makes you think there is inconsistent metadata here?

The encoding is declared in two places, and they are different. One is
the charset parameter, and one is the xml encoding declaration.

BH> The charset parameter in the example above has no semantics that
BH> could be inconsistent with other information.

Its clearly inconsistent! The encoding declaration has the same
semantic. It agree that there is a mechanism to *resolve* the ambiguity,
but the inconsistency is clearly there.

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

From: derhoermi at gmx.net (Bjoern Hoehrmann)
Date: Tue Jan  3 16:22:51 2006
Subject: SVG12: charset parameter for image/svg+xml
In-Reply-To: <[email-masked]>
References: <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]>
Message-ID: <[email-masked]>

* Chris Lilley wrote:
>BH> The W3C Markup Validator considers resources such as
>
>BH>   Content-Type: image/svg+xml;charset=iso-8859-1
>
>BH>   <?xml version='1.0' encoding='utf-8'?>
>BH>   ...
>
>BH> ISO-8859-1 encoded.
>
>Yes, there are two inconsistent pieces of metadata and the markup
>validator correctly applies the rules to determine which to use.

What makes you think there is inconsistent metadata here? The
charset parameter in the example above has no semantics that
could be inconsistent with other information.

From: chris at w3.org (Chris Lilley)
Date: Mon Nov  1 22:02:44 2004
Subject: SVG12: charset parameter for image/svg+xml
In-Reply-To: <[email-masked]>
References: <[email-masked]> <[email-masked]> <[email-masked]>
Message-ID: <[email-masked]>

On Monday, November 1, 2004, 9:46:15 PM, Boris wrote:

BZ> Chris Lilley wrote:
>> On the contrary! The +xml convention clearly indicates, for an unknown
>> media type, that it is xml; thus, that an XML processor should be used;
>> which will correctly determine the encoding from the xml encoding
>> declaration or lack therof.

BZ> I think the concern was about what happens when someone sends the 
BZ> following HTTP header:

BZ>    Content-Type:  image/svg+xml; charset=iso-8859-1

BZ> combined with an XML document that has no encoding declaration (so 
BZ> defaulting to UTF-8).

That is (for a random +xml media type) currently allowed. It is, as you
say, a problem. (It defaults to UTF-8 or UTF-16 depending on the
presence of absence of a BOM and, if present, what bytes represent it).

BZ> Now per the type registration for "image/svg+xml", the above 
BZ> Content-Type header is invalid, right?

Yes. Instead of an optional parameter which should not be used and if
used, causes problems, the proposal is to not have the parameter.

BZ>  So what's a UA to do?  What encoding to use?

Under which rules? Currently, that is a malformed document that has been
temporarily made well formed while in transit. If saved, it needs to be
rewritten (some implementations do this, most do not). Note that if the
document used DSig, that would actually break it.

BZ>  Using UTF-8 means hardcoding knowledge about the fact
BZ> that image/svg+xml, unlike most other character-based types used today,
BZ> doesn't have a charset parameter.

No, it doesn't. This is not specific to SVG, it could (and should) be
adopted by any non-text +xml registration.

>> No, they would not. RFC 3023 already allows the charset to be omitted,
>> and gives rules to follow for this case. SVG follows those rules, as the
>> registration document makes plain.

BZ> The problems arise when there IS a charset parameter.

Exactly. The code path for when there isn't one is well implemented and
interoperable, today.

BZ>   I don't think
BZ> anyone ever claimed there is a problem when the charset parameter is
BZ> omitted.

Correct. There is no problem when its omitted, for SVG or for anything
else.

>>    In general, a representation provider SHOULD NOT specify the
>>    character encoding for XML data in protocol headers since the data is
>>    self-describing

BZ> Given that this is a not a MUST NOT,

Its a should not, because for text/* you have to unless your data is
guaranteed to always be US-ASCII (and even then, it is required to fall
back to text/plain; charset=us-ascii) and because it was not desired to
force a change on legacy formats, just to stop the problem spreading to
new formats.

BZ> people will continue to do this in
BZ> some cases (particularly as some web servers automatically tack on a
BZ> "charset" parameter to Content-Type headers).

Which leads us to

  Server software designers SHOULD NOT specify a default Internet media
  type in the default configuration shipped with the server.
  http://www.w3.org/2001/tag/doc/mime-respect.html#self-describing

Some web servers do that, agreed. Including the W3C one. Its wrong, and
it causes pain.

Some of that is because of the requirements of the text/* media type
tree. For XML, that is being dealt with in the RFC 3023 revision by
deprecating text/xml.

-- 
 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:51 2006
Subject: SVG12: charset parameter for image/svg+xml
In-Reply-To: <[email-masked]>
References: <[email-masked]> <[email-masked]> <[email-masked]>
Message-ID: <[email-masked]>

On Monday, November 1, 2004, 9:46:15 PM, Boris wrote:

BZ> Chris Lilley wrote:
>> On the contrary! The +xml convention clearly indicates, for an unknown
>> media type, that it is xml; thus, that an XML processor should be used;
>> which will correctly determine the encoding from the xml encoding
>> declaration or lack therof.

BZ> I think the concern was about what happens when someone sends the 
BZ> following HTTP header:

BZ>    Content-Type:  image/svg+xml; charset=iso-8859-1

BZ> combined with an XML document that has no encoding declaration (so 
BZ> defaulting to UTF-8).

That is (for a random +xml media type) currently allowed. It is, as you
say, a problem. (It defaults to UTF-8 or UTF-16 depending on the
presence of absence of a BOM and, if present, what bytes represent it).

BZ> Now per the type registration for "image/svg+xml", the above 
BZ> Content-Type header is invalid, right?

Yes. Instead of an optional parameter which should not be used and if
used, causes problems, the proposal is to not have the parameter.

BZ>  So what's a UA to do?  What encoding to use?

Under which rules? Currently, that is a malformed document that has been
temporarily made well formed while in transit. If saved, it needs to be
rewritten (some implementations do this, most do not). Note that if the
document used DSig, that would actually break it.

BZ>  Using UTF-8 means hardcoding knowledge about the fact
BZ> that image/svg+xml, unlike most other character-based types used today,
BZ> doesn't have a charset parameter.

No, it doesn't. This is not specific to SVG, it could (and should) be
adopted by any non-text +xml registration.

>> No, they would not. RFC 3023 already allows the charset to be omitted,
>> and gives rules to follow for this case. SVG follows those rules, as the
>> registration document makes plain.

BZ> The problems arise when there IS a charset parameter.

Exactly. The code path for when there isn't one is well implemented and
interoperable, today.

BZ>   I don't think
BZ> anyone ever claimed there is a problem when the charset parameter is
BZ> omitted.

Correct. There is no problem when its omitted, for SVG or for anything
else.

>>    In general, a representation provider SHOULD NOT specify the
>>    character encoding for XML data in protocol headers since the data is
>>    self-describing

BZ> Given that this is a not a MUST NOT,

Its a should not, because for text/* you have to unless your data is
guaranteed to always be US-ASCII (and even then, it is required to fall
back to text/plain; charset=us-ascii) and because it was not desired to
force a change on legacy formats, just to stop the problem spreading to
new formats.

BZ> people will continue to do this in
BZ> some cases (particularly as some web servers automatically tack on a
BZ> "charset" parameter to Content-Type headers).

Which leads us to

  Server software designers SHOULD NOT specify a default Internet media
  type in the default configuration shipped with the server.
  http://www.w3.org/2001/tag/doc/mime-respect.html#self-describing

Some web servers do that, agreed. Including the W3C one. Its wrong, and
it causes pain.

Some of that is because of the requirements of the text/* media type
tree. For XML, that is being dealt with in the RFC 3023 revision by
deprecating text/xml.

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

From: bzbarsky at MIT.EDU (Boris Zbarsky)
Date: Tue Jan  3 16:22:51 2006
Subject: SVG12: charset parameter for image/svg+xml
In-Reply-To: <[email-masked]>
References: <[email-masked]> <[email-masked]>
Message-ID: <[email-masked]>

Chris Lilley wrote:
> On the contrary! The +xml convention clearly indicates, for an unknown
> media type, that it is xml; thus, that an XML processor should be used;
> which will correctly determine the encoding from the xml encoding
> declaration or lack therof.

I think the concern was about what happens when someone sends the 
following HTTP header:

   Content-Type:  image/svg+xml; charset=iso-8859-1

combined with an XML document that has no encoding declaration (so 
defaulting to UTF-8).

Now per the type registration for "image/svg+xml", the above 
Content-Type header is invalid, right?  So what's a UA to do?  What 
encoding to use?  Using UTF-8 means hardcoding knowledge about the fact 
that image/svg+xml, unlike most other character-based types used today, 
doesn't have a charset parameter.

> No, they would not. RFC 3023 already allows the charset to be omitted,
> and gives rules to follow for this case. SVG follows those rules, as the
> registration document makes plain.

The problems arise when there IS a charset parameter.  I don't think 
anyone ever claimed there is a problem when the charset parameter is 
omitted.

>    In general, a representation provider SHOULD NOT specify the
>    character encoding for XML data in protocol headers since the data is
>    self-describing

Given that this is a not a MUST NOT, people will continue to do this in 
some cases (particularly as some web servers automatically tack on a 
"charset" parameter to Content-Type headers).

-Boris

From: chris at w3.org (Chris Lilley)
Date: Tue Jan  3 16:22:51 2006
Subject: SVG12: charset parameter for image/svg+xml
In-Reply-To: <[email-masked]>
References: <[email-masked]> <[email-masked]> <[email-masked]>
Message-ID: <[email-masked]>

On Monday, November 1, 2004, 9:14:02 PM, Bjoern wrote:

BH> * Chris Lilley wrote:
>>BH>  which is expensive and unlikely to happen. In fact, a number
>>BH> of deployed tools already don't do that, for example the W3C Markup
>>BH> Validator would need to be updated with special code for image/svg+xml
>>BH> in order to comply with the registration.
>>
>>Incorrect; see above.

BH> The W3C Markup Validator considers resources such as

BH>   Content-Type: image/svg+xml;charset=iso-8859-1

BH>   <?xml version='1.0' encoding='utf-8'?>
BH>   ...

BH> ISO-8859-1 encoded.

Yes, there are two inconsistent pieces of metadata and the markup
validator correctly applies the rules to determine which to use. Note
that the example above, if saved to disk and re-opened, is not well
formed. This is undesirable. Lots of content is processed from local
disk, on servers and on clients.

The markup validator does the correct thing also in this case

Content-Type: image/svg+xml

  <?xml version='1.0' encoding='utf-8'?>
  ...

  and this one

Content-Type: image/svg+xml

  <?xml version='1.0'?>
  ...

  and this one

Content-Type: image/svg+xml

  <?xml version='1.0' encoding="koi-8-r"?>
  ...  

  as per RFC 3023.
  
BH> If it is incorrect that the W3C Markup Validator needs to change you
BH> either want that all processors treat the resource ISO-8859-1
BH> encoded in which case there is not really a point in not allowing an
BH> optional charset parameter,

I agree, there is no point in an optional charset parameter. Thats why
the registration for svg doesn't have one.

BH> or you want two classes of non- interoperable processors, where some
BH> consider it ISO-8859-1 and others consider it UTF-8. Which one is
BH> it?

That is the current situation, yes. Some processors do one and some do
the other. As you note, its undesirable. As you note, I don't want this.

The TAG would like to see mutually inconsistent duplicate metadata
reduced or eliminated.

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

From: derhoermi at gmx.net (Bjoern Hoehrmann)
Date: Mon Nov  1 21:14:29 2004
Subject: SVG12: charset parameter for image/svg+xml
In-Reply-To: <[email-masked]>
References: <[email-masked]> <[email-masked]>
Message-ID: <[email-masked]>

* Chris Lilley wrote:
>BH>  which is expensive and unlikely to happen. In fact, a number
>BH> of deployed tools already don't do that, for example the W3C Markup
>BH> Validator would need to be updated with special code for image/svg+xml
>BH> in order to comply with the registration.
>
>Incorrect; see above.

The W3C Markup Validator considers resources such as

  Content-Type: image/svg+xml;charset=iso-8859-1

  <?xml version='1.0' encoding='utf-8'?>
  ...

ISO-8859-1 encoded. If it is incorrect that the W3C Markup Validator
needs to change you either want that all processors treat the resource
ISO-8859-1 encoded in which case there is not really a point in not
allowing an optional charset parameter, or you want two classes of non-
interoperable processors, where some consider it ISO-8859-1 and others
consider it UTF-8. Which one is it?
>From [email-masked]  Mon Nov  1 21:39:09 2004
From: chris at w3.org (Chris Lilley)
Date: Mon Nov  1 21:39:14 2004
Subject: SVG12: charset parameter for image/svg+xml
In-Reply-To: <[email-masked]>
References: <[email-masked]>
	<[email-masked]>
	<[email-masked]>
Message-ID: <[email-masked]>

On Monday, November 1, 2004, 9:14:02 PM, Bjoern wrote:

BH> * Chris Lilley wrote:
>>BH>  which is expensive and unlikely to happen. In fact, a number
>>BH> of deployed tools already don't do that, for example the W3C Markup
>>BH> Validator would need to be updated with special code for image/svg+xml
>>BH> in order to comply with the registration.
>>
>>Incorrect; see above.

BH> The W3C Markup Validator considers resources such as

BH>   Content-Type: image/svg+xml;charset=iso-8859-1

BH>   <?xml version='1.0' encoding='utf-8'?>
BH>   ...

BH> ISO-8859-1 encoded.

Yes, there are two inconsistent pieces of metadata and the markup
validator correctly applies the rules to determine which to use. Note
that the example above, if saved to disk and re-opened, is not well
formed. This is undesirable. Lots of content is processed from local
disk, on servers and on clients.

The markup validator does the correct thing also in this case

Content-Type: image/svg+xml

  <?xml version='1.0' encoding='utf-8'?>
  ...

  and this one

Content-Type: image/svg+xml

  <?xml version='1.0'?>
  ...

  and this one

Content-Type: image/svg+xml

  <?xml version='1.0' encoding="koi-8-r"?>
  ...  

  as per RFC 3023.
  
BH> If it is incorrect that the W3C Markup Validator needs to change you
BH> either want that all processors treat the resource ISO-8859-1
BH> encoded in which case there is not really a point in not allowing an
BH> optional charset parameter,

I agree, there is no point in an optional charset parameter. Thats why
the registration for svg doesn't have one.

BH> or you want two classes of non- interoperable processors, where some
BH> consider it ISO-8859-1 and others consider it UTF-8. Which one is
BH> it?

That is the current situation, yes. Some processors do one and some do
the other. As you note, its undesirable. As you note, I don't want this.

The TAG would like to see mutually inconsistent duplicate metadata
reduced or eliminated.

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

From: derhoermi at gmx.net (Bjoern Hoehrmann)
Date: Tue Jan  3 16:22:51 2006
Subject: SVG12: charset parameter for image/svg+xml
In-Reply-To: <[email-masked]>
References: <[email-masked]> <[email-masked]>
Message-ID: <[email-masked]>

* Chris Lilley wrote:
>BH>  which is expensive and unlikely to happen. In fact, a number
>BH> of deployed tools already don't do that, for example the W3C Markup
>BH> Validator would need to be updated with special code for image/svg+xml
>BH> in order to comply with the registration.
>
>Incorrect; see above.

The W3C Markup Validator considers resources such as

  Content-Type: image/svg+xml;charset=iso-8859-1

  <?xml version='1.0' encoding='utf-8'?>
  ...

ISO-8859-1 encoded. If it is incorrect that the W3C Markup Validator
needs to change you either want that all processors treat the resource
ISO-8859-1 encoded in which case there is not really a point in not
allowing an optional charset parameter, or you want two classes of non-
interoperable processors, where some consider it ISO-8859-1 and others
consider it UTF-8. Which one is it?

From: chris at w3.org (Chris Lilley)
Date: Mon Nov  1 20:03:24 2004
Subject: SVG12: charset parameter for image/svg+xml
In-Reply-To: <[email-masked]>
References: <[email-masked]>
Message-ID: <[email-masked]>

On Monday, November 1, 2004, 2:49:32 AM, Bjoern wrote:

BH> Dear Scalable Vector Graphics Working Group,

BH>   http://www.w3.org/TR/2004/WD-SVG12-20041027/mimereg.html attempts to
BH> register the "image/svg+xml" MIME Type but the registration lacks the
BH> charset parameter as defined in RFC 3023. This defeats the purpose of
BH> the +xml convention which attempts to provide a means for generic XML
BH> processing.

On the contrary! The +xml convention clearly indicates, for an unknown
media type, that it is xml; thus, that an XML processor should be used;
which will correctly determine the encoding from the xml encoding
declaration or lack therof.

I was able to discuss this with Murata-san in Tokyo at SVG Open, and he
agreed that the +xml convention, plus the deprecation of text/xml and
associated charset handling weirdness of required us-ascii fallback,
allows consistent handling

BH> Generic XML tools such as Validators, Editors, XSLT and XQuery
BH> processors, and full-text XML search engines would need to maintain
BH> special knowledge to ignore the charset parameter for image/svg+xml
BH> documents

No, they would not. RFC 3023 already allows the charset to be omitted,
and gives rules to follow for this case. SVG follows those rules, as the
registration document makes plain.

However, if such a parameter were to be added, anything that downloaded
an SVG document (or any other type of document that used a charset
parameter) would have to know to change the encoding declaration in the
xml - otherwise it would be on well formed when read from local disk.
this is expensive and unlikely to happen.

BH>  which is expensive and unlikely to happen. In fact, a number
BH> of deployed tools already don't do that, for example the W3C Markup
BH> Validator would need to be updated with special code for image/svg+xml
BH> in order to comply with the registration.

Incorrect; see above.

BH> Thus, please change the registration to be consistent with application/
BH> xml as defined in RFC 3023.

In fact it is consistent already, but refers to specific cases while
excluding other cases.

Speaking as one of the co-editors of the revision to RFC 3023, which
removes this requirement and deprecates text/xml, thus bringing it into
line with the good practice notes in the AWWW document:

http://www.w3.org/TR/2004/WD-webarch-20040816/Overview.html#xml-media-types

 Good practice: XML and "text/*"

  In general, a representation provider SHOULD NOT assign Internet media
  types beginning with "text/" to XML representations

 Good practice: XML and character encodings

   In general, a representation provider SHOULD NOT specify the
   character encoding for XML data in protocol headers since the data is
   self-describing

I can confirm that the idea is to apply this more generally.

In other words, the omission of the charset parameter was not an
oversight; it was a deliberate design choice following discussions in
the TAG over the last year and a half.

-- 
 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:51 2006
Subject: SVG12: charset parameter for image/svg+xml
In-Reply-To: <[email-masked]>
References: <[email-masked]>
Message-ID: <[email-masked]>

On Monday, November 1, 2004, 2:49:32 AM, Bjoern wrote:

BH> Dear Scalable Vector Graphics Working Group,

BH>   http://www.w3.org/TR/2004/WD-SVG12-20041027/mimereg.html attempts to
BH> register the "image/svg+xml" MIME Type but the registration lacks the
BH> charset parameter as defined in RFC 3023. This defeats the purpose of
BH> the +xml convention which attempts to provide a means for generic XML
BH> processing.

On the contrary! The +xml convention clearly indicates, for an unknown
media type, that it is xml; thus, that an XML processor should be used;
which will correctly determine the encoding from the xml encoding
declaration or lack therof.

I was able to discuss this with Murata-san in Tokyo at SVG Open, and he
agreed that the +xml convention, plus the deprecation of text/xml and
associated charset handling weirdness of required us-ascii fallback,
allows consistent handling

BH> Generic XML tools such as Validators, Editors, XSLT and XQuery
BH> processors, and full-text XML search engines would need to maintain
BH> special knowledge to ignore the charset parameter for image/svg+xml
BH> documents

No, they would not. RFC 3023 already allows the charset to be omitted,
and gives rules to follow for this case. SVG follows those rules, as the
registration document makes plain.

However, if such a parameter were to be added, anything that downloaded
an SVG document (or any other type of document that used a charset
parameter) would have to know to change the encoding declaration in the
xml - otherwise it would be on well formed when read from local disk.
this is expensive and unlikely to happen.

BH>  which is expensive and unlikely to happen. In fact, a number
BH> of deployed tools already don't do that, for example the W3C Markup
BH> Validator would need to be updated with special code for image/svg+xml
BH> in order to comply with the registration.

Incorrect; see above.

BH> Thus, please change the registration to be consistent with application/
BH> xml as defined in RFC 3023.

In fact it is consistent already, but refers to specific cases while
excluding other cases.

Speaking as one of the co-editors of the revision to RFC 3023, which
removes this requirement and deprecates text/xml, thus bringing it into
line with the good practice notes in the AWWW document:

http://www.w3.org/TR/2004/WD-webarch-20040816/Overview.html#xml-media-types

 Good practice: XML and "text/*"

  In general, a representation provider SHOULD NOT assign Internet media
  types beginning with "text/" to XML representations

 Good practice: XML and character encodings

   In general, a representation provider SHOULD NOT specify the
   character encoding for XML data in protocol headers since the data is
   self-describing

I can confirm that the idea is to apply this more generally.

In other words, the omission of the charset parameter was not an
oversight; it was a deliberate design choice following discussions in
the TAG over the last year and a half.

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

From: iana at iana.org ([email-masked])
Date: Mon Nov  1 04:56:47 2004
Subject: ConfirmSystem: [email-masked] [[ca7128ef62ae0fe9]]
Message-ID: <[email-masked]>

Thank you for your message.

The [email-masked] address collects a tremendous amount of spam, and we
have been forced to implement protective measures.  In order to process
your message we need to confirm that it came from a real email address. 
To confirm your message, you can either:

  1) Reply to this message, without altering the subject line 
    The "Re: " added by many mail clients is OK, but please note
    that this method is *not* foolproof.  

or

  2) Visit the URL
        <http://confirm.icann.org/?s=ca7128ef62ae0fe9&l=[email-masked]>

If you want to be very sure that your message gets through, do both steps
above -- it does no harm to confirm more than once.

For your reference, the subject of the message you sent was:

  "{Filename?} Re:"
       
and it arrived at IANA approximately at Sun Oct 31 19:56:37 2004.

---------------------------------------------------------------
ConfirmSystem: [email-masked] [[ca7128ef62ae0fe9]]
1

From: iana at iana.org ([email-masked])
Date: Tue Jan  3 16:22:51 2006
Subject: ConfirmSystem: [email-masked] [[ca7128ef62ae0fe9]]
Message-ID: <[email-masked]>

Thank you for your message.

The [email-masked] address collects a tremendous amount of spam, and we
have been forced to implement protective measures.  In order to process
your message we need to confirm that it came from a real email address. 
To confirm your message, you can either:

  1) Reply to this message, without altering the subject line 
    The "Re: " added by many mail clients is OK, but please note
    that this method is *not* foolproof.  

or

  2) Visit the URL
        <http://confirm.icann.org/?s=ca7128ef62ae0fe9&l=[email-masked]>

If you want to be very sure that your message gets through, do both steps
above -- it does no harm to confirm more than once.

For your reference, the subject of the message you sent was:

  "{Filename?} Re:"
       
and it arrived at IANA approximately at Sun Oct 31 19:56:37 2004.

---------------------------------------------------------------
ConfirmSystem: [email-masked] [[ca7128ef62ae0fe9]]
1

From: jim at jibbering.com (Jim Ley)
Date: Tue Jan  3 16:22:51 2006
Subject: SVG12: charset parameter for image/svg+xml
References: <[email-masked]>
Message-ID: <[email-masked]>

"Bjoern Hoehrmann" <[email-masked]> wrote in message 
news:[email-masked]...
>  http://www.w3.org/TR/2004/WD-SVG12-20041027/mimereg.html attempts to
> register the "image/svg+xml" MIME Type but the registration lacks the
> charset parameter as defined in RFC 3023. This defeats the purpose of
> the +xml convention which attempts to provide a means for generic XML
> processing.
>
> Thus, please change the registration to be consistent with application/
> xml as defined in RFC 3023.

I fully agree with this, I would also like the Working Group to consider 
registering application/svg+xml with a distinction between image and 
application being scripting and sXBL within the document.  The reasons, I've 
raised before, but if you want me to elaborate further, I can do.

Cheers.

Jim. 

From: derhoermi at gmx.net (Bjoern Hoehrmann)
Date: Mon Nov  1 02:50:03 2004
Subject: SVG12: charset parameter for image/svg+xml
Message-ID: <[email-masked]>

Dear Scalable Vector Graphics Working Group,

  http://www.w3.org/TR/2004/WD-SVG12-20041027/mimereg.html attempts to
register the "image/svg+xml" MIME Type but the registration lacks the
charset parameter as defined in RFC 3023. This defeats the purpose of
the +xml convention which attempts to provide a means for generic XML
processing.

Generic XML tools such as Validators, Editors, XSLT and XQuery
processors, and full-text XML search engines would need to maintain
special knowledge to ignore the charset parameter for image/svg+xml
documents which is expensive and unlikely to happen. In fact, a number
of deployed tools already don't do that, for example the W3C Markup
Validator would need to be updated with special code for image/svg+xml
in order to comply with the registration.

Thus, please change the registration to be consistent with application/
xml as defined in RFC 3023.

regards.
>From [email-masked]  Mon Nov  1 03:58:12 2004
From: jim at jibbering.com (Jim Ley)
Date: Mon Nov  1 04:00:44 2004
Subject: SVG12: charset parameter for image/svg+xml
References: <[email-masked]>
Message-ID: <[email-masked]>

"Bjoern Hoehrmann" <[email-masked]> wrote in message 
news:[email-masked]...
>  http://www.w3.org/TR/2004/WD-SVG12-20041027/mimereg.html attempts to
> register the "image/svg+xml" MIME Type but the registration lacks the
> charset parameter as defined in RFC 3023. This defeats the purpose of
> the +xml convention which attempts to provide a means for generic XML
> processing.
>
> Thus, please change the registration to be consistent with application/
> xml as defined in RFC 3023.

I fully agree with this, I would also like the Working Group to consider 
registering application/svg+xml with a distinction between image and 
application being scripting and sXBL within the document.  The reasons, I've 
raised before, but if you want me to elaborate further, I can do.

Cheers.

Jim.