- Ietf-types - example.com

draft-taylor-example-media-types-01.xml
by Tom-PT Taylor 30 Mar '06

30 Mar '06

Since I have received no further comments on the example media type draft, I have added the following sentence to the introduction as I indicated I would do. When it appears, I will forward it to the IESG. "It is suggested that compilers of illustrative examples involving media types in trees other than the standards tree might also incorporate the string "example" into their hypothetical media types." Tom Taylor

1 0

Comments solicited on application/cellml+xml
by Andrew Miller 28 Mar '06

28 Mar '06

Dear all, I am proposing that the MIME media type application/cellml+xml be used for CellML documents. Please see the Internet draft draft-miller-media-type-cellml-00.txt, available at http://www.ietf.org/internet-drafts/draft-miller-media-type-cellml-00.txt, for the full registration. Any comments are welcome, please send them to ak.miller(a)auckland.ac.nz. If there are no objections, the document will be submitted to IESG for approval on the Wednesday the 12th of April, 2006. Best regards, Andrew Miller ---------------------------------------------------------------- This message was sent using IMP, the Internet Messaging Program.

3 3

Review of draft-westerlund-mime-dls-01
by Tom-PT Taylor 27 Mar '06

27 Mar '06

The subject draft is a reasonable contribution to the are of Internet engineering which it covers. It has editorial issues which should be fixed before it is approved. The major issue is that, despite the presence of an acceptable Security Considerations section (section 2), the registration in section 3.1 points to the Security Considerations section of RFC XXXX. Section 4 is an RFC Editor's note requesting the substitution of the proper number for RFC XXXX. There is no RFC XXXX in the references. Undoubtedly this was the result of a change of plan. I had two minor editorial comments: In section 2, third paragraph, third line, the phrase "it is stressed" caused a momentary glitch in my mind: "Where is it stressed?". Perhaps the sentence might read better if it were phrased: "A key point is that conditional chunks are optional, that is to say a parser does not have to execute a conditional chunk." The other item is an extra "the" in the first line of "Interoperability Considerations" in section 3.1. Tom Taylor

3 2

RE: Charset mandatory in unix/linux
by Misha Wolf 27 Mar '06

27 Mar '06

[John Cowan has writtten this reply to Bruce's mail and has given me permission to forward it. Misha] > These typically (and specifically for tar and zip) do not include > media type information or charset or other type parameter information. > The information in the tar format, for example, carries time stamps, > permissions, and file type (where "type" means plain file vs. directory > vs. device, etc.). ZIP format, however, has the ability to store extended attributes, though this is normally only used on VMS and OS/2 systems. See http://www.info-zip.org/pub/infozip/doc/appnote-iz-latest.zip for the details. > The holy grail of a single unified character set that will supposedly > solve the problem sounds nice until one looks at the details. I think this line, and the rant which follows, is a serious exaggeration of the facts. > "Unicode" is itself a "vast array" (ever-increasing in number) of > character code sets. Saying "Unicode" doesn't tell me if that's > pre-"Korean mess" (see RFC 2279) "Unicode" or post-"Korean mess" > "Unicode". The pre-Korean-mess versions (1.0 and 1.1) do in fact have their own charsets: Unicode-1-1 and Unicode-1-1-UTF-8. However, no one has ever come forward with actual text encoded in anger that contains pre-mess Korean syllables, so it's almost entirely academic. > Or whether that's the "Unicode" that has among its design principles > a uniform code width of 16 bits and an encoding strictly of text > (specifically excluding musical notation), or the "Unicode" that has a > much wider code width and includes non-textual cruft such as (yes, you > guessed it) musical notation. Or whether it's one of the "Unicode"s > that has an attempt at encoding language information (versions 3.1 > and 3.2), or one of the "Unicode"s (earlier and later) that do not. > And so on. All this is about one thing and one thing only: what characters your implementation can handle. If you have an old 8-bit or 16-bit implementation trying to process text involving new characters, it won't know what to make of them, but it won't be seriously confused. New implementations can of course handle old text fine using their more advanced models, because everything is backward compatible. As for language tagging in plain text, it was demanded by an IETF WG, was in effect born deprecated, and is formally deprecated as of 4.0 but of course remains present and will forever. > as far as I know, it's not even possible to have multiple versions of > Unicode and to transcode between them on the same machine. It's not possible because (other than the Korean mess) it's not necessary either. > [S]uppose Jacob has received a text file in Korean and the issue of > labeling the charset and language is solved. If it is labeled as > "ISO-2022-KR", he can proceed to make sense of the file; conversely > if it is labeled as "utf-7" he cannot because he lacks information > to determine whether the result of the transformation to "Unicode" > should be interpreted as groups of 16 bits or some other code width, > as well as which code points represent various hangul characters. The former point is not relevant: you can interpret it as 16-bit or 21-bit codes without any difference in effect. The latter point I have already addressed. -- John Cowan cowan(a)ccil.org www.ccil.org/~cowan www.ap.org The competent programmer is fully aware of the strictly limited size of his own skull; therefore he approaches the programming task in full humility, and among other things he avoids clever tricks like the plague. --Edsger Dijkstra To find out more about Reuters visit www.about.reuters.com Any views expressed in this message are those of the individual sender, except where the sender specifically states them to be the views of Reuters Ltd.

2 1

Re: Charset mandatory in unix/linux
by Ned Freed 26 Mar '06

26 Mar '06

(cc'ing the ietf-types list since this doesn't seem like an appropriate topic for ietf-822) > The charset parameter is mandatory in the MIME content-type > attribute. Actually, I don't know of a single case where this is true. All media type pararameters are either type or subtype specific, so there is no general rule that applies to all charset parameters. Nevertheless, the charset parameters that attach to the text top-level type are optional, as is the charset parameter on application/xml. And making the parameter optional doesn't even imply that there's a default. For exmaple, In the case of XML the allowed charsets for unlabelled material are intentionally limited so they can be determined by inspection. > However, such a parameter is not mandatory in > Unix or Linux. I could say the same thing about media types. File extensions or type codes are commonly used to determine the media type. This is a huge problem that has led to serious security glitches as well as poor user experiences. > This is causing more and more problems, when > people have a mixture of files with different charsets, > which you easily get when you download files from the > Internet or receive them via e-mail. The reality is it is causing less and less problems as things gradually shift towards Unicode-based charsets and away from the vast array of less capable charsets. The security issues caused by non-use or misuse of media type labels are a far bigger problem, and worse, one that doesn't appear to be going away. > Would it be possible to get the people responsible for the > file systems in Unix and Linux to add a mandatory charset > attribute to all text files? Knowing the charset buys you very little without also knowing the media type. You seem to be focused on plain text here and hence you're ignoring the larger media type issue. Lots of media types have parameters and even when the media type can be determined - it frequently cannot be done reliably - it is often done in a way that doesn't allow additional parameters to be attached. Additionally, usage is shifting away from plain text and towards other, more sophisticated, formats - so much so that support for plain text has become a bit problematic in some places. This is one of the reasons given for moving away from plain text RFCs to some other format. > Best is probably to add a > generalized property list to files, so that also other > properties than charset can be added in the future. The ability to attach metadata to files is indeed a very useful feature, one that has been around for decades on some platforms at least. (I'm not going to bother with the history here.) And it is already available on Linux - at a minimum the ext2, ext3, and XFS file systems support it. (There are probably others but I'm too lazy to go look them up.) So in the sense of getting the filesystem to support this sort of tagging, your problem is already solved in many cases. But this is the easy part. You now have to get applications to agree on a specific use of metadata tags for charsets or media types or whatever. Good luck on getting that to happen. > The advantage would be that programs which transport files > across the Internet, such as e-mail, ftp and http, would > more often use the correct charset and not munge the files > by giving then an incorrect charset. The commonly occuring > problem with incorrect charset would be reduced. Also local > problems such as text editors would benefit from knowing > the charset of a file. First of all, email and http do not "transfer files" per se. They transfer data objects and each protocol defines the metadata it considers approproate to attach to data objects. The matchup of this metadata to file system metadata is imperfect at best, and there are plenty of issues in this space. (It is far from clear that adding additional type information will solve these problems, however.) Ftp does transfer files, but ftp is kinda old and doesn't understand file metadata too well if at all. This situation means that in situations where retention of file metadata is important some sort of additional container has to be used. A vast number of such container formats have been defined - tar files, zip files, AppleSingle/AppleDouble, etc. > (Mac OS earlier had a very good feature, you could add to > every file a property list called the "resource fork"). > This still works in Mac OS X, but is less and less often > used, since Unix, on which Mac OS X is based, does not have > this facility. In Mac OS X the resource fork is stored in a > separate file whose file name starts with ".", in the same > directory as the file described). Sigh. There are so many things wrong here it is difficult to know where to begin. I guess I'll start with resource forks. The HFS+ and HFSX file systems used by Mac OS X support resource forks natively. They are accessible through the Posix APIs not by prepending a dot to the file name (given how often adjunct files with this naming convention are created by UNIX facilites such a convention would cause all sorts of havoc) but rather by appending "/rsrc" - it's a sort of file-in-a-pseudo-subdirectory. And while it used to be true that most utilities on Mac OS X were unaware of resource forks, this has changed in recent versions - most of the UNIX-derived OS utilieis now handle resource forks correctly. However, resource forks are used to store file data, not metadata, so none of this is especially relevant to the metadata issue. Now, Apple apparently had some notion of extending the fork model to allow arbitrary named forks. Such a facility could in theory be used to store metadata, although using such a heavyweight mechanism to store metadata never seemed like a very good idea to me. (A fork is in effect a separate file as far as the on-disk structures are concerned, so even if you hide this from applications the overhead is still there.) Regardless, Apple has backed away from actually completing the implementation of this facility. My understanding is if you try to create forks with other names with the provided APIs you get an error. What Apple has done instead is implement full support for file metadata separate from forks. This IMO is the right approach. Apparently there's a separate B-tree for this somewhere in HFS+ - you don't even need to be running HFSX for it to work. It took Apple a while to get this done, but API routines to access this stuff now exist, and even better, they are apparently the same as the ones used on Linux. This support also works on other filesystems that lack built in metadata storage - the metadata is instead stored in a separate file with "._" prepended to the name. (I know there are ext2 and ext3 drivers for Mac OS X but I don't know if or how they handle the metadata issue - hopefully they store it in a way that's compatible with usage on Linux.) There's lots more to know about metadata on Mac OS X. This article describes the landscape pretty well: http://arstechnica.com/reviews/os/macosx-10.4.ars/6 So what's the bottom line? The bottom line is that you appear to be focusing on the wrong problem along several dimensions. First, charset information specifically isn't as interesting or essential as you claim, and the degree to which is it interesting is dropping for a variety of reasons. Second, you appear to have missed the larger and much more important problem of not having correct parameterized type information available. (And we haven't even discussed the many other sorts of metadata, like say language information, that is also useful to have.) Third, your focus on getting metadata support into filesystems is mostly misplaced - this is a solved problem in a lot of cases. And fifth, you don't seem to appreciate the difficulty of getting everyone to agree to actually use filesystem metadata to solve any of these problems. This last is a complete showstopper and I dispair of there ever being significant progress in this area because of it. Ned

4 3

[Fwd: I-D ACTION:draft-taylor-types-example-00.txt]
by Tom-PT Taylor 23 Mar '06

23 Mar '06

This is a draft implementing the idea of the example media type and subtype. Please look it over and see whether it is suitable for submission. I have had a comment suggesting that I add a bit of informative text suggesting the use of the string "example" in sample media descriptions involving types outside of the standards tree. This would go in the introduction. Tom Taylor

1 0

Request for review of audio/G729EV media type
by Colin Perkins 22 Mar '06

22 Mar '06

The AVT working group requests media type review for the audio/G729EV media type defined in section 6.1 of draft-ietf-avt-rtp-g729-scal-wb- ext-03.txt. This draft is currently in working group last call. We would be grateful if any comments could be made by 4th April 2006. Thanks, Colin (AVT co-chair)

1 0

Example media type and subtype
by Tom-PT Taylor 20 Mar '06

20 Mar '06

A need has arisen in MMUSIC for a media type to use strictly as an example. In the particular case, something like application/example would do. Discussion of the matter led to the suggestion that registrations be defined for */example (presumably scoped to the standards tree only) and a new top-level media type example/*. Since the use would be for documentation only, it would seem that there would not be much to say in most fields of the registration template. Comments? Tom Taylor

2 1

Proposed Media Type Registration:davmount+xml (draft-reschke-webdav-mount-03)
by Julian Reschke 16 Mar '06

16 Mar '06

Hi, <http://www.ietf.org/internet-drafts/draft-reschke-webdav-mount-03.txt> proposes a new XML based media type for messages sent by WebDAV servers to user agents, initiating "mounting" a WebDAV collection on the local system. Please review. Best regards, Julian

1 0

Re: Charset mandatory in unix/linux
by Ned Freed 13 Mar '06

13 Mar '06

> Martin Duerst writes: > > At 00:10 06/03/13, Ned Freed wrote: > > >(cc'ing the ietf-types list since this doesn't seem like an > > appropriate topic > > >for ietf-822) > > > > > >> The charset parameter is mandatory in the MIME content-type attribute. > > > > > >Actually, I don't know of a single case where this is true. > > > > I don't, either. > Huh. > So I looked closely, and I find that you're right. How about stressing > this a little more in the successor to RFC 2045? RFC 2045 is about message structure and only deals with with the aspects of media types that interact with message structure. RFC 2046 is where media type behavior is defined, and section 4.1.2 of that document is quite clear about the behavior of the charset parameter. > Ned? Section 5.2 could > state clearly that «Content-Type: text/plain» does NOT mean the same as > a missing Content-Type header. Since it does mean that in email, I fail to see why such a change would be (a) Correct or (b) A good idea. Ned

2 2