From: chris at w3.org (Chris Lilley) Date: Tue Jan 3 16:22:37 2006 Subject: Please review application/shf+xml In-Reply-To: <20031030012511.0819.MURATA@hokkaido.email.ne.jp> References: <767211950.20031026215846@w3.org> <20031030012511.0819.MURATA@hokkaido.email.ne.jp> Message-ID: <968551406.20031029181654@w3.org> On Wednesday, October 29, 2003, 5:33:26 PM, MURATA wrote: MM> On Mon, 27 Oct 2003 18:06:46 +0100 (MET) MM> Linus Walleij wrote: >> * We define that shf+xml will use UTF-8 and UTF-16 only, for reasons of >> simplicty. MM> Which UTF-16? Unfortunately, there are three charsets for UTF-16. MM> They are "utf-16le", "utf-16be" and "utf-16" (see RFC 2781). I believe the answer to this can be found by a case-insensitive string match between the three stings you give and the string "UTF-16" that I suggested above. However, my main reason for suggesting both the encodings that XML mandates is because the effort to detect and give an error on an otherwise perfectly fine file in XML that uses UTF-16 and that the parser would happily accept, seems higher than any utility gained. MM> Since this XML format describes hexadecimal data, almost every character MM> is US-ASCII. I wonder why we have to double the file size by representing MM> a US-ASCII character with 16 bits. 1MB in UTF-8 becomes 2MB in UTF-16. You don't *have* to double the file size. Saying UTF-16 only would, I agree, double the file size in most cases. Use UTF-8 unless the quantity of human-readable content is large and the overall size is smaller in UTF-16 >> * We define that in this case the "charset" parameter is omitted, for this >> very reason. MM> If there is more than one choice, I do not think that this is a MM> good reason to omit the charset parameter. On the contrary, since both UTF-8 and UTF-16 are accepted by every XML parser worldwide and since, therefore, using either of these two does not require an XML declaration with an encoding declaration, then there is absolutely no problem there. Forcing the server to construct redundant and frequently erroneous information in parallel seems especially unwise in this case, because every parser can accept both encodings and because the string containing the encoding is not physically present in the file, making the server have to do byte analysis to compute the value. -- Chris mailto:chris@w3.org From: triad at df.lth.se (Linus Walleij) Date: Wed Oct 29 18:02:40 2003 Subject: Please review application/shf+xml In-Reply-To: <20031030012511.0819.MURATA@hokkaido.email.ne.jp> References: <767211950.20031026215846@w3.org> <20031030012511.0819.MURATA@hokkaido.email.ne.jp> Message-ID: On Thu, 30 Oct 2003, MURATA Makoto wrote: > > * We define that shf+xml will use UTF-8 and UTF-16 only, for reasons of > > simplicty. > > Which UTF-16? Unfortunately, there are three charsets for UTF-16. > They are "utf-16le", "utf-16be" and "utf-16" (see RFC 2781). The XML specification says: Entities encoded in UTF-16 must begin with the Byte Order Mark described by Annex F of [ISO/IEC 10646], Annex H of [ISO/IEC 10646-2000], section 2.4 of [Unicode], and section 2.7 of [Unicode3] (the ZERO WIDTH NO-BREAK SPACE character, #xFEFF). This is an encoding signature, not part of either the markup or the character data of the XML document. XML processors must be able to use this character to differentiate between UTF-8 and UTF-16 encoded documents. As easy as it gets :-) > Since this XML format describes hexadecimal data, almost every character > is US-ASCII. I wonder why we have to double the file size by representing > a US-ASCII character with 16 bits. 1MB in UTF-8 becomes 2MB in UTF-16. That's a good point. OK it's UTF-8 only then. Linus >From chris@w3.org Wed Oct 29 18:16:54 2003 From: chris at w3.org (Chris Lilley) Date: Wed Oct 29 18:27:21 2003 Subject: Please review application/shf+xml In-Reply-To: <20031030012511.0819.MURATA@hokkaido.email.ne.jp> References: <767211950.20031026215846@w3.org> <20031030012511.0819.MURATA@hokkaido.email.ne.jp> Message-ID: <968551406.20031029181654@w3.org> On Wednesday, October 29, 2003, 5:33:26 PM, MURATA wrote: MM> On Mon, 27 Oct 2003 18:06:46 +0100 (MET) MM> Linus Walleij wrote: >> * We define that shf+xml will use UTF-8 and UTF-16 only, for reasons of >> simplicty. MM> Which UTF-16? Unfortunately, there are three charsets for UTF-16. MM> They are "utf-16le", "utf-16be" and "utf-16" (see RFC 2781). I believe the answer to this can be found by a case-insensitive string match between the three stings you give and the string "UTF-16" that I suggested above. However, my main reason for suggesting both the encodings that XML mandates is because the effort to detect and give an error on an otherwise perfectly fine file in XML that uses UTF-16 and that the parser would happily accept, seems higher than any utility gained. MM> Since this XML format describes hexadecimal data, almost every character MM> is US-ASCII. I wonder why we have to double the file size by representing MM> a US-ASCII character with 16 bits. 1MB in UTF-8 becomes 2MB in UTF-16. You don't *have* to double the file size. Saying UTF-16 only would, I agree, double the file size in most cases. Use UTF-8 unless the quantity of human-readable content is large and the overall size is smaller in UTF-16 >> * We define that in this case the "charset" parameter is omitted, for this >> very reason. MM> If there is more than one choice, I do not think that this is a MM> good reason to omit the charset parameter. On the contrary, since both UTF-8 and UTF-16 are accepted by every XML parser worldwide and since, therefore, using either of these two does not require an XML declaration with an encoding declaration, then there is absolutely no problem there. Forcing the server to construct redundant and frequently erroneous information in parallel seems especially unwise in this case, because every parser can accept both encodings and because the string containing the encoding is not physically present in the file, making the server have to do byte analysis to compute the value. -- Chris mailto:chris@w3.org From: triad at df.lth.se (Linus Walleij) Date: Tue Jan 3 16:22:37 2006 Subject: Please review application/shf+xml In-Reply-To: <20031030012511.0819.MURATA@hokkaido.email.ne.jp> References: <767211950.20031026215846@w3.org> <20031030012511.0819.MURATA@hokkaido.email.ne.jp> Message-ID: On Thu, 30 Oct 2003, MURATA Makoto wrote: > > * We define that shf+xml will use UTF-8 and UTF-16 only, for reasons of > > simplicty. > > Which UTF-16? Unfortunately, there are three charsets for UTF-16. > They are "utf-16le", "utf-16be" and "utf-16" (see RFC 2781). The XML specification says: Entities encoded in UTF-16 must begin with the Byte Order Mark described by Annex F of [ISO/IEC 10646], Annex H of [ISO/IEC 10646-2000], section 2.4 of [Unicode], and section 2.7 of [Unicode3] (the ZERO WIDTH NO-BREAK SPACE character, #xFEFF). This is an encoding signature, not part of either the markup or the character data of the XML document. XML processors must be able to use this character to differentiate between UTF-8 and UTF-16 encoded documents. As easy as it gets :-) > Since this XML format describes hexadecimal data, almost every character > is US-ASCII. I wonder why we have to double the file size by representing > a US-ASCII character with 16 bits. 1MB in UTF-8 becomes 2MB in UTF-16. That's a good point. OK it's UTF-8 only then. Linus From: murata at hokkaido.email.ne.jp (MURATA Makoto) Date: Tue Jan 3 16:22:37 2006 Subject: Please review application/shf+xml In-Reply-To: References: <767211950.20031026215846@w3.org> Message-ID: <20031030012511.0819.MURATA@hokkaido.email.ne.jp> On Mon, 27 Oct 2003 18:06:46 +0100 (MET) Linus Walleij wrote: > * We define that shf+xml will use UTF-8 and UTF-16 only, for reasons of > simplicty. Which UTF-16? Unfortunately, there are three charsets for UTF-16. They are "utf-16le", "utf-16be" and "utf-16" (see RFC 2781). Since this XML format describes hexadecimal data, almost every character is US-ASCII. I wonder why we have to double the file size by representing a US-ASCII character with 16 bits. 1MB in UTF-8 becomes 2MB in UTF-16. > * We define that in this case the "charset" parameter is omitted, for this > very reason. If there is more than one choice, I do not think that this is a good reason to omit the charset parameter. Cheers, -- MURATA Makoto From: triad at df.lth.se (Linus Walleij) Date: Mon Oct 27 18:07:50 2003 Subject: Please review application/shf+xml In-Reply-To: <767211950.20031026215846@w3.org> References: <20031024184245.933E.MURATA@hokkaido.email.ne.jp> <1197508576.20031024162631@w3.org> <20031026225646.9359.MURATA@hokkaido.email.ne.jp> <767211950.20031026215846@w3.org> Message-ID: OK we have then reached consensus on this issue I believe: * We define that shf+xml will use UTF-8 and UTF-16 only, for reasons of simplicty. * We define that in this case the "charset" parameter is omitted, for this very reason. And then everybody is happy with this transport type? Regarding the application as such, I have announced it for discussion on the discuss-list for Application Area, all interested parties are welcomed to join in on it. Yours, Linus Walleij >From murata@hokkaido.email.ne.jp Thu Oct 30 01:33:26 2003 From: murata at hokkaido.email.ne.jp (MURATA Makoto) Date: Wed Oct 29 17:36:31 2003 Subject: Please review application/shf+xml In-Reply-To: References: <767211950.20031026215846@w3.org> Message-ID: <20031030012511.0819.MURATA@hokkaido.email.ne.jp> On Mon, 27 Oct 2003 18:06:46 +0100 (MET) Linus Walleij wrote: > * We define that shf+xml will use UTF-8 and UTF-16 only, for reasons of > simplicty. Which UTF-16? Unfortunately, there are three charsets for UTF-16. They are "utf-16le", "utf-16be" and "utf-16" (see RFC 2781). Since this XML format describes hexadecimal data, almost every character is US-ASCII. I wonder why we have to double the file size by representing a US-ASCII character with 16 bits. 1MB in UTF-8 becomes 2MB in UTF-16. > * We define that in this case the "charset" parameter is omitted, for this > very reason. If there is more than one choice, I do not think that this is a good reason to omit the charset parameter. Cheers, -- MURATA Makoto From: triad at df.lth.se (Linus Walleij) Date: Tue Jan 3 16:22:37 2006 Subject: Please review application/shf+xml In-Reply-To: <767211950.20031026215846@w3.org> References: <20031024184245.933E.MURATA@hokkaido.email.ne.jp> <1197508576.20031024162631@w3.org> <20031026225646.9359.MURATA@hokkaido.email.ne.jp> <767211950.20031026215846@w3.org> Message-ID: OK we have then reached consensus on this issue I believe: * We define that shf+xml will use UTF-8 and UTF-16 only, for reasons of simplicty. * We define that in this case the "charset" parameter is omitted, for this very reason. And then everybody is happy with this transport type? Regarding the application as such, I have announced it for discussion on the discuss-list for Application Area, all interested parties are welcomed to join in on it. Yours, Linus Walleij From: murata at hokkaido.email.ne.jp (MURATA Makoto) Date: Sun Oct 26 15:07:17 2003 Subject: Please review application/shf+xml In-Reply-To: <1197508576.20031024162631@w3.org> References: <20031024184245.933E.MURATA@hokkaido.email.ne.jp> <1197508576.20031024162631@w3.org> Message-ID: <20031026225646.9359.MURATA@hokkaido.email.ne.jp> On Fri, 24 Oct 2003 16:26:31 +0200 Chris Lilley wrote: > > "There is no charset parameter. Character handling has identical > semantics to the case where the charset parameter of the > "application/xml" media type is omitted, as described in [RFC3023]." > > The intent seems identical to what you suggest. What am I missing > here? I think that this I-D should provide a good reason to omit the charset parameter and that reason should be specific to application/shf+xml. For example, "this media type uses UTF-8 only" is a perfectly good reason. In this particular case, are there any reasons to allow something different from UTF-8? (I'm just asking.) Cheers, -- MURATA Makoto From: chris at w3.org (Chris Lilley) Date: Sun Oct 26 21:59:22 2003 Subject: Please review application/shf+xml In-Reply-To: <20031026225646.9359.MURATA@hokkaido.email.ne.jp> References: <20031024184245.933E.MURATA@hokkaido.email.ne.jp> <1197508576.20031024162631@w3.org> <20031026225646.9359.MURATA@hokkaido.email.ne.jp> Message-ID: <767211950.20031026215846@w3.org> On Sunday, October 26, 2003, 3:04:11 PM, MURATA wrote: MM> On Fri, 24 Oct 2003 16:26:31 +0200 MM> Chris Lilley wrote: >> >> "There is no charset parameter. Character handling has identical >> semantics to the case where the charset parameter of the >> "application/xml" media type is omitted, as described in [RFC3023]." >> >> The intent seems identical to what you suggest. What am I missing >> here? MM> I think that this I-D should provide a good reason to omit the charset MM> parameter and that reason should be specific to application/shf+xml. MM> For example, "this media type uses UTF-8 only" is a perfectly good reason. MM> In this particular case, are there any reasons to allow something MM> different from UTF-8? (I'm just asking.) Probably not, though I would advance the case that if they really are using an XML parser then they get UTF-16 for free and should allow both. However, I was not saying that the only time the charset parameter should be omitted was when the encoding was UTF-8 or UTF-16. -- Chris mailto:chris@w3.org From: chris at w3.org (Chris Lilley) Date: Tue Jan 3 16:22:37 2006 Subject: Please review application/shf+xml In-Reply-To: <20031026225646.9359.MURATA@hokkaido.email.ne.jp> References: <20031024184245.933E.MURATA@hokkaido.email.ne.jp> <1197508576.20031024162631@w3.org> <20031026225646.9359.MURATA@hokkaido.email.ne.jp> Message-ID: <767211950.20031026215846@w3.org> On Sunday, October 26, 2003, 3:04:11 PM, MURATA wrote: MM> On Fri, 24 Oct 2003 16:26:31 +0200 MM> Chris Lilley wrote: >> >> "There is no charset parameter. Character handling has identical >> semantics to the case where the charset parameter of the >> "application/xml" media type is omitted, as described in [RFC3023]." >> >> The intent seems identical to what you suggest. What am I missing >> here? MM> I think that this I-D should provide a good reason to omit the charset MM> parameter and that reason should be specific to application/shf+xml. MM> For example, "this media type uses UTF-8 only" is a perfectly good reason. MM> In this particular case, are there any reasons to allow something MM> different from UTF-8? (I'm just asking.) Probably not, though I would advance the case that if they really are using an XML parser then they get UTF-16 for free and should allow both. However, I was not saying that the only time the charset parameter should be omitted was when the encoding was UTF-8 or UTF-16. -- Chris mailto:chris@w3.org From: murata at hokkaido.email.ne.jp (MURATA Makoto) Date: Tue Jan 3 16:22:37 2006 Subject: Please review application/shf+xml In-Reply-To: <1197508576.20031024162631@w3.org> References: <20031024184245.933E.MURATA@hokkaido.email.ne.jp> <1197508576.20031024162631@w3.org> Message-ID: <20031026225646.9359.MURATA@hokkaido.email.ne.jp> On Fri, 24 Oct 2003 16:26:31 +0200 Chris Lilley wrote: > > "There is no charset parameter. Character handling has identical > semantics to the case where the charset parameter of the > "application/xml" media type is omitted, as described in [RFC3023]." > > The intent seems identical to what you suggest. What am I missing > here? I think that this I-D should provide a good reason to omit the charset parameter and that reason should be specific to application/shf+xml. For example, "this media type uses UTF-8 only" is a perfectly good reason. In this particular case, are there any reasons to allow something different from UTF-8? (I'm just asking.) Cheers, -- MURATA Makoto From: murata at hokkaido.email.ne.jp (MURATA Makoto) Date: Fri Oct 24 12:35:23 2003 Subject: Internet draft for sbml+xml media type In-Reply-To: <1066168364.3f8c702ca3d2a@webmail.nethere.net> References: <1066164655.3f8c61af68aa6@webmail.nethere.net> <1066168364.3f8c702ca3d2a@webmail.nethere.net> Message-ID: <20031024192912.9344.MURATA@hokkaido.email.ne.jp> On Tue, 14 Oct 2003 14:52:44 -0700 Ben Kovitz wrote: > With application/xml, UTF-8 is already the default. So, since > SBML is defined to use UTF-8, everything fits together nicely if > we just disallow the charset parameter. I think that this is a good reason to disallow the charset parameter. Please mention this reason in the next I-D. Cheers, -- MURATA Makoto From: mutz at kde.org (Marc Mutz) Date: Fri Oct 24 19:08:27 2003 Subject: please review 'application/pdf' In-Reply-To: <1876966016.20031024161729@w3.org> References: <000001c399a8$ed849370$c3432099@MasinterT40> <200310241314.43294@mail.marc-mutz.de> <1876966016.20031024161729@w3.org> Message-ID: <200310241853.09486@mail.marc-mutz.de> On Friday 24 October 2003 16:17, Chris Lilley wrote: > On Friday, October 24, 2003, 1:14:24 PM, Marc wrote: > I agree. But in this case, its not assumptions. The intent is > specifically described in the PDF. However, the field might not > actually contain the ? symbol and thus, in some jurisdictions, it > might not count as a valid assertion of copyright unless the media > type registration explicitly calls it out. So what you are saying is that the flags might not be legally binding as long as I haven't read the specs? Hmm, too bad I did. Will tell others to not make the same mistake :-)) To recall: >> o Accessing the document in ways not permitted by the document's >> access permissions is a violation of the document author's >> copyright. The more often I read this, the more I get to the conclusion that this is a call to implement law. But law needs to implemented by judges and legislative, not software. I can't help but feel that Adobe tries to outlaw Elcomsoft-like software in this way and tries to abuse IANA and IETF for that. Maybe I'm paranoid. But a technical document shouldn't wake those feelings in me :-) > MM> Or, for that matter, for a media type registration to mandate > MM> DRM. > > It doesn't do that either. There is no access control or other > provision in the quoted sentence. > > It just says that if the author has said in the PDF file that the > material is copyright, then the material is copyright. This strikes > me as sensible. And copyright works can be quoted, cited, and so > forth. It states that "accessing the doc in ways not permitted by the [flags] is a violation of the [..] author's copyright." Not having read the spec and thus not knowing what access permissions are available, I nevertheless speculate that they include printing, viewing, extracting text etc. But if that PDF content is copyrighted and I want to extract a quote and I use software that doesn't implement the above requirement, at least in my jurisdiction I am (still :-( ) allowed to do that and the author can only prohibit that if I use the quote against her personally (simplified). I am expressedly _not_ violating her copyright (implying criminal intend), contrary to what the text states. Trying to restrict rights the law gives me _is_ what I call DRM... > MM> It may be that the document is the result of the conversion > MM> of a freely available Web page to PDF format (e.g. print to PDF) > and MM> that the creator of the document, as opposed to the creator > of the MM> content. > > Yes; but then, the capture software should transfer that copyright > information across (if its machine readable, which it probably > isn't). If save-to-PDF software is adding 'copyright the person that > saved it' then it is wrong. What if the creator of the PDF instructed it to? According to the text, I'd be violating the author's copyright, which is rediculous, given that the author probably didn't even know about the creation of the PDF. :-o Yes. That is a case for the judges to decide. Exactly. My words. Not the software or a media type registration. ;-) > Another good catch, though I would prefer to see that expressed as a > positive (software should give full control over ...) rather than > appearing to state that writing erroneous values is acceptable. "Software should only add and change this data if explicitly directed to by the user." Add that, fine. But don't replace it. The security considerations section of a media type registration is there to list the security-related issues of the _format_. I don't think it should try to standardize behaviour of software that generates or reads the data. That's out of scope for a media type registration. Even if it did, the risk of software putting my phone number into the PDF to be published on the web would still be there. Marc -- They [RIAA,MPAA] are trying to invent a new crime: interference with a business model. --Bruce Schneier, Crypto-Gram 08/2002 -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: signature Url : http://eikenes.alvestrand.no/pipermail/ietf-types/attachments/20031024/799102ee/attachment-0001.bin >From jas@extundo.com Fri Oct 24 20:25:46 2003 From: jas at extundo.com (Simon Josefsson) Date: Fri Oct 24 19:25:56 2003 Subject: please review 'application/pdf' In-Reply-To: <9214601535.20031024182444@w3.org> (Chris Lilley's message of "Fri, 24 Oct 2003 18:24:44 +0200") References: <000001c399a8$ed849370$c3432099@MasinterT40> <532468549.20031024001316@w3.org> <200310241314.43294@mail.marc-mutz.de> <1876966016.20031024161729@w3.org> <9214601535.20031024182444@w3.org> Message-ID: Chris Lilley writes: > On Friday, October 24, 2003, 5:17:25 PM, Simon wrote: > > SJ> Chris Lilley writes: > >>> For a related, example, see the 'Copyright' keyword in the PNG >>> specification. > > SJ> I cannot find any text that is similar to the above in RFC 2083. > SJ> Could you provide a more detailed pointer? > > 4.2.7. tEXt Textual data > > Any number of tEXt chunks can appear, and more than one with > the same keyword is permissible. > > The keyword indicates the type of information represented by the text > string. The following keywords are predefined and should be used where > appropriate: > > Title Short (one line) title or caption for image > Author Name of image's creator > Description Description of image (possibly long) > Copyright Copyright notice > [... ] That is what I found as well. So, how about replacing o Accessing the document in ways not permitted by the document's access permissions is a violation of the document author's copyright. with o The document's access permissions can contain copyright notices or licensing information. or similar text, that lack the legal connotations in the original version? Thanks, Simon From: murata at hokkaido.email.ne.jp (MURATA Makoto) Date: Fri Oct 24 11:49:56 2003 Subject: Please review application/shf+xml In-Reply-To: <6213838328.20031024032246@w3.org> References: <20031024095441.9334.MURATA@hokkaido.email.ne.jp> <6213838328.20031024032246@w3.org> Message-ID: <20031024184245.933E.MURATA@hokkaido.email.ne.jp> On Fri, 24 Oct 2003 03:22:46 +0200 Chris Lilley wrote: > For example, using my suggested wording whereby the registration for > application/shf+xml references what RFC 3023 says to do. I do not think so, because the proposed I-D does not say Same as [charset parameter/ encoding considerations] of application/xml as specified in RFC 3023 which is what RFC 3023 says to do. Cheers, -- MURATA Makoto From: murata at hokkaido.email.ne.jp (MURATA Makoto) Date: Fri Oct 24 11:45:19 2003 Subject: Please review application/shf+xml In-Reply-To: <20031024011222.GA12823@mauzo.mauzo.dyndns.org> References: <20031024095441.9334.MURATA@hokkaido.email.ne.jp> <20031024011222.GA12823@mauzo.mauzo.dyndns.org> Message-ID: <20031024184111.933B.MURATA@hokkaido.email.ne.jp> On Fri, 24 Oct 2003 02:12:22 +0100 ben@morrow.me.uk wrote: > Um, excuse me? > Chris's suggestion that app/shf+xml entities should not have a > charset, but instead always be processed according to this paragraph, > is both entirely in conformance with the RFC and entirely sensible, > especially for a format which will almost invariably be in ASCII. What you have missed is 7.1 of RFC 3023 Registrations for new XML-based media types under top-level types other than "text" SHOULD, in specifying the charset parameter and encoding considerations, define them as: "Same as [charset parameter / encoding considerations] of application/xml as specified in RFC 3023." Cheers, -- MURATA Makoto From: mutz at kde.org (Marc Mutz) Date: Tue Jan 3 16:22:37 2006 Subject: please review 'application/pdf' In-Reply-To: <1876966016.20031024161729@w3.org> References: <000001c399a8$ed849370$c3432099@MasinterT40> <200310241314.43294@mail.marc-mutz.de> <1876966016.20031024161729@w3.org> Message-ID: <200310241853.09486@mail.marc-mutz.de> On Friday 24 October 2003 16:17, Chris Lilley wrote: > On Friday, October 24, 2003, 1:14:24 PM, Marc wrote: > I agree. But in this case, its not assumptions. The intent is > specifically described in the PDF. However, the field might not > actually contain the ? symbol and thus, in some jurisdictions, it > might not count as a valid assertion of copyright unless the media > type registration explicitly calls it out. So what you are saying is that the flags might not be legally binding as long as I haven't read the specs? Hmm, too bad I did. Will tell others to not make the same mistake :-)) To recall: >> o Accessing the document in ways not permitted by the document's >> access permissions is a violation of the document author's >> copyright. The more often I read this, the more I get to the conclusion that this is a call to implement law. But law needs to implemented by judges and legislative, not software. I can't help but feel that Adobe tries to outlaw Elcomsoft-like software in this way and tries to abuse IANA and IETF for that. Maybe I'm paranoid. But a technical document shouldn't wake those feelings in me :-) > MM> Or, for that matter, for a media type registration to mandate > MM> DRM. > > It doesn't do that either. There is no access control or other > provision in the quoted sentence. > > It just says that if the author has said in the PDF file that the > material is copyright, then the material is copyright. This strikes > me as sensible. And copyright works can be quoted, cited, and so > forth. It states that "accessing the doc in ways not permitted by the [flags] is a violation of the [..] author's copyright." Not having read the spec and thus not knowing what access permissions are available, I nevertheless speculate that they include printing, viewing, extracting text etc. But if that PDF content is copyrighted and I want to extract a quote and I use software that doesn't implement the above requirement, at least in my jurisdiction I am (still :-( ) allowed to do that and the author can only prohibit that if I use the quote against her personally (simplified). I am expressedly _not_ violating her copyright (implying criminal intend), contrary to what the text states. Trying to restrict rights the law gives me _is_ what I call DRM... > MM> It may be that the document is the result of the conversion > MM> of a freely available Web page to PDF format (e.g. print to PDF) > and MM> that the creator of the document, as opposed to the creator > of the MM> content. > > Yes; but then, the capture software should transfer that copyright > information across (if its machine readable, which it probably > isn't). If save-to-PDF software is adding 'copyright the person that > saved it' then it is wrong. What if the creator of the PDF instructed it to? According to the text, I'd be violating the author's copyright, which is rediculous, given that the author probably didn't even know about the creation of the PDF. :-o Yes. That is a case for the judges to decide. Exactly. My words. Not the software or a media type registration. ;-) > Another good catch, though I would prefer to see that expressed as a > positive (software should give full control over ...) rather than > appearing to state that writing erroneous values is acceptable. "Software should only add and change this data if explicitly directed to by the user." Add that, fine. But don't replace it. The security considerations section of a media type registration is there to list the security-related issues of the _format_. I don't think it should try to standardize behaviour of software that generates or reads the data. That's out of scope for a media type registration. Even if it did, the risk of software putting my phone number into the PDF to be published on the web would still be there. Marc -- They [RIAA,MPAA] are trying to invent a new crime: interference with a business model. --Bruce Schneier, Crypto-Gram 08/2002 -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: signature Url : http://www.alvestrand.no/pipermail/ietf-types/attachments/20031024/799102ee/attachment-0002.bin >From jas@extundo.com Fri Oct 24 19:25:46 2003 From: jas at extundo.com (Simon Josefsson) Date: Tue Jan 3 16:22:37 2006 Subject: please review 'application/pdf' In-Reply-To: <9214601535.20031024182444@w3.org> (Chris Lilley's message of "Fri, 24 Oct 2003 18:24:44 +0200") References: <000001c399a8$ed849370$c3432099@MasinterT40> <532468549.20031024001316@w3.org> <200310241314.43294@mail.marc-mutz.de> <1876966016.20031024161729@w3.org> <9214601535.20031024182444@w3.org> Message-ID: Chris Lilley writes: > On Friday, October 24, 2003, 5:17:25 PM, Simon wrote: > > SJ> Chris Lilley writes: > >>> For a related, example, see the 'Copyright' keyword in the PNG >>> specification. > > SJ> I cannot find any text that is similar to the above in RFC 2083. > SJ> Could you provide a more detailed pointer? > > 4.2.7. tEXt Textual data > > Any number of tEXt chunks can appear, and more than one with > the same keyword is permissible. > > The keyword indicates the type of information represented by the text > string. The following keywords are predefined and should be used where > appropriate: > > Title Short (one line) title or caption for image > Author Name of image's creator > Description Description of image (possibly long) > Copyright Copyright notice > [... ] That is what I found as well. So, how about replacing o Accessing the document in ways not permitted by the document's access permissions is a violation of the document author's copyright. with o The document's access permissions can contain copyright notices or licensing information. or similar text, that lack the legal connotations in the original version? Thanks, Simon From: jas at extundo.com (Simon Josefsson) Date: Fri Oct 24 17:17:37 2003 Subject: please review 'application/pdf' In-Reply-To: <1876966016.20031024161729@w3.org> (Chris Lilley's message of "Fri, 24 Oct 2003 16:17:29 +0200") References: <000001c399a8$ed849370$c3432099@MasinterT40> <532468549.20031024001316@w3.org> <200310241314.43294@mail.marc-mutz.de> <1876966016.20031024161729@w3.org> Message-ID: Chris Lilley writes: > On Friday, October 24, 2003, 1:14:24 PM, Marc wrote: > > MM> On Friday 24 October 2003 00:13, Chris Lilley wrote: > MM> >>> I also see >>> >>> ? ?o Accessing the document in ways not permitted by the document's >>> ? ? ?access permissions is a violation of the document author's >>> ? ? ?copyright. >>> >>> This strikes me as a useful statement and I am pleased by its >>> inclusion. > MM> > > MM> I think I need to disagree here. > > MM> I don't think it's appropriate for a technical document to make > MM> assumptions on the intent of the author of a document, be it PDF or > MM> other. > > I agree. But in this case, its not assumptions. The intent is > specifically described in the PDF. However, the field might not > actually contain the ? symbol and thus, in some jurisdictions, it > might not count as a valid assertion of copyright unless the media > type registration explicitly calls it out. In some jurisdiction, simply _accessing_ a document does not violate anyone's copyright. To violate a copyright require more than just accessing a document. Furthermore, PDF files may contain uncopyrighted material, or might not have a clear author. I have to agree that it is inappropriate for a technical document to make these legal statements. If the text should remain at all, I believe it would make sense to relax the wording somewhat. Right now the text make assertions that cannot be tested for technical interoperability. Legal requirements change over time, and the interpretation and enforcement of such requirements should be left to lawyers or the proper authorities. > For a related, example, see the 'Copyright' keyword in the PNG > specification. I cannot find any text that is similar to the above in RFC 2083. Could you provide a more detailed pointer? Thanks, Simon From: ben at morrow.me.uk (ben@morrow.me.uk) Date: Fri Oct 24 17:41:57 2003 Subject: please review 'application/pdf' In-Reply-To: References: <000001c399a8$ed849370$c3432099@MasinterT40> <532468549.20031024001316@w3.org> <200310241314.43294@mail.marc-mutz.de> <1876966016.20031024161729@w3.org> Message-ID: <20031024154150.GA3521@mauzo.mauzo.dyndns.org> At 5pm on 24/10/03 you (Simon Josefsson) wrote: > > In some jurisdiction, simply _accessing_ a document does not violate > anyone's copyright. To violate a copyright require more than just > accessing a document. > > Furthermore, PDF files may contain uncopyrighted material, or might > not have a clear author. > > I have to agree that it is inappropriate for a technical document to > make these legal statements. If the text should remain at all, I > believe it would make sense to relax the wording somewhat. Right now > the text make assertions that cannot be tested for technical > interoperability. > > Legal requirements change over time, and the interpretation and > enforcement of such requirements should be left to lawyers or the > proper authorities. Of course. It is clear (at least to me) that the intention of the statement is that the (machine-readable) access-permission fields in a PDF file are to be considered legally equivalent to a formal statement of copyright and appropriate licensing terms. The further legal implications of that, as regards rights to access the material etc., are not (and should not be) dealt with by the ID: they are left to the proper authorities. Maybe it should be recast to make this clear. Of course, in any actual dispute, I would have thought it quite within the bounds of possibility for lawyers and judges to ignore this ID: thus, people concerned about their copyrights would do well to put a full statement in natural language as well. :) Ben >From mutz@kde.org Fri Oct 24 18:40:02 2003 From: mutz at kde.org (Marc Mutz) Date: Fri Oct 24 17:57:31 2003 Subject: please review 'application/pdf' In-Reply-To: <200310241314.43294@mail.marc-mutz.de> References: <000001c399a8$ed849370$c3432099@MasinterT40> <532468549.20031024001316@w3.org> <200310241314.43294@mail.marc-mutz.de> Message-ID: <200310241740.05859@mail.marc-mutz.de> On Friday 24 October 2003 13:14, Marc Mutz wrote: > and > that the creator of the document, as opposed to the creator of the > content. ... decided on the flags. Sorry, Marc -- The first casualty of war is the truth. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: signature Url : http://eikenes.alvestrand.no/pipermail/ietf-types/attachments/20031024/0e82437a/attachment.bin >From chris@w3.org Fri Oct 24 19:24:44 2003 From: chris at w3.org (Chris Lilley) Date: Fri Oct 24 18:25:20 2003 Subject: please review 'application/pdf' In-Reply-To: References: <000001c399a8$ed849370$c3432099@MasinterT40> <532468549.20031024001316@w3.org> <200310241314.43294@mail.marc-mutz.de> <1876966016.20031024161729@w3.org> Message-ID: <9214601535.20031024182444@w3.org> On Friday, October 24, 2003, 5:17:25 PM, Simon wrote: SJ> Chris Lilley writes: >> For a related, example, see the 'Copyright' keyword in the PNG >> specification. SJ> I cannot find any text that is similar to the above in RFC 2083. SJ> Could you provide a more detailed pointer? 4.2.7. tEXt Textual data Any number of tEXt chunks can appear, and more than one with the same keyword is permissible. The keyword indicates the type of information represented by the text string. The following keywords are predefined and should be used where appropriate: Title Short (one line) title or caption for image Author Name of image's creator Description Description of image (possibly long) Copyright Copyright notice [... ] -- Chris mailto:chris@w3.org From: ben at morrow.me.uk (ben@morrow.me.uk) Date: Tue Jan 3 16:22:37 2006 Subject: please review 'application/pdf' In-Reply-To: References: <000001c399a8$ed849370$c3432099@MasinterT40> <532468549.20031024001316@w3.org> <200310241314.43294@mail.marc-mutz.de> <1876966016.20031024161729@w3.org> Message-ID: <20031024154150.GA3521@mauzo.mauzo.dyndns.org> At 5pm on 24/10/03 you (Simon Josefsson) wrote: > > In some jurisdiction, simply _accessing_ a document does not violate > anyone's copyright. To violate a copyright require more than just > accessing a document. > > Furthermore, PDF files may contain uncopyrighted material, or might > not have a clear author. > > I have to agree that it is inappropriate for a technical document to > make these legal statements. If the text should remain at all, I > believe it would make sense to relax the wording somewhat. Right now > the text make assertions that cannot be tested for technical > interoperability. > > Legal requirements change over time, and the interpretation and > enforcement of such requirements should be left to lawyers or the > proper authorities. Of course. It is clear (at least to me) that the intention of the statement is that the (machine-readable) access-permission fields in a PDF file are to be considered legally equivalent to a formal statement of copyright and appropriate licensing terms. The further legal implications of that, as regards rights to access the material etc., are not (and should not be) dealt with by the ID: they are left to the proper authorities. Maybe it should be recast to make this clear. Of course, in any actual dispute, I would have thought it quite within the bounds of possibility for lawyers and judges to ignore this ID: thus, people concerned about their copyrights would do well to put a full statement in natural language as well. :) Ben From: mutz at kde.org (Marc Mutz) Date: Tue Jan 3 16:22:37 2006 Subject: please review 'application/pdf' In-Reply-To: <200310241314.43294@mail.marc-mutz.de> References: <000001c399a8$ed849370$c3432099@MasinterT40> <532468549.20031024001316@w3.org> <200310241314.43294@mail.marc-mutz.de> Message-ID: <200310241740.05859@mail.marc-mutz.de> On Friday 24 October 2003 13:14, Marc Mutz wrote: > and > that the creator of the document, as opposed to the creator of the > content. ... decided on the flags. Sorry, Marc -- The first casualty of war is the truth. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: signature Url : http://www.alvestrand.no/pipermail/ietf-types/attachments/20031024/0e82437a/attachment-0002.bin >From chris@w3.org Fri Oct 24 18:24:44 2003 From: chris at w3.org (Chris Lilley) Date: Tue Jan 3 16:22:37 2006 Subject: please review 'application/pdf' In-Reply-To: References: <000001c399a8$ed849370$c3432099@MasinterT40> <532468549.20031024001316@w3.org> <200310241314.43294@mail.marc-mutz.de> <1876966016.20031024161729@w3.org> Message-ID: <9214601535.20031024182444@w3.org> On Friday, October 24, 2003, 5:17:25 PM, Simon wrote: SJ> Chris Lilley writes: >> For a related, example, see the 'Copyright' keyword in the PNG >> specification. SJ> I cannot find any text that is similar to the above in RFC 2083. SJ> Could you provide a more detailed pointer? 4.2.7. tEXt Textual data Any number of tEXt chunks can appear, and more than one with the same keyword is permissible. The keyword indicates the type of information represented by the text string. The following keywords are predefined and should be used where appropriate: Title Short (one line) title or caption for image Author Name of image's creator Description Description of image (possibly long) Copyright Copyright notice [... ] -- Chris mailto:chris@w3.org From: chris at w3.org (Chris Lilley) Date: Fri Oct 24 16:27:06 2003 Subject: Please review application/shf+xml In-Reply-To: <20031024184245.933E.MURATA@hokkaido.email.ne.jp> References: <20031024095441.9334.MURATA@hokkaido.email.ne.jp> <6213838328.20031024032246@w3.org> <20031024184245.933E.MURATA@hokkaido.email.ne.jp> Message-ID: <1197508576.20031024162631@w3.org> On Friday, October 24, 2003, 11:44:30 AM, MURATA wrote: MM> On Fri, 24 Oct 2003 03:22:46 +0200 MM> Chris Lilley wrote: >> For example, using my suggested wording whereby the registration for >> application/shf+xml references what RFC 3023 says to do. MM> I do not think so, because the proposed I-D does not say MM> Same as [charset parameter/ encoding considerations] of MM> application/xml as specified in RFC 3023 MM> which is what RFC 3023 says to do. My suggested wording, which was only suggested a few days ago on this list so might not be in the latest ID was "There is no charset parameter. Character handling has identical semantics to the case where the charset parameter of the "application/xml" media type is omitted, as described in [RFC3023]." The intent seems identical to what you suggest. What am I missing here? -- Chris mailto:chris@w3.org From: jas at extundo.com (Simon Josefsson) Date: Tue Jan 3 16:22:37 2006 Subject: please review 'application/pdf' In-Reply-To: <1876966016.20031024161729@w3.org> (Chris Lilley's message of "Fri, 24 Oct 2003 16:17:29 +0200") References: <000001c399a8$ed849370$c3432099@MasinterT40> <532468549.20031024001316@w3.org> <200310241314.43294@mail.marc-mutz.de> <1876966016.20031024161729@w3.org> Message-ID: Chris Lilley writes: > On Friday, October 24, 2003, 1:14:24 PM, Marc wrote: > > MM> On Friday 24 October 2003 00:13, Chris Lilley wrote: > MM> >>> I also see >>> >>> ? ?o Accessing the document in ways not permitted by the document's >>> ? ? ?access permissions is a violation of the document author's >>> ? ? ?copyright. >>> >>> This strikes me as a useful statement and I am pleased by its >>> inclusion. > MM> > > MM> I think I need to disagree here. > > MM> I don't think it's appropriate for a technical document to make > MM> assumptions on the intent of the author of a document, be it PDF or > MM> other. > > I agree. But in this case, its not assumptions. The intent is > specifically described in the PDF. However, the field might not > actually contain the ? symbol and thus, in some jurisdictions, it > might not count as a valid assertion of copyright unless the media > type registration explicitly calls it out. In some jurisdiction, simply _accessing_ a document does not violate anyone's copyright. To violate a copyright require more than just accessing a document. Furthermore, PDF files may contain uncopyrighted material, or might not have a clear author. I have to agree that it is inappropriate for a technical document to make these legal statements. If the text should remain at all, I believe it would make sense to relax the wording somewhat. Right now the text make assertions that cannot be tested for technical interoperability. Legal requirements change over time, and the interpretation and enforcement of such requirements should be left to lawyers or the proper authorities. > For a related, example, see the 'Copyright' keyword in the PNG > specification. I cannot find any text that is similar to the above in RFC 2083. Could you provide a more detailed pointer? Thanks, Simon From: chris at w3.org (Chris Lilley) Date: Tue Jan 3 16:22:37 2006 Subject: Please review application/shf+xml In-Reply-To: <20031024184245.933E.MURATA@hokkaido.email.ne.jp> References: <20031024095441.9334.MURATA@hokkaido.email.ne.jp> <6213838328.20031024032246@w3.org> <20031024184245.933E.MURATA@hokkaido.email.ne.jp> Message-ID: <1197508576.20031024162631@w3.org> On Friday, October 24, 2003, 11:44:30 AM, MURATA wrote: MM> On Fri, 24 Oct 2003 03:22:46 +0200 MM> Chris Lilley wrote: >> For example, using my suggested wording whereby the registration for >> application/shf+xml references what RFC 3023 says to do. MM> I do not think so, because the proposed I-D does not say MM> Same as [charset parameter/ encoding considerations] of MM> application/xml as specified in RFC 3023 MM> which is what RFC 3023 says to do. My suggested wording, which was only suggested a few days ago on this list so might not be in the latest ID was "There is no charset parameter. Character handling has identical semantics to the case where the charset parameter of the "application/xml" media type is omitted, as described in [RFC3023]." The intent seems identical to what you suggest. What am I missing here? -- Chris mailto:chris@w3.org From: mutz at kde.org (Marc Mutz) Date: Fri Oct 24 13:29:28 2003 Subject: please review 'application/pdf' In-Reply-To: <532468549.20031024001316@w3.org> References: <000001c399a8$ed849370$c3432099@MasinterT40> <532468549.20031024001316@w3.org> Message-ID: <200310241314.43294@mail.marc-mutz.de> On Friday 24 October 2003 00:13, Chris Lilley wrote: > I also see > > ? ?o Accessing the document in ways not permitted by the document's > ? ? ?access permissions is a violation of the document author's > ? ? ?copyright. > > This strikes me as a useful statement and I am pleased by its > inclusion. I think I need to disagree here. I don't think it's appropriate for a technical document to make assumptions on the intent of the author of a document, be it PDF or other. Or, for that matter, for a media type registration to mandate DRM. It might be that the document author just left the default values of whatever software she used to create the PDF and that software might default to restricting rights that the author may have freely granted otherwise. It may be that the document is the result of the conversion of a freely available Web page to PDF format (e.g. print to PDF) and that the creator of the document, as opposed to the creator of the content. OTOH, the Security Consideration section misses a remark that PDF files contain compressed content and that the result of decompression might be very much larger than the file appears, which enables DoS attacks on MUAs and Web Browsers if not taken into account. It also misses to mention if and to what extend meta data about the author or the authors system is present in the PDF file. Something along the lines of PDF documents include document metadata such as the name of the author, etc. The PDF author may not have full control over what metadata is to be included. Therefore, use of this mimetype may lead to hidden leaking of possibly sensitive data. Marc -- It's one thing to accept a risk to your own data, but quite another to standardize on something that imposes that risk on others, no matter how unlikely you think it is that anything "really bad" will happen, and no matter how desirable the outcome. -- Bart Schaefer, on ietf-822 -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: signature Url : http://eikenes.alvestrand.no/pipermail/ietf-types/attachments/20031024/c7bb0e2c/attachment.bin >From chris@w3.org Fri Oct 24 17:17:29 2003 From: chris at w3.org (Chris Lilley) Date: Fri Oct 24 16:18:08 2003 Subject: please review 'application/pdf' In-Reply-To: <200310241314.43294@mail.marc-mutz.de> References: <000001c399a8$ed849370$c3432099@MasinterT40> <532468549.20031024001316@w3.org> <200310241314.43294@mail.marc-mutz.de> Message-ID: <1876966016.20031024161729@w3.org> On Friday, October 24, 2003, 1:14:24 PM, Marc wrote: MM> On Friday 24 October 2003 00:13, Chris Lilley wrote: MM> >> I also see >> >> ? ?o Accessing the document in ways not permitted by the document's >> ? ? ?access permissions is a violation of the document author's >> ? ? ?copyright. >> >> This strikes me as a useful statement and I am pleased by its >> inclusion. MM> MM> I think I need to disagree here. MM> I don't think it's appropriate for a technical document to make MM> assumptions on the intent of the author of a document, be it PDF or MM> other. I agree. But in this case, its not assumptions. The intent is specifically described in the PDF. However, the field might not actually contain the ? symbol and thus, in some jurisdictions, it might not count as a valid assertion of copyright unless the media type registration explicitly calls it out. For a related, example, see the 'Copyright' keyword in the PNG specification. MM> Or, for that matter, for a media type registration to mandate MM> DRM. It doesn't do that either. There is no access control or other provision in the quoted sentence. It just says that if the author has said in the PDF file that the material is copyright, then the material is copyright. This strikes me as sensible. And copyright works can be quoted, cited, and so forth. MM> It might be that the document author just left the default values MM> of whatever software she used to create the PDF and that software might MM> default to restricting rights that the author may have freely granted MM> otherwise. I agree that this is a worrying scenario. But the fault there would be with the software, same as if I wrote software that said all the content was ? Chris Lilley, as a default option. Talking of freely granting - how does one express, for example, a GNU copyleft or a Creative Commons license in a PDF file? MM> It may be that the document is the result of the conversion MM> of a freely available Web page to PDF format (e.g. print to PDF) and MM> that the creator of the document, as opposed to the creator of the MM> content. Yes; but then, the capture software should transfer that copyright information across (if its machine readable, which it probably isn't). If save-to-PDF software is adding 'copyright the person that saved it' then it is wrong. MM> OTOH, the Security Consideration section misses a remark that PDF files MM> contain compressed content and that the result of decompression might MM> be very much larger than the file appears, which enables DoS attacks on MM> MUAs and Web Browsers if not taken into account. Good point. MM> It also misses to mention if and to what extend meta data about the MM> author or the authors system is present in the PDF file. Something MM> along the lines of MM> PDF documents include document metadata such as the name of MM> the author, etc. The PDF author may not have full control over MM> what metadata is to be included. Therefore, use of this MM> mimetype may lead to hidden leaking of possibly sensitive data. Another good catch, though I would prefer to see that expressed as a positive (software should give full control over ...) rather than appearing to state that writing erroneous values is acceptable. -- Chris mailto:chris@w3.org From: mutz at kde.org (Marc Mutz) Date: Tue Jan 3 16:22:37 2006 Subject: please review 'application/pdf' In-Reply-To: <532468549.20031024001316@w3.org> References: <000001c399a8$ed849370$c3432099@MasinterT40> <532468549.20031024001316@w3.org> Message-ID: <200310241314.43294@mail.marc-mutz.de> On Friday 24 October 2003 00:13, Chris Lilley wrote: > I also see > > ? ?o Accessing the document in ways not permitted by the document's > ? ? ?access permissions is a violation of the document author's > ? ? ?copyright. > > This strikes me as a useful statement and I am pleased by its > inclusion. I think I need to disagree here. I don't think it's appropriate for a technical document to make assumptions on the intent of the author of a document, be it PDF or other. Or, for that matter, for a media type registration to mandate DRM. It might be that the document author just left the default values of whatever software she used to create the PDF and that software might default to restricting rights that the author may have freely granted otherwise. It may be that the document is the result of the conversion of a freely available Web page to PDF format (e.g. print to PDF) and that the creator of the document, as opposed to the creator of the content. OTOH, the Security Consideration section misses a remark that PDF files contain compressed content and that the result of decompression might be very much larger than the file appears, which enables DoS attacks on MUAs and Web Browsers if not taken into account. It also misses to mention if and to what extend meta data about the author or the authors system is present in the PDF file. Something along the lines of PDF documents include document metadata such as the name of the author, etc. The PDF author may not have full control over what metadata is to be included. Therefore, use of this mimetype may lead to hidden leaking of possibly sensitive data. Marc -- It's one thing to accept a risk to your own data, but quite another to standardize on something that imposes that risk on others, no matter how unlikely you think it is that anything "really bad" will happen, and no matter how desirable the outcome. -- Bart Schaefer, on ietf-822 -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: signature Url : http://www.alvestrand.no/pipermail/ietf-types/attachments/20031024/c7bb0e2c/attachment-0002.bin >From chris@w3.org Fri Oct 24 16:17:29 2003 From: chris at w3.org (Chris Lilley) Date: Tue Jan 3 16:22:37 2006 Subject: please review 'application/pdf' In-Reply-To: <200310241314.43294@mail.marc-mutz.de> References: <000001c399a8$ed849370$c3432099@MasinterT40> <532468549.20031024001316@w3.org> <200310241314.43294@mail.marc-mutz.de> Message-ID: <1876966016.20031024161729@w3.org> On Friday, October 24, 2003, 1:14:24 PM, Marc wrote: MM> On Friday 24 October 2003 00:13, Chris Lilley wrote: MM> >> I also see >> >> ? ?o Accessing the document in ways not permitted by the document's >> ? ? ?access permissions is a violation of the document author's >> ? ? ?copyright. >> >> This strikes me as a useful statement and I am pleased by its >> inclusion. MM> MM> I think I need to disagree here. MM> I don't think it's appropriate for a technical document to make MM> assumptions on the intent of the author of a document, be it PDF or MM> other. I agree. But in this case, its not assumptions. The intent is specifically described in the PDF. However, the field might not actually contain the ? symbol and thus, in some jurisdictions, it might not count as a valid assertion of copyright unless the media type registration explicitly calls it out. For a related, example, see the 'Copyright' keyword in the PNG specification. MM> Or, for that matter, for a media type registration to mandate MM> DRM. It doesn't do that either. There is no access control or other provision in the quoted sentence. It just says that if the author has said in the PDF file that the material is copyright, then the material is copyright. This strikes me as sensible. And copyright works can be quoted, cited, and so forth. MM> It might be that the document author just left the default values MM> of whatever software she used to create the PDF and that software might MM> default to restricting rights that the author may have freely granted MM> otherwise. I agree that this is a worrying scenario. But the fault there would be with the software, same as if I wrote software that said all the content was ? Chris Lilley, as a default option. Talking of freely granting - how does one express, for example, a GNU copyleft or a Creative Commons license in a PDF file? MM> It may be that the document is the result of the conversion MM> of a freely available Web page to PDF format (e.g. print to PDF) and MM> that the creator of the document, as opposed to the creator of the MM> content. Yes; but then, the capture software should transfer that copyright information across (if its machine readable, which it probably isn't). If save-to-PDF software is adding 'copyright the person that saved it' then it is wrong. MM> OTOH, the Security Consideration section misses a remark that PDF files MM> contain compressed content and that the result of decompression might MM> be very much larger than the file appears, which enables DoS attacks on MM> MUAs and Web Browsers if not taken into account. Good point. MM> It also misses to mention if and to what extend meta data about the MM> author or the authors system is present in the PDF file. Something MM> along the lines of MM> PDF documents include document metadata such as the name of MM> the author, etc. The PDF author may not have full control over MM> what metadata is to be included. Therefore, use of this MM> mimetype may lead to hidden leaking of possibly sensitive data. Another good catch, though I would prefer to see that expressed as a positive (software should give full control over ...) rather than appearing to state that writing erroneous values is acceptable. -- Chris mailto:chris@w3.org From: murata at hokkaido.email.ne.jp (MURATA Makoto) Date: Tue Jan 3 16:22:36 2006 Subject: Internet draft for sbml+xml media type In-Reply-To: <1066168364.3f8c702ca3d2a@webmail.nethere.net> References: <1066164655.3f8c61af68aa6@webmail.nethere.net> <1066168364.3f8c702ca3d2a@webmail.nethere.net> Message-ID: <20031024192912.9344.MURATA@hokkaido.email.ne.jp> On Tue, 14 Oct 2003 14:52:44 -0700 Ben Kovitz wrote: > With application/xml, UTF-8 is already the default. So, since > SBML is defined to use UTF-8, everything fits together nicely if > we just disallow the charset parameter. I think that this is a good reason to disallow the charset parameter. Please mention this reason in the next I-D. Cheers, -- MURATA Makoto From: murata at hokkaido.email.ne.jp (MURATA Makoto) Date: Tue Jan 3 16:22:36 2006 Subject: Please review application/shf+xml In-Reply-To: <6213838328.20031024032246@w3.org> References: <20031024095441.9334.MURATA@hokkaido.email.ne.jp> <6213838328.20031024032246@w3.org> Message-ID: <20031024184245.933E.MURATA@hokkaido.email.ne.jp> On Fri, 24 Oct 2003 03:22:46 +0200 Chris Lilley wrote: > For example, using my suggested wording whereby the registration for > application/shf+xml references what RFC 3023 says to do. I do not think so, because the proposed I-D does not say Same as [charset parameter/ encoding considerations] of application/xml as specified in RFC 3023 which is what RFC 3023 says to do. Cheers, -- MURATA Makoto From: murata at hokkaido.email.ne.jp (MURATA Makoto) Date: Tue Jan 3 16:22:36 2006 Subject: Please review application/shf+xml In-Reply-To: <20031024011222.GA12823@mauzo.mauzo.dyndns.org> References: <20031024095441.9334.MURATA@hokkaido.email.ne.jp> <20031024011222.GA12823@mauzo.mauzo.dyndns.org> Message-ID: <20031024184111.933B.MURATA@hokkaido.email.ne.jp> On Fri, 24 Oct 2003 02:12:22 +0100 ben@morrow.me.uk wrote: > Um, excuse me? > Chris's suggestion that app/shf+xml entities should not have a > charset, but instead always be processed according to this paragraph, > is both entirely in conformance with the RFC and entirely sensible, > especially for a format which will almost invariably be in ASCII. What you have missed is 7.1 of RFC 3023 Registrations for new XML-based media types under top-level types other than "text" SHOULD, in specifying the charset parameter and encoding considerations, define them as: "Same as [charset parameter / encoding considerations] of application/xml as specified in RFC 3023." Cheers, -- MURATA Makoto From: murata at hokkaido.email.ne.jp (MURATA Makoto) Date: Fri Oct 24 03:02:59 2003 Subject: Please review application/shf+xml In-Reply-To: <645556890.20031022163917@w3.org> References: <20031022213753.9312.MURATA@hokkaido.email.ne.jp> <645556890.20031022163917@w3.org> Message-ID: <20031024095441.9334.MURATA@hokkaido.email.ne.jp> On Wed, 22 Oct 2003 16:39:17 +0200 Chris Lilley wrote: > If your applications are tested with multiple charsets, and you can > demonstrate that your applications interoperably: Chris can certainly argue against RFC 3023 and try to improve it. However, I do not think that Linus would like to wait for the conclusion of that debate. Apparently, application/shf+xml and RFC 3023 should be in sync, By the way, if we drop the charset from RFC 3023, some SOAP implementations will break. Linus wrote: > > If, on the other hand, (...) > > then I urge you to *not* add a charset parameter but instead, to add > > the sentence: > > Your previous statements on this issue have not gone unnoticed, so that's > how I do it. Thanks, Chris. I do not think that this is a good action. Cheers, Makoto -- MURATA Makoto From: chris at w3.org (Chris Lilley) Date: Tue Jan 3 16:22:36 2006 Subject: Please review application/shf+xml In-Reply-To: <20031024095441.9334.MURATA@hokkaido.email.ne.jp> References: <20031022213753.9312.MURATA@hokkaido.email.ne.jp> <645556890.20031022163917@w3.org> <20031024095441.9334.MURATA@hokkaido.email.ne.jp> Message-ID: <6213838328.20031024032246@w3.org> On Friday, October 24, 2003, 2:59:58 AM, MURATA wrote: MM> On Wed, 22 Oct 2003 16:39:17 +0200 MM> Chris Lilley wrote: >> If your applications are tested with multiple charsets, and you can >> demonstrate that your applications interoperably: MM> Chris can certainly argue against RFC 3023 and try to improve it. Well, I could. Instead, though, I prefer to suggest wording that directly and normatively references RFC 3023 since that is the current specification. MM> However, I do not think that Linus would like to wait for the MM> conclusion of that debate. I don't recall suggesting anyone wait for anything. MM> Apparently, application/shf+xml and RFC 3023 should be in sync, For example, using my suggested wording whereby the registration for application/shf+xml references what RFC 3023 says to do. MM> By the way, if we drop the charset from RFC 3023, some SOAP MM> implementations will break. Perhaps you could indicate where I suggested altering the SOAP specification? MM> Linus wrote: >> > If, on the other hand, (...) >> > then I urge you to *not* add a charset parameter but instead, to add >> > the sentence: >> >> Your previous statements on this issue have not gone unnoticed, so that's >> how I do it. Thanks, Chris. MM> I do not think that this is a good action. However, you fail to articulate a reason for this. -- Chris mailto:chris@w3.org From: ben at morrow.me.uk (ben@morrow.me.uk) Date: Fri Oct 24 03:12:38 2003 Subject: Please review application/shf+xml In-Reply-To: <20031024095441.9334.MURATA@hokkaido.email.ne.jp> References: <20031022213753.9312.MURATA@hokkaido.email.ne.jp> <645556890.20031022163917@w3.org> <20031024095441.9334.MURATA@hokkaido.email.ne.jp> Message-ID: <20031024011222.GA12823@mauzo.mauzo.dyndns.org> At 9am on 24/10/03 you (MURATA Makoto) wrote: > > On Wed, 22 Oct 2003 16:39:17 +0200 > Chris Lilley wrote: > > > If your applications are tested with multiple charsets, and you can > > demonstrate that your applications interoperably: > > Chris can certainly argue against RFC 3023 and try to improve it. However, > I do not think that Linus would like to wait for the conclusion of that > debate. Apparently, application/shf+xml and RFC 3023 should be in sync, > By the way, if we drop the charset from RFC 3023, some SOAP implementations > will break. Um, excuse me? >From rfc3023 (section 3.2, 'Application/xml registration'): | Optional parameters: charset | If an application/xml entity is received where the charset | parameter is omitted, no information is being provided about the | charset by the MIME Content-Type header. Conforming XML | processors MUST follow the requirements in section 4.3.3 of [XML] | that directly address this contingency. However, MIME processors | that are not XML processors SHOULD NOT assume a default charset if | the charset parameter is omitted from an application/xml entity. Chris's suggestion that app/shf+xml entities should not have a charset, but instead always be processed according to this paragraph, is both entirely in conformance with the RFC and entirely sensible, especially for a format which will almost invariably be in ASCII. Ben >From chris@w3.org Fri Oct 24 04:22:46 2003 From: chris at w3.org (Chris Lilley) Date: Fri Oct 24 03:23:21 2003 Subject: Please review application/shf+xml In-Reply-To: <20031024095441.9334.MURATA@hokkaido.email.ne.jp> References: <20031022213753.9312.MURATA@hokkaido.email.ne.jp> <645556890.20031022163917@w3.org> <20031024095441.9334.MURATA@hokkaido.email.ne.jp> Message-ID: <6213838328.20031024032246@w3.org> On Friday, October 24, 2003, 2:59:58 AM, MURATA wrote: MM> On Wed, 22 Oct 2003 16:39:17 +0200 MM> Chris Lilley wrote: >> If your applications are tested with multiple charsets, and you can >> demonstrate that your applications interoperably: MM> Chris can certainly argue against RFC 3023 and try to improve it. Well, I could. Instead, though, I prefer to suggest wording that directly and normatively references RFC 3023 since that is the current specification. MM> However, I do not think that Linus would like to wait for the MM> conclusion of that debate. I don't recall suggesting anyone wait for anything. MM> Apparently, application/shf+xml and RFC 3023 should be in sync, For example, using my suggested wording whereby the registration for application/shf+xml references what RFC 3023 says to do. MM> By the way, if we drop the charset from RFC 3023, some SOAP MM> implementations will break. Perhaps you could indicate where I suggested altering the SOAP specification? MM> Linus wrote: >> > If, on the other hand, (...) >> > then I urge you to *not* add a charset parameter but instead, to add >> > the sentence: >> >> Your previous statements on this issue have not gone unnoticed, so that's >> how I do it. Thanks, Chris. MM> I do not think that this is a good action. However, you fail to articulate a reason for this. -- Chris mailto:chris@w3.org From: ben at morrow.me.uk (ben@morrow.me.uk) Date: Tue Jan 3 16:22:36 2006 Subject: Please review application/shf+xml In-Reply-To: <20031024095441.9334.MURATA@hokkaido.email.ne.jp> References: <20031022213753.9312.MURATA@hokkaido.email.ne.jp> <645556890.20031022163917@w3.org> <20031024095441.9334.MURATA@hokkaido.email.ne.jp> Message-ID: <20031024011222.GA12823@mauzo.mauzo.dyndns.org> At 9am on 24/10/03 you (MURATA Makoto) wrote: > > On Wed, 22 Oct 2003 16:39:17 +0200 > Chris Lilley wrote: > > > If your applications are tested with multiple charsets, and you can > > demonstrate that your applications interoperably: > > Chris can certainly argue against RFC 3023 and try to improve it. However, > I do not think that Linus would like to wait for the conclusion of that > debate. Apparently, application/shf+xml and RFC 3023 should be in sync, > By the way, if we drop the charset from RFC 3023, some SOAP implementations > will break. Um, excuse me? >From rfc3023 (section 3.2, 'Application/xml registration'): | Optional parameters: charset | If an application/xml entity is received where the charset | parameter is omitted, no information is being provided about the | charset by the MIME Content-Type header. Conforming XML | processors MUST follow the requirements in section 4.3.3 of [XML] | that directly address this contingency. However, MIME processors | that are not XML processors SHOULD NOT assume a default charset if | the charset parameter is omitted from an application/xml entity. Chris's suggestion that app/shf+xml entities should not have a charset, but instead always be processed according to this paragraph, is both entirely in conformance with the RFC and entirely sensible, especially for a format which will almost invariably be in ASCII. Ben From: murata at hokkaido.email.ne.jp (MURATA Makoto) Date: Tue Jan 3 16:22:36 2006 Subject: Please review application/shf+xml In-Reply-To: <645556890.20031022163917@w3.org> References: <20031022213753.9312.MURATA@hokkaido.email.ne.jp> <645556890.20031022163917@w3.org> Message-ID: <20031024095441.9334.MURATA@hokkaido.email.ne.jp> On Wed, 22 Oct 2003 16:39:17 +0200 Chris Lilley wrote: > If your applications are tested with multiple charsets, and you can > demonstrate that your applications interoperably: Chris can certainly argue against RFC 3023 and try to improve it. However, I do not think that Linus would like to wait for the conclusion of that debate. Apparently, application/shf+xml and RFC 3023 should be in sync, By the way, if we drop the charset from RFC 3023, some SOAP implementations will break. Linus wrote: > > If, on the other hand, (...) > > then I urge you to *not* add a charset parameter but instead, to add > > the sentence: > > Your previous statements on this issue have not gone unnoticed, so that's > how I do it. Thanks, Chris. I do not think that this is a good action. Cheers, Makoto -- MURATA Makoto From: chris at w3.org (Chris Lilley) Date: Fri Oct 24 00:13:50 2003 Subject: please review 'application/pdf' In-Reply-To: <000001c399a8$ed849370$c3432099@MasinterT40> References: <000001c399a8$ed849370$c3432099@MasinterT40> Message-ID: <532468549.20031024001316@w3.org> On Thursday, October 23, 2003, 11:02:11 PM, Larry wrote: LM> http://www.ietf.org/internet-drafts/draft-zilles-pdf-00.txt LM> This draft updates the (9-year-old) application/pdf LM> registration. Its good to see the registration updated to point to the latest defining specifications. I note the following text: 3. Fragment identifiers The handling of fragment identifiers [5] is not defined in the PDF Reference. The handling of these is defined by the User Agent that interprets a PDF file. One such agent has the following semantics for the fragment identifies [6]: Is the intent here that the semantics implemented by 'one such agent' be standardized for the media type application/pdf so that other such agents can interoperably share URIs containing fragment identifiers? (In other words, its not defined in the PDF reference but is defined in this Media Type registration). If that is the intent, I believe it needs to be more clearly stated. In addition, it should be verified that the proposed syntax should conform to the BNF for fragment identifiers in URIs. If on the other hand the intent is that fragment identifiers are not standardized for application/pdf and that URIs containing fragment identifiers are not interoperable between user agents, I believe that some justification should be presented for this design choice. I also see o Accessing the document in ways not permitted by the document's access permissions is a violation of the document author's copyright. This strikes me as a useful statement and I am pleased by its inclusion. My remaining comments are very minor. Acrobat, Acrobat Capture, Adobe Reader, ePaper, the "Get Adobe Reader" Web logo, the "Adobe PDF" Web logo, and all other trademarks, service marks, and logos used by Adobe (the "Marks") are the registered trademarks or trademarks of Adobe Systems Incorporated in the United States and other countries. Nothing in this book is intended to grant you any right or license to use the Marks for any purpose. I see that the latest Acrobat Reader is called Adobe Reader 6.0, so it might be useful to add that name to the list in the paragraph above. Its covered by "all other trademarks ..." but then so are the other examples given. Macintosh File Type Code(s): "PDF" My understanding is that these codes are four characters. Please check that "PDF" and not, for example, "PDF " is the correct code. Adobe Developer Support %lt;dev-support@adobe.com%gt; I guess that these should have been < and > in the xml source and thus should be, in the text version, Adobe Developer Support -- Chris mailto:chris@w3.org From: chris at w3.org (Chris Lilley) Date: Tue Jan 3 16:22:36 2006 Subject: please review 'application/pdf' In-Reply-To: <000001c399a8$ed849370$c3432099@MasinterT40> References: <000001c399a8$ed849370$c3432099@MasinterT40> Message-ID: <532468549.20031024001316@w3.org> On Thursday, October 23, 2003, 11:02:11 PM, Larry wrote: LM> http://www.ietf.org/internet-drafts/draft-zilles-pdf-00.txt LM> This draft updates the (9-year-old) application/pdf LM> registration. Its good to see the registration updated to point to the latest defining specifications. I note the following text: 3. Fragment identifiers The handling of fragment identifiers [5] is not defined in the PDF Reference. The handling of these is defined by the User Agent that interprets a PDF file. One such agent has the following semantics for the fragment identifies [6]: Is the intent here that the semantics implemented by 'one such agent' be standardized for the media type application/pdf so that other such agents can interoperably share URIs containing fragment identifiers? (In other words, its not defined in the PDF reference but is defined in this Media Type registration). If that is the intent, I believe it needs to be more clearly stated. In addition, it should be verified that the proposed syntax should conform to the BNF for fragment identifiers in URIs. If on the other hand the intent is that fragment identifiers are not standardized for application/pdf and that URIs containing fragment identifiers are not interoperable between user agents, I believe that some justification should be presented for this design choice. I also see o Accessing the document in ways not permitted by the document's access permissions is a violation of the document author's copyright. This strikes me as a useful statement and I am pleased by its inclusion. My remaining comments are very minor. Acrobat, Acrobat Capture, Adobe Reader, ePaper, the "Get Adobe Reader" Web logo, the "Adobe PDF" Web logo, and all other trademarks, service marks, and logos used by Adobe (the "Marks") are the registered trademarks or trademarks of Adobe Systems Incorporated in the United States and other countries. Nothing in this book is intended to grant you any right or license to use the Marks for any purpose. I see that the latest Acrobat Reader is called Adobe Reader 6.0, so it might be useful to add that name to the list in the paragraph above. Its covered by "all other trademarks ..." but then so are the other examples given. Macintosh File Type Code(s): "PDF" My understanding is that these codes are four characters. Please check that "PDF" and not, for example, "PDF " is the correct code. Adobe Developer Support %lt;dev-support@adobe.com%gt; I guess that these should have been < and > in the xml source and thus should be, in the text version, Adobe Developer Support -- Chris mailto:chris@w3.org From: masinter at adobe.com (Larry Masinter) Date: Tue Jan 3 16:22:36 2006 Subject: please review 'application/pdf' Message-ID: <000001c399a8$ed849370$c3432099@MasinterT40> http://www.ietf.org/internet-drafts/draft-zilles-pdf-00.txt This draft updates the (9-year-old) application/pdf registration. From: LMM at acm.org (Larry Masinter) Date: Tue Jan 3 16:22:36 2006 Subject: Please review application/shf+xml In-Reply-To: Message-ID: <001601c39993$1c696fa0$c3432099@MasinterT40> > Also, if we should not go for XML, then the same line of reasoning about > simplicity would also go for BEEP and others, yes? These RFCs give me the > impression that textual transport should be made in XML where possible, > not only where complexity is above some certain level. (Correct med if > this is wrong.) The "best current practice" for use of XML within IETF is in http://www.ietf.org/rfc/rfc3470.txt. It does not contain the recommendation that "textual transport should be made in XML where possible". Larry From: ben at morrow.me.uk (ben@morrow.me.uk) Date: Tue Jan 3 16:22:36 2006 Subject: Please review application/shf+xml In-Reply-To: References: <20031021232648.GA20110@mauzo.mauzo.dyndns.org> <20031022162415.GA4103@mauzo.mauzo.dyndns.org> Message-ID: <20031023175425.GA27211@mauzo.mauzo.dyndns.org> At 7pm on 23/10/03 you (Linus Walleij) wrote: > On Wed, 22 Oct 2003 ben@morrow.me.uk wrote: > > > Rather, my question is, why are > > you using XML rather than (say) some format based on short-lines-of- > > ASCII (perhaps taking RFC2822 as your model)? Given that the data to > > be represented is pure ascii, and has a very simple structure, do you > > really need all the complexities of XML? > > First, it's an Internet thing we wanna do, so if we were just writing "the > most simple hexdump standard" the place to do it would probably be IEEE > and not IETF. This is rather what I was worried about :). I would have said that if you were writing 'the most simple hexdump standard; subject to it being textual, more-or-less human-readable and widely interoperable' then the IETF is exactly the place to do it. For example, RFC2822 is pretty close to 'the most simple email format'. And even MIME, which extends it, is still based on lines of ASCII text. MIME could easily be recast into XML, but there would be no advantage in doing so. > Such de facto-standards (like S-records) already exist. We > expect the need for transport of this kind of data to increase, so an IETF > RFC is needed. Of course. And you should of course consider more than your immediate needs when writing such an RFC, as you have done. > Also, if we should not go for XML, then the same line of reasoning about > simplicity would also go for BEEP and others, yes? I don't know...BEEP is not something I am familiar with. Looking over the RFC, BEEP messages seem to have the property that there are a number of different 'classes' of message, each with a fixed internal structure; this list of classes is extensible. This is a data model which XML is well suited to. > These RFCs give me the impression that textual transport should be > made in XML where possible, not only where complexity is above some > certain level. (Correct med if this is wrong.) I would have said 1. For a simple format like a hex dump, using XML adds significant complexity. 2. You should not add complexity to a format unless there is a significant advantage in doing so. So the question then is, what advantage is XML giving you? > Perhaps the most important point raised was that if we need to extend this > format, e.g. replace it with an SHF v.2 at some point (if not before, > then as 128bit computing is introduced sooner or later), XML is easy to > extend, version and add structure in, if desired. When complexity > increase, XML scales fine. This is true. However, such things as changing the maximum word size are easy to work into a simple format (indeed, there is no real reason to limit the word size at all beyond the specifics of your hashing mechanism). Other structure I would say would be better dealt with by defining a new format which includes a section of SHF: quite possibly this new format could be XML-based, viz.: [here follows an SHF object] But this is all just my opinion: if noone else on the list backs me up I will consider myself outvoted and keep quiet :). Ben From: triad at df.lth.se (Linus Walleij) Date: Tue Jan 3 16:22:36 2006 Subject: Please review application/shf+xml In-Reply-To: <20031022162415.GA4103@mauzo.mauzo.dyndns.org> References: <20031021232648.GA20110@mauzo.mauzo.dyndns.org> <20031022162415.GA4103@mauzo.mauzo.dyndns.org> Message-ID: On Wed, 22 Oct 2003 ben@morrow.me.uk wrote: > Rather, my question is, why are > you using XML rather than (say) some format based on short-lines-of- > ASCII (perhaps taking RFC2822 as your model)? Given that the data to > be represented is pure ascii, and has a very simple structure, do you > really need all the complexities of XML? OK that's a fair and good question... Several things makes us go for XML. First, it's an Internet thing we wanna do, so if we were just writing "the most simple hexdump standard" the place to do it would probably be IEEE and not IETF. Such de facto-standards (like S-records) already exist. We expect the need for transport of this kind of data to increase, so an IETF RFC is needed. There is a general trend i Unix and other OS:es to in addition to being textual, also be XML. Also, if we should not go for XML, then the same line of reasoning about simplicity would also go for BEEP and others, yes? These RFCs give me the impression that textual transport should be made in XML where possible, not only where complexity is above some certain level. (Correct med if this is wrong.) Perhaps the most important point raised was that if we need to extend this format, e.g. replace it with an SHF v.2 at some point (if not before, then as 128bit computing is introduced sooner or later), XML is easy to extend, version and add structure in, if desired. When complexity increase, XML scales fine. Yours, Linus Walleij From: triad at df.lth.se (Linus Walleij) Date: Tue Jan 3 16:22:36 2006 Subject: Please review application/shf+xml In-Reply-To: <645556890.20031022163917@w3.org> References: <20031021232648.GA20110@mauzo.mauzo.dyndns.org> <20031022213753.9312.MURATA@hokkaido.email.ne.jp> <645556890.20031022163917@w3.org> Message-ID: On Wed, 22 Oct 2003, Chris Lilley wrote: > If, on the other hand, (...) > then I urge you to *not* add a charset parameter but instead, to add > the sentence: Your previous statements on this issue have not gone unnoticed, so that's how I do it. Thanks, Chris. Linus From: masinter at adobe.com (Larry Masinter) Date: Thu Oct 23 23:02:59 2003 Subject: please review 'application/pdf' Message-ID: <000001c399a8$ed849370$c3432099@MasinterT40> http://www.ietf.org/internet-drafts/draft-zilles-pdf-00.txt This draft updates the (9-year-old) application/pdf registration. From: ben at morrow.me.uk (ben@morrow.me.uk) Date: Wed Oct 22 18:24:22 2003 Subject: Please review application/shf+xml In-Reply-To: References: <20031021232648.GA20110@mauzo.mauzo.dyndns.org> Message-ID: <20031022162415.GA4103@mauzo.mauzo.dyndns.org> At 2pm on 22/10/03 you (Linus Walleij) wrote: > On Wed, 22 Oct 2003 ben@morrow.me.uk wrote: > > Could I write something like: > > Second, neither the "xml" processing instruction nor the > "DOCTYPE" declaration need to be present. Ah yes, this is quite different. I ws puzzled by 'neither... MAY be present'. > (Accordingly, if a > character set other than UTF-8 is desired, then the "encoding" > parameter must be present in an "xml" processing instruction .) For this, see Chris Lilley's mail. The paragraph he gives is all that is required. > > Two additional points: would it not be worth declaring an XML > > namespace for this format in addition to the DTD? > > I have seen no standards for this: there are however two drafts > about it, while we don't know if they will be published, we fashined > this like e.g. the BEEP standard. What about ? OK, that's W3C not IETF, but they are probably the appropriate standards body wrt XML stuff. This is rather a side issue, and doesn't really matter. :) > > and would it not be worth adding support for using hashes other > > than SHA-1, > > We had this discussion, and SHA-1 is sort of IETF standard (RFC > 3174). Sorry. Fair enough. :) > > More generally, although this may be out of the remit of this > > list, is an XML-based format not a little complex for a hex dump? > > The main purpose is transport and storage. In reality, dumps are > typically not transferred to embedded systems by way of textual > formats anyway, instead a host program ("flasher" etc) on some other > machine will typically read the SHF file and transfer the data via > serial bus in some custom format. This is not quite my point (although it does clarify that the format would be useful rather than futile :). Rather, my question is, why are you using XML rather than (say) some format based on short-lines-of- ASCII (perhaps taking RFC2822 as your model)? Given that the data to be represented is pure ascii, and has a very simple structure, do you really need all the complexities of XML? Ben >From triad@df.lth.se Thu Oct 23 19:32:46 2003 From: triad at df.lth.se (Linus Walleij) Date: Thu Oct 23 18:33:03 2003 Subject: Please review application/shf+xml In-Reply-To: <645556890.20031022163917@w3.org> References: <20031021232648.GA20110@mauzo.mauzo.dyndns.org> <20031022213753.9312.MURATA@hokkaido.email.ne.jp> <645556890.20031022163917@w3.org> Message-ID: On Wed, 22 Oct 2003, Chris Lilley wrote: > If, on the other hand, (...) > then I urge you to *not* add a charset parameter but instead, to add > the sentence: Your previous statements on this issue have not gone unnoticed, so that's how I do it. Thanks, Chris. Linus >From triad@df.lth.se Thu Oct 23 20:08:39 2003 From: triad at df.lth.se (Linus Walleij) Date: Thu Oct 23 19:08:46 2003 Subject: Please review application/shf+xml In-Reply-To: <20031022162415.GA4103@mauzo.mauzo.dyndns.org> References: <20031021232648.GA20110@mauzo.mauzo.dyndns.org> <20031022162415.GA4103@mauzo.mauzo.dyndns.org> Message-ID: On Wed, 22 Oct 2003 ben@morrow.me.uk wrote: > Rather, my question is, why are > you using XML rather than (say) some format based on short-lines-of- > ASCII (perhaps taking RFC2822 as your model)? Given that the data to > be represented is pure ascii, and has a very simple structure, do you > really need all the complexities of XML? OK that's a fair and good question... Several things makes us go for XML. First, it's an Internet thing we wanna do, so if we were just writing "the most simple hexdump standard" the place to do it would probably be IEEE and not IETF. Such de facto-standards (like S-records) already exist. We expect the need for transport of this kind of data to increase, so an IETF RFC is needed. There is a general trend i Unix and other OS:es to in addition to being textual, also be XML. Also, if we should not go for XML, then the same line of reasoning about simplicity would also go for BEEP and others, yes? These RFCs give me the impression that textual transport should be made in XML where possible, not only where complexity is above some certain level. (Correct med if this is wrong.) Perhaps the most important point raised was that if we need to extend this format, e.g. replace it with an SHF v.2 at some point (if not before, then as 128bit computing is introduced sooner or later), XML is easy to extend, version and add structure in, if desired. When complexity increase, XML scales fine. Yours, Linus Walleij >From ben@morrow.me.uk Thu Oct 23 19:54:25 2003 From: ben at morrow.me.uk (ben@morrow.me.uk) Date: Thu Oct 23 19:54:42 2003 Subject: Please review application/shf+xml In-Reply-To: References: <20031021232648.GA20110@mauzo.mauzo.dyndns.org> <20031022162415.GA4103@mauzo.mauzo.dyndns.org> Message-ID: <20031023175425.GA27211@mauzo.mauzo.dyndns.org> At 7pm on 23/10/03 you (Linus Walleij) wrote: > On Wed, 22 Oct 2003 ben@morrow.me.uk wrote: > > > Rather, my question is, why are > > you using XML rather than (say) some format based on short-lines-of- > > ASCII (perhaps taking RFC2822 as your model)? Given that the data to > > be represented is pure ascii, and has a very simple structure, do you > > really need all the complexities of XML? > > First, it's an Internet thing we wanna do, so if we were just writing "the > most simple hexdump standard" the place to do it would probably be IEEE > and not IETF. This is rather what I was worried about :). I would have said that if you were writing 'the most simple hexdump standard; subject to it being textual, more-or-less human-readable and widely interoperable' then the IETF is exactly the place to do it. For example, RFC2822 is pretty close to 'the most simple email format'. And even MIME, which extends it, is still based on lines of ASCII text. MIME could easily be recast into XML, but there would be no advantage in doing so. > Such de facto-standards (like S-records) already exist. We > expect the need for transport of this kind of data to increase, so an IETF > RFC is needed. Of course. And you should of course consider more than your immediate needs when writing such an RFC, as you have done. > Also, if we should not go for XML, then the same line of reasoning about > simplicity would also go for BEEP and others, yes? I don't know...BEEP is not something I am familiar with. Looking over the RFC, BEEP messages seem to have the property that there are a number of different 'classes' of message, each with a fixed internal structure; this list of classes is extensible. This is a data model which XML is well suited to. > These RFCs give me the impression that textual transport should be > made in XML where possible, not only where complexity is above some > certain level. (Correct med if this is wrong.) I would have said 1. For a simple format like a hex dump, using XML adds significant complexity. 2. You should not add complexity to a format unless there is a significant advantage in doing so. So the question then is, what advantage is XML giving you? > Perhaps the most important point raised was that if we need to extend this > format, e.g. replace it with an SHF v.2 at some point (if not before, > then as 128bit computing is introduced sooner or later), XML is easy to > extend, version and add structure in, if desired. When complexity > increase, XML scales fine. This is true. However, such things as changing the maximum word size are easy to work into a simple format (indeed, there is no real reason to limit the word size at all beyond the specifics of your hashing mechanism). Other structure I would say would be better dealt with by defining a new format which includes a section of SHF: quite possibly this new format could be XML-based, viz.: [here follows an SHF object] But this is all just my opinion: if noone else on the list backs me up I will consider myself outvoted and keep quiet :). Ben >From LMM@acm.org Thu Oct 23 12:26:00 2003 From: LMM at acm.org (Larry Masinter) Date: Thu Oct 23 20:28:14 2003 Subject: Please review application/shf+xml In-Reply-To: Message-ID: <001601c39993$1c696fa0$c3432099@MasinterT40> > Also, if we should not go for XML, then the same line of reasoning about > simplicity would also go for BEEP and others, yes? These RFCs give me the > impression that textual transport should be made in XML where possible, > not only where complexity is above some certain level. (Correct med if > this is wrong.) The "best current practice" for use of XML within IETF is in http://www.ietf.org/rfc/rfc3470.txt. It does not contain the recommendation that "textual transport should be made in XML where possible". Larry From: ben at morrow.me.uk (ben@morrow.me.uk) Date: Tue Jan 3 16:22:36 2006 Subject: Please review application/shf+xml In-Reply-To: References: <20031021232648.GA20110@mauzo.mauzo.dyndns.org> Message-ID: <20031022162415.GA4103@mauzo.mauzo.dyndns.org> At 2pm on 22/10/03 you (Linus Walleij) wrote: > On Wed, 22 Oct 2003 ben@morrow.me.uk wrote: > > Could I write something like: > > Second, neither the "xml" processing instruction nor the > "DOCTYPE" declaration need to be present. Ah yes, this is quite different. I ws puzzled by 'neither... MAY be present'. > (Accordingly, if a > character set other than UTF-8 is desired, then the "encoding" > parameter must be present in an "xml" processing instruction .) For this, see Chris Lilley's mail. The paragraph he gives is all that is required. > > Two additional points: would it not be worth declaring an XML > > namespace for this format in addition to the DTD? > > I have seen no standards for this: there are however two drafts > about it, while we don't know if they will be published, we fashined > this like e.g. the BEEP standard. What about ? OK, that's W3C not IETF, but they are probably the appropriate standards body wrt XML stuff. This is rather a side issue, and doesn't really matter. :) > > and would it not be worth adding support for using hashes other > > than SHA-1, > > We had this discussion, and SHA-1 is sort of IETF standard (RFC > 3174). Sorry. Fair enough. :) > > More generally, although this may be out of the remit of this > > list, is an XML-based format not a little complex for a hex dump? > > The main purpose is transport and storage. In reality, dumps are > typically not transferred to embedded systems by way of textual > formats anyway, instead a host program ("flasher" etc) on some other > machine will typically read the SHF file and transfer the data via > serial bus in some custom format. This is not quite my point (although it does clarify that the format would be useful rather than futile :). Rather, my question is, why are you using XML rather than (say) some format based on short-lines-of- ASCII (perhaps taking RFC2822 as your model)? Given that the data to be represented is pure ascii, and has a very simple structure, do you really need all the complexities of XML? Ben From: chris at w3.org (Chris Lilley) Date: Wed Oct 22 17:17:05 2003 Subject: Please review application/shf+xml In-Reply-To: <20031022213753.9312.MURATA@hokkaido.email.ne.jp> References: <20031021232648.GA20110@mauzo.mauzo.dyndns.org> <20031022213753.9312.MURATA@hokkaido.email.ne.jp> Message-ID: <645556890.20031022163917@w3.org> On Wednesday, October 22, 2003, 2:42:51 PM, MURATA wrote: MM> Please follow RFC 3023 and provide the charset parameter. If your applications are tested with multiple charsets, and you can demonstrate that your applications interoperably: a) give the charset parameter precedence over what the XML declaration says b) correctly re-write the XML when saving to disk so that the encoding parameter in the XML declaration is altered to what the MIME charset parameter said (if they differ, thus ensuring that the XML remains well formed when read from disk) then please feel free to add the charset parameter. If, on the other hand, - you would rather avoid this extra level of implementation burden - you would like consistent behavior when reading from local disk as well as from the network, - you are uncomfortable about the possibility of having allegedly XML content on your server which is not well formed in the absence of HTTP headers - you want to simplify the deployability of this media type across Web servers from different vendors then I urge you to *not* add a charset parameter but instead, to add the sentence: "There is no charset parameter. Character handling has identical semantics to the case where the charset parameter of the "application/xml" media type is omitted, as described in [RFC3023]." -- Chris mailto:chris@w3.org From: chris at w3.org (Chris Lilley) Date: Tue Jan 3 16:22:36 2006 Subject: Please review application/shf+xml In-Reply-To: <20031022213753.9312.MURATA@hokkaido.email.ne.jp> References: <20031021232648.GA20110@mauzo.mauzo.dyndns.org> <20031022213753.9312.MURATA@hokkaido.email.ne.jp> Message-ID: <645556890.20031022163917@w3.org> On Wednesday, October 22, 2003, 2:42:51 PM, MURATA wrote: MM> Please follow RFC 3023 and provide the charset parameter. If your applications are tested with multiple charsets, and you can demonstrate that your applications interoperably: a) give the charset parameter precedence over what the XML declaration says b) correctly re-write the XML when saving to disk so that the encoding parameter in the XML declaration is altered to what the MIME charset parameter said (if they differ, thus ensuring that the XML remains well formed when read from disk) then please feel free to add the charset parameter. If, on the other hand, - you would rather avoid this extra level of implementation burden - you would like consistent behavior when reading from local disk as well as from the network, - you are uncomfortable about the possibility of having allegedly XML content on your server which is not well formed in the absence of HTTP headers - you want to simplify the deployability of this media type across Web servers from different vendors then I urge you to *not* add a charset parameter but instead, to add the sentence: "There is no charset parameter. Character handling has identical semantics to the case where the charset parameter of the "application/xml" media type is omitted, as described in [RFC3023]." -- Chris mailto:chris@w3.org From: murata at hokkaido.email.ne.jp (MURATA Makoto) Date: Tue Jan 3 16:22:36 2006 Subject: Please review application/shf+xml In-Reply-To: References: <20031021232648.GA20110@mauzo.mauzo.dyndns.org> Message-ID: <20031022213753.9312.MURATA@hokkaido.email.ne.jp> Please follow RFC 3023 and provide the charset parameter. Cheers, -- MURATA Makoto From: triad at df.lth.se (Linus Walleij) Date: Tue Jan 3 16:22:36 2006 Subject: Please review application/shf+xml In-Reply-To: <20031021232648.GA20110@mauzo.mauzo.dyndns.org> References: <20031021232648.GA20110@mauzo.mauzo.dyndns.org> Message-ID: Thanks Ben! Your effort is much appreciated. On Wed, 22 Oct 2003 ben@morrow.me.uk wrote: > In section 6 the draft states > > | Refer to this DTD as: > | > | | "http://www.foo.org/shf.dtd"> > | %SHF; > > and in section 9.1 > > | There is no charset parameter. > > ; however in section 9.5 we have > > | Second, neither the "XML" declaration (e.g., ) nor the "DOCTYPE" > | declaration (e.g., ) may be present. (Accordingly, if another > | character set other than UTF-8 is desired, then the "charset" > | parameter must be present.) > > . These are inconsistent. Sorry, I was confusing "charset" with "encoding". Will never do it again... Also the paragraph is unclear, as you say. Could I write something like: Second, neither the "xml" processing instruction nor the "DOCTYPE" declaration need to be present. (Accordingly, if a character set other than UTF-8 is desired, then the "encoding" parameter must be present in an "xml" processing instruction .) > I would suggest removing both restrictions > listed in 9.5: their purpose is unclear. The idea is: if you want to switch character set, do so in the processing instruction. () I hope the above conveys this clearly. So, a pedantically specified SHF file would begin: Two additional points: would it not be worth declaring an XML namespace > for this format in addition to the DTD? I have seen no standards for this: there are however two drafts about it, while we don't know if they will be published, we fashined this like e.g. the BEEP standard. > and would it not be worth > adding support for using hashes other than SHA-1, both for when the > time surely comes that SHA-1 is insufficient security, and to allow > simpler checksums in secure environments with limited processing power > (such as embedded systems)? We had this discussion, and SHA-1 is sort of IETF standard (RFC 3174). The purpose of the SHA-1 checksum is plain checksumming of the contents (information integrity) not to counter compromise. The SHF file as a whole may be signed and checked by way of RFC 3275 if need be, as stated. Several checksum algorithms would increase complexity of implementation and was removed for keeping it simple. On processing power, see below. > More generally, although this may be out of the remit of this list, is > an XML-based format not a little complex for a hex dump? The main purpose is transport and storage. In reality, dumps are typically not transferred to embedded systems by way of textual formats anyway, instead a host program ("flasher" etc) on some other machine will typically read the SHF file and transfer the data via serial bus in some custom format. SHF file -> parser/converter -> 01011001001 -> device In the future, as complexity increase in embedded systems, this may change, so that systems parse the SHF file directly. I will try to clarify this. Thanks, Linus From: ben at morrow.me.uk (ben@morrow.me.uk) Date: Tue Jan 3 16:22:36 2006 Subject: Please review application/shf+xml In-Reply-To: References: Message-ID: <20031021232648.GA20110@mauzo.mauzo.dyndns.org> At 11pm on 21/10/03 you (Linus Walleij) wrote: > We have just published an I-D for the Standard Hex Format, and this > announcement is to ask the types-list to review it from a transport type > perspective. > > http://www.ietf.org/internet-drafts/draft-strombergson-shf-00.txt In section 6 the draft states | Refer to this DTD as: | | | %SHF; and in section 9.1 | There is no charset parameter. ; however in section 9.5 we have | Second, neither the "XML" declaration (e.g., ) nor the "DOCTYPE" | declaration (e.g., ) may be present. (Accordingly, if another | character set other than UTF-8 is desired, then the "charset" | parameter must be present.) . These are inconsistent. I would suggest removing both restrictions listed in 9.5: their purpose is unclear. If it is to simplify the processing, then there are many aspects of XML parsing (CDATA sections, properly parsed comments, random charsets, substituting entity references) that are harder to deal with than simply ignoring an XML declaration and doctype. Two additional points: would it not be worth declaring an XML namespace for this format in addition to the DTD? and would it not be worth adding support for using hashes other than SHA-1, both for when the time surely comes that SHA-1 is insufficient security, and to allow simpler checksums in secure environments with limited processing power (such as embedded systems)? More generally, although this may be out of the remit of this list, is an XML-based format not a little complex for a hex dump? The draft mentions 8- and 16-bit embedded systems: are these likely to have the necessary processing power and XML-parsing tools available to make use of a dump in this format? If it is necessary to transform the dump into a simpler form on a more powerful machine this rather defeats the object of a general-purpose platform-neutral format. Ben From: triad at df.lth.se (Linus Walleij) Date: Tue Oct 21 23:03:50 2003 Subject: Please review application/shf+xml Message-ID: We have just published an I-D for the Standard Hex Format, and this announcement is to ask the types-list to review it from a transport type perspective. http://www.ietf.org/internet-drafts/draft-strombergson-shf-00.txt Yours, Linus Walleij on behalf of the author group >From ben@morrow.me.uk Wed Oct 22 01:26:48 2003 From: ben at morrow.me.uk (ben@morrow.me.uk) Date: Wed Oct 22 01:27:05 2003 Subject: Please review application/shf+xml In-Reply-To: References: Message-ID: <20031021232648.GA20110@mauzo.mauzo.dyndns.org> At 11pm on 21/10/03 you (Linus Walleij) wrote: > We have just published an I-D for the Standard Hex Format, and this > announcement is to ask the types-list to review it from a transport type > perspective. > > http://www.ietf.org/internet-drafts/draft-strombergson-shf-00.txt In section 6 the draft states | Refer to this DTD as: | | | %SHF; and in section 9.1 | There is no charset parameter. ; however in section 9.5 we have | Second, neither the "XML" declaration (e.g., ) nor the "DOCTYPE" | declaration (e.g., ) may be present. (Accordingly, if another | character set other than UTF-8 is desired, then the "charset" | parameter must be present.) . These are inconsistent. I would suggest removing both restrictions listed in 9.5: their purpose is unclear. If it is to simplify the processing, then there are many aspects of XML parsing (CDATA sections, properly parsed comments, random charsets, substituting entity references) that are harder to deal with than simply ignoring an XML declaration and doctype. Two additional points: would it not be worth declaring an XML namespace for this format in addition to the DTD? and would it not be worth adding support for using hashes other than SHA-1, both for when the time surely comes that SHA-1 is insufficient security, and to allow simpler checksums in secure environments with limited processing power (such as embedded systems)? More generally, although this may be out of the remit of this list, is an XML-based format not a little complex for a hex dump? The draft mentions 8- and 16-bit embedded systems: are these likely to have the necessary processing power and XML-parsing tools available to make use of a dump in this format? If it is necessary to transform the dump into a simpler form on a more powerful machine this rather defeats the object of a general-purpose platform-neutral format. Ben >From triad@df.lth.se Wed Oct 22 15:21:51 2003 From: triad at df.lth.se (Linus Walleij) Date: Wed Oct 22 14:22:18 2003 Subject: Please review application/shf+xml In-Reply-To: <20031021232648.GA20110@mauzo.mauzo.dyndns.org> References: <20031021232648.GA20110@mauzo.mauzo.dyndns.org> Message-ID: Thanks Ben! Your effort is much appreciated. On Wed, 22 Oct 2003 ben@morrow.me.uk wrote: > In section 6 the draft states > > | Refer to this DTD as: > | > | | "http://www.foo.org/shf.dtd"> > | %SHF; > > and in section 9.1 > > | There is no charset parameter. > > ; however in section 9.5 we have > > | Second, neither the "XML" declaration (e.g., ) nor the "DOCTYPE" > | declaration (e.g., ) may be present. (Accordingly, if another > | character set other than UTF-8 is desired, then the "charset" > | parameter must be present.) > > . These are inconsistent. Sorry, I was confusing "charset" with "encoding". Will never do it again... Also the paragraph is unclear, as you say. Could I write something like: Second, neither the "xml" processing instruction nor the "DOCTYPE" declaration need to be present. (Accordingly, if a character set other than UTF-8 is desired, then the "encoding" parameter must be present in an "xml" processing instruction .) > I would suggest removing both restrictions > listed in 9.5: their purpose is unclear. The idea is: if you want to switch character set, do so in the processing instruction. () I hope the above conveys this clearly. So, a pedantically specified SHF file would begin: Two additional points: would it not be worth declaring an XML namespace > for this format in addition to the DTD? I have seen no standards for this: there are however two drafts about it, while we don't know if they will be published, we fashined this like e.g. the BEEP standard. > and would it not be worth > adding support for using hashes other than SHA-1, both for when the > time surely comes that SHA-1 is insufficient security, and to allow > simpler checksums in secure environments with limited processing power > (such as embedded systems)? We had this discussion, and SHA-1 is sort of IETF standard (RFC 3174). The purpose of the SHA-1 checksum is plain checksumming of the contents (information integrity) not to counter compromise. The SHF file as a whole may be signed and checked by way of RFC 3275 if need be, as stated. Several checksum algorithms would increase complexity of implementation and was removed for keeping it simple. On processing power, see below. > More generally, although this may be out of the remit of this list, is > an XML-based format not a little complex for a hex dump? The main purpose is transport and storage. In reality, dumps are typically not transferred to embedded systems by way of textual formats anyway, instead a host program ("flasher" etc) on some other machine will typically read the SHF file and transfer the data via serial bus in some custom format. SHF file -> parser/converter -> 01011001001 -> device In the future, as complexity increase in embedded systems, this may change, so that systems parse the SHF file directly. I will try to clarify this. Thanks, Linus >From murata@hokkaido.email.ne.jp Wed Oct 22 22:42:51 2003 From: murata at hokkaido.email.ne.jp (MURATA Makoto) Date: Wed Oct 22 14:45:51 2003 Subject: Please review application/shf+xml In-Reply-To: References: <20031021232648.GA20110@mauzo.mauzo.dyndns.org> Message-ID: <20031022213753.9312.MURATA@hokkaido.email.ne.jp> Please follow RFC 3023 and provide the charset parameter. Cheers, -- MURATA Makoto From: triad at df.lth.se (Linus Walleij) Date: Tue Jan 3 16:22:36 2006 Subject: Please review application/shf+xml Message-ID: We have just published an I-D for the Standard Hex Format, and this announcement is to ask the types-list to review it from a transport type perspective. http://www.ietf.org/internet-drafts/draft-strombergson-shf-00.txt Yours, Linus Walleij on behalf of the author group From: bkovitz at caltech.edu (Ben Kovitz) Date: Tue Jan 3 16:22:36 2006 Subject: Internet draft for sbml+xml media type In-Reply-To: <1066164655.3f8c61af68aa6@webmail.nethere.net> References: <1065642124.3f84688c56dd2@webmail.nethere.net> <18718895059.20031009210457@w3.org> <1066164655.3f8c61af68aa6@webmail.nethere.net> Message-ID: <1066168364.3f8c702ca3d2a@webmail.nethere.net> Off-list, Ben Morrow pointed out that I had misread RFC 3023: when I mentioned us-ascii as the default encoding, I was reading the section on text/xml, not application/xml. With application/xml, UTF-8 is already the default. So, since SBML is defined to use UTF-8, everything fits together nicely if we just disallow the charset parameter. I will update the Internet-Draft so it refers to section 3.2 (ahem, not 3.1) of RFC 3023 and uses the text that Chris Lilley suggested. That will be draft-sbml-media-type-02.txt, hopefully on the IETF server tomorrow. Ben Kovitz Caltech bkovitz at caltech.edu http://sbml.org From: bkovitz at caltech.edu (Ben Kovitz) Date: Tue Jan 3 16:22:36 2006 Subject: Internet draft for sbml+xml media type In-Reply-To: <1065813828.30956.3.camel@felicia> References: <1065642124.3f84688c56dd2@webmail.nethere.net> <1065813828.30956.3.camel@felicia> Message-ID: <1066166238.3f8c67de6b6eb@webmail.nethere.net> Regarding: http://www.ietf.org/internet-drafts/draft-sbml-media-type-00.txt Linus Walleij wrote: > I am a little concerned about the long list of URI:s for > applications in the end, with URI:s like: > > http://gnida.cs.vt.edu/~cellcyclepse/ > http://nsr.bioeng.washington.edu/DOC/JSIMDOC/JSim1.5_New_Features > > Will these URI:s still be valid in 20+ years, when SBML is > still in use, or will they just be a huge bunch of invalid old > junk that noone can use by then? It would be better if you put > up a webresource pointer at the same place as the > specification, so that it may be updated as useful. D'ohhh! I'd just gone and made sure we had a stable domain name and set up all the URLs within that domain to be stable for a very long time, and at the last minute tossed in all these presumably non-persistent URLs to all the current SBML projects. Thanks for catching this! I've updated the Internet-Draft to list the projects and refer to just http://sbml.org. I've submitted draft-sbml-media-type-01.txt but I don't think it's appeared on the IETF server yet. Thanks! Ben Kovitz Caltech bkovitz at caltech.edu http://sbml.org From: bkovitz at caltech.edu (Ben Kovitz) Date: Tue Jan 3 16:22:36 2006 Subject: Internet draft for sbml+xml media type In-Reply-To: <20031009181550.GA3955@phoenix.morrow.me.uk> References: <1065642124.3f84688c56dd2@webmail.nethere.net> <20031009181550.GA3955@phoenix.morrow.me.uk> Message-ID: <1066165622.3f8c6576bb366@webmail.nethere.net> Regarding: http://www.ietf.org/internet-drafts/draft-sbml-media-type-00.txt Ben Morrow wrote: > Would it not be advantageous to have 'level' and 'version' > parameters, for situations where the SBML entity will need to > be retrieved and a user-agent will need to decide if it would > be able to process it? Back on July 6, Mark Baker suggested: In my observation, these rarely work out as extensibility mechanisms. text/html used to have one ("level"), and it wasn't used, so wasn't included in RFC 2854. application/xhtml+xml has one ("profile"), but it's there for a single purpose only; to help WAP apps distinguish between XHTML Basic and XHTML 1.0. I'm not aware of anybody using it for other reasons. You might want to consider whether prescribing sufficiently extensible processing behaviour - such that "higher level" (more complex) content may be properly processed by a "lower level" processor - would be adequate for your needs. http://eikenes.alvestrand.no/pipermail/ietf-types/2003-July/000071.html Since 'level' and 'version' are already in the XML schema, I'm thinking that lower-level processors will be able to read higher-level documents, or at least know what to ignore. Does anyone know of any other problems with leaving 'level' and 'version' out of the MIME header, beyond the wasted bandwidth of downloading an XML document only to find that the user agent can't deal with it? Admittedly, some of these SBML models are well into the megabytes, and no one knows what the future will bring. Ben Kovitz Caltech bkovitz at caltech.edu http://sbml.org From: bkovitz at caltech.edu (Ben Kovitz) Date: Tue Jan 3 16:22:36 2006 Subject: Internet draft for sbml+xml media type In-Reply-To: <18718895059.20031009210457@w3.org> References: <1065642124.3f84688c56dd2@webmail.nethere.net> <18718895059.20031009210457@w3.org> Message-ID: <1066164655.3f8c61af68aa6@webmail.nethere.net> Regarding: http://www.ietf.org/internet-drafts/draft-sbml-media-type-00.txt Chris Lilley wrote: > Do the existing SBML-consuming tools honor the charset > parameter when SBML is sent over HTTP or email? And where the > charset parameter disagrees with the encoding in the XMl > encoding declaration, do these tools rewrite the XML when > saving it to disk? > > Note that, although charset is optional in this registration, > RFC 3023 still imposes requirements on software in the > *absence* of a charset. > > If not, I suggest removing this optional parameter as follows: > > There is no charset parameter. Character handling has > identical semantics to the case where the charset parameter > of the "application/xml" media type is omitted, as > described in [RFC3023]. My understanding is that most current SBML-consuming tools do not honor the charset parameter, but that's only because most don't get involved with MIME. Thanks for pointing out the RFC 3023 statements regarding the absence of a parameter! Indeed us-ascii seems unnecessarily limiting. Andrew Finney on sbml-discuss at caltech.edu responded: The SBML Level 2 document states in section 4.1: "The character encoding for SBML is UTF-8. SBML documents should include the encoding attribute with the value UTF-8 in the XML prologue." SBML Level 1 doesn't have this text as far as I remember. I don't know if that helps. My vote would be to specify that SBML is always encoded in UTF-8 and follow through with that in the MIME registration. Would that make SBML unusual for an XML format? Do MIME processors need the flexibility to transform UTF-8 into us-ASCII? i.e. what are the concrete implications? if we do this are we imposing an unrealistic restriction on transmission that would probably not happen in practice? Can we make the char set non-optional and restricted to UFT-8? If yes this would then avoid the issue with rewriting to disk. If we restrict the car set does that make interpreting the incoming stream because the its in only char set? Any thoughts? Restricting sbml+xml to a UTF-8 encoding would certainly be simple, imposing no new requirements on SBML-consuming tools. But would this go against the grain of the relevant RFCs and future evolvability? Ben Kovitz Caltech bkovitz at caltech.edu http://sbml.org From: bkovitz at caltech.edu (Ben Kovitz) Date: Tue Oct 14 23:52:47 2003 Subject: Internet draft for sbml+xml media type In-Reply-To: <1066164655.3f8c61af68aa6@webmail.nethere.net> References: <1065642124.3f84688c56dd2@webmail.nethere.net> <18718895059.20031009210457@w3.org> <1066164655.3f8c61af68aa6@webmail.nethere.net> Message-ID: <1066168364.3f8c702ca3d2a@webmail.nethere.net> Off-list, Ben Morrow pointed out that I had misread RFC 3023: when I mentioned us-ascii as the default encoding, I was reading the section on text/xml, not application/xml. With application/xml, UTF-8 is already the default. So, since SBML is defined to use UTF-8, everything fits together nicely if we just disallow the charset parameter. I will update the Internet-Draft so it refers to section 3.2 (ahem, not 3.1) of RFC 3023 and uses the text that Chris Lilley suggested. That will be draft-sbml-media-type-02.txt, hopefully on the IETF server tomorrow. Ben Kovitz Caltech bkovitz at caltech.edu http://sbml.org From: bkovitz at caltech.edu (Ben Kovitz) Date: Tue Oct 14 23:17:21 2003 Subject: Internet draft for sbml+xml media type In-Reply-To: <1065813828.30956.3.camel@felicia> References: <1065642124.3f84688c56dd2@webmail.nethere.net> <1065813828.30956.3.camel@felicia> Message-ID: <1066166238.3f8c67de6b6eb@webmail.nethere.net> Regarding: http://www.ietf.org/internet-drafts/draft-sbml-media-type-00.txt Linus Walleij wrote: > I am a little concerned about the long list of URI:s for > applications in the end, with URI:s like: > > http://gnida.cs.vt.edu/~cellcyclepse/ > http://nsr.bioeng.washington.edu/DOC/JSIMDOC/JSim1.5_New_Features > > Will these URI:s still be valid in 20+ years, when SBML is > still in use, or will they just be a huge bunch of invalid old > junk that noone can use by then? It would be better if you put > up a webresource pointer at the same place as the > specification, so that it may be updated as useful. D'ohhh! I'd just gone and made sure we had a stable domain name and set up all the URLs within that domain to be stable for a very long time, and at the last minute tossed in all these presumably non-persistent URLs to all the current SBML projects. Thanks for catching this! I've updated the Internet-Draft to list the projects and refer to just http://sbml.org. I've submitted draft-sbml-media-type-01.txt but I don't think it's appeared on the IETF server yet. Thanks! Ben Kovitz Caltech bkovitz at caltech.edu http://sbml.org From: bkovitz at caltech.edu (Ben Kovitz) Date: Tue Oct 14 23:07:05 2003 Subject: Internet draft for sbml+xml media type In-Reply-To: <20031009181550.GA3955@phoenix.morrow.me.uk> References: <1065642124.3f84688c56dd2@webmail.nethere.net> <20031009181550.GA3955@phoenix.morrow.me.uk> Message-ID: <1066165622.3f8c6576bb366@webmail.nethere.net> Regarding: http://www.ietf.org/internet-drafts/draft-sbml-media-type-00.txt Ben Morrow wrote: > Would it not be advantageous to have 'level' and 'version' > parameters, for situations where the SBML entity will need to > be retrieved and a user-agent will need to decide if it would > be able to process it? Back on July 6, Mark Baker suggested: In my observation, these rarely work out as extensibility mechanisms. text/html used to have one ("level"), and it wasn't used, so wasn't included in RFC 2854. application/xhtml+xml has one ("profile"), but it's there for a single purpose only; to help WAP apps distinguish between XHTML Basic and XHTML 1.0. I'm not aware of anybody using it for other reasons. You might want to consider whether prescribing sufficiently extensible processing behaviour - such that "higher level" (more complex) content may be properly processed by a "lower level" processor - would be adequate for your needs. http://eikenes.alvestrand.no/pipermail/ietf-types/2003-July/000071.html Since 'level' and 'version' are already in the XML schema, I'm thinking that lower-level processors will be able to read higher-level documents, or at least know what to ignore. Does anyone know of any other problems with leaving 'level' and 'version' out of the MIME header, beyond the wasted bandwidth of downloading an XML document only to find that the user agent can't deal with it? Admittedly, some of these SBML models are well into the megabytes, and no one knows what the future will bring. Ben Kovitz Caltech bkovitz at caltech.edu http://sbml.org From: bkovitz at caltech.edu (Ben Kovitz) Date: Tue Oct 14 22:50:59 2003 Subject: Internet draft for sbml+xml media type In-Reply-To: <18718895059.20031009210457@w3.org> References: <1065642124.3f84688c56dd2@webmail.nethere.net> <18718895059.20031009210457@w3.org> Message-ID: <1066164655.3f8c61af68aa6@webmail.nethere.net> Regarding: http://www.ietf.org/internet-drafts/draft-sbml-media-type-00.txt Chris Lilley wrote: > Do the existing SBML-consuming tools honor the charset > parameter when SBML is sent over HTTP or email? And where the > charset parameter disagrees with the encoding in the XMl > encoding declaration, do these tools rewrite the XML when > saving it to disk? > > Note that, although charset is optional in this registration, > RFC 3023 still imposes requirements on software in the > *absence* of a charset. > > If not, I suggest removing this optional parameter as follows: > > There is no charset parameter. Character handling has > identical semantics to the case where the charset parameter > of the "application/xml" media type is omitted, as > described in [RFC3023]. My understanding is that most current SBML-consuming tools do not honor the charset parameter, but that's only because most don't get involved with MIME. Thanks for pointing out the RFC 3023 statements regarding the absence of a parameter! Indeed us-ascii seems unnecessarily limiting. Andrew Finney on sbml-discuss at caltech.edu responded: The SBML Level 2 document states in section 4.1: "The character encoding for SBML is UTF-8. SBML documents should include the encoding attribute with the value UTF-8 in the XML prologue." SBML Level 1 doesn't have this text as far as I remember. I don't know if that helps. My vote would be to specify that SBML is always encoded in UTF-8 and follow through with that in the MIME registration. Would that make SBML unusual for an XML format? Do MIME processors need the flexibility to transform UTF-8 into us-ASCII? i.e. what are the concrete implications? if we do this are we imposing an unrealistic restriction on transmission that would probably not happen in practice? Can we make the char set non-optional and restricted to UFT-8? If yes this would then avoid the issue with rewriting to disk. If we restrict the car set does that make interpreting the incoming stream because the its in only char set? Any thoughts? Restricting sbml+xml to a UTF-8 encoding would certainly be simple, imposing no new requirements on SBML-consuming tools. But would this go against the grain of the relevant RFCs and future evolvability? Ben Kovitz Caltech bkovitz at caltech.edu http://sbml.org From: triad at df.lth.se (Linus Walleij) Date: Fri Oct 10 21:24:02 2003 Subject: Internet draft for sbml+xml media type In-Reply-To: <1065642124.3f84688c56dd2@webmail.nethere.net> References: <1065642124.3f84688c56dd2@webmail.nethere.net> Message-ID: <1065813828.30956.3.camel@felicia> ons 2003-10-08 klockan 21.42 skrev Ben Kovitz: > Hi, I've just submitted an Internet Draft for the sbml+xml media > type. I and the other folks responsible for SBML (the Systems > Biology Markup Langage) have incorporated the comments and > suggestions from the folks on this list, especially getting a > definite, persistent, named organization in place to serve as > the change owner. That part is great, I am a litte concerned about the long list of URI:s for applications in the end, with URI:s like: http://gnida.cs.vt.edu/~cellcyclepse/ http://nsr.bioeng.washington.edu/DOC/JSIMDOC/JSim1.5_New_Features Will these URI:s still be valid in 20+ years, when SBML is still in use, or will they just be a huge bunch of invalid old junk that noone can use by then? It would be better if you put up a webresource pointer at the same place as the specification, so that it may be updated as useful. Apart from that it looks just fine. Linus From: triad at df.lth.se (Linus Walleij) Date: Tue Jan 3 16:22:36 2006 Subject: Internet draft for sbml+xml media type In-Reply-To: <1065642124.3f84688c56dd2@webmail.nethere.net> References: <1065642124.3f84688c56dd2@webmail.nethere.net> Message-ID: <1065813828.30956.3.camel@felicia> ons 2003-10-08 klockan 21.42 skrev Ben Kovitz: > Hi, I've just submitted an Internet Draft for the sbml+xml media > type. I and the other folks responsible for SBML (the Systems > Biology Markup Langage) have incorporated the comments and > suggestions from the folks on this list, especially getting a > definite, persistent, named organization in place to serve as > the change owner. That part is great, I am a litte concerned about the long list of URI:s for applications in the end, with URI:s like: http://gnida.cs.vt.edu/~cellcyclepse/ http://nsr.bioeng.washington.edu/DOC/JSIMDOC/JSim1.5_New_Features Will these URI:s still be valid in 20+ years, when SBML is still in use, or will they just be a huge bunch of invalid old junk that noone can use by then? It would be better if you put up a webresource pointer at the same place as the specification, so that it may be updated as useful. Apart from that it looks just fine. Linus From: chris at w3.org (Chris Lilley) Date: Tue Jan 3 16:22:36 2006 Subject: Internet draft for sbml+xml media type In-Reply-To: <1065642124.3f84688c56dd2@webmail.nethere.net> References: <1065642124.3f84688c56dd2@webmail.nethere.net> Message-ID: <18718895059.20031009210457@w3.org> On Wednesday, October 8, 2003, 9:42:04 PM, Ben wrote: BK> Hi, I've just submitted an Internet Draft for the sbml+xml media BK> type. I and the other folks responsible for SBML (the Systems BK> Biology Markup Langage) have incorporated the comments and BK> suggestions from the folks on this list, especially getting a BK> definite, persistent, named organization in place to serve as BK> the change owner. BK> The draft is here: BK> http://www.ietf.org/internet-drafts/draft-sbml-media-type-00.txt BK> Your comments are solicited. Do the existing SBML-consuming tools honor the charset parameter when SBML is sent over HTTP or email? And where the charset parameter disagrees with the encoding in the XMl encoding declaration, do these tools rewrite the XML when saving it to disk? Note that, although charset is optional in this registration, RFC 3023 still imposes requirements on software in the *absence* of a charset. If not, I suggest removing this optional parameter as follows: There is no charset parameter. Character handling has identical semantics to the case where the charset parameter of the "application/xml" media type is omitted, as described in [RFC3023]. -- Chris mailto:chris@w3.org From: ben at morrow.me.uk (ben@morrow.me.uk) Date: Thu Oct 9 20:15:56 2003 Subject: Internet draft for sbml+xml media type In-Reply-To: <1065642124.3f84688c56dd2@webmail.nethere.net> References: <1065642124.3f84688c56dd2@webmail.nethere.net> Message-ID: <20031009181550.GA3955@phoenix.morrow.me.uk> Your (Ben Kovitz) mail at 12pm on 8/10/03 said: > Hi, I've just submitted an Internet Draft for the sbml+xml media > type. > > http://www.ietf.org/internet-drafts/draft-sbml-media-type-00.txt Would it not be advantageous to have 'level' and 'version' parameters, for situations where the SBML entity will need to be retreived and a user-agent will need to decide if it would be able to process it? Ben Morrow >From chris@w3.org Thu Oct 9 22:04:57 2003 From: chris at w3.org (Chris Lilley) Date: Thu Oct 9 21:05:27 2003 Subject: Internet draft for sbml+xml media type In-Reply-To: <1065642124.3f84688c56dd2@webmail.nethere.net> References: <1065642124.3f84688c56dd2@webmail.nethere.net> Message-ID: <18718895059.20031009210457@w3.org> On Wednesday, October 8, 2003, 9:42:04 PM, Ben wrote: BK> Hi, I've just submitted an Internet Draft for the sbml+xml media BK> type. I and the other folks responsible for SBML (the Systems BK> Biology Markup Langage) have incorporated the comments and BK> suggestions from the folks on this list, especially getting a BK> definite, persistent, named organization in place to serve as BK> the change owner. BK> The draft is here: BK> http://www.ietf.org/internet-drafts/draft-sbml-media-type-00.txt BK> Your comments are solicited. Do the existing SBML-consuming tools honor the charset parameter when SBML is sent over HTTP or email? And where the charset parameter disagrees with the encoding in the XMl encoding declaration, do these tools rewrite the XML when saving it to disk? Note that, although charset is optional in this registration, RFC 3023 still imposes requirements on software in the *absence* of a charset. If not, I suggest removing this optional parameter as follows: There is no charset parameter. Character handling has identical semantics to the case where the charset parameter of the "application/xml" media type is omitted, as described in [RFC3023]. -- Chris mailto:chris@w3.org From: ben at morrow.me.uk (ben@morrow.me.uk) Date: Tue Jan 3 16:22:36 2006 Subject: Internet draft for sbml+xml media type In-Reply-To: <1065642124.3f84688c56dd2@webmail.nethere.net> References: <1065642124.3f84688c56dd2@webmail.nethere.net> Message-ID: <20031009181550.GA3955@phoenix.morrow.me.uk> Your (Ben Kovitz) mail at 12pm on 8/10/03 said: > Hi, I've just submitted an Internet Draft for the sbml+xml media > type. > > http://www.ietf.org/internet-drafts/draft-sbml-media-type-00.txt Would it not be advantageous to have 'level' and 'version' parameters, for situations where the SBML entity will need to be retreived and a user-agent will need to decide if it would be able to process it? Ben Morrow From: mf at w3.org (Max Froumentin) Date: Fri Oct 3 12:22:33 2003 Subject: update: application/mathml+xml media type submission Message-ID: <871xtuy61y.fsf@w3.org> Following the first submission at [1], the W3C Math Working Group is submitting a revised version of the application/mathml+xml media type registration. This version removes the charset parameter, considered dangerous as prone to conflicts with XML encoding declaration, and corrects a typo in the draft. Max. -------------- next part -------------- Network Working Group M. Froumentin INTERNET DRAFT W3C draft-froumentin-mathml-media-type-01.txt October 2003 The application/mathml+xml Media Type Status of this Memo This document is anhttp://www.ietf.org/rfc/rfc2026.txt Internet-Draft and is subject to all provisions of Section 10 of RFC2026. http://www.ietf.org/rfc/rfc2026.txt Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents ashttp://www.ietf.org/rfc/rfc2026.txt Internet-Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet- Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/1id-abstracts.html The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html Abstract This document specifies the Media Type for the W3C Mathematical Markup Language (MathML). MathML is an XML application for describing mathematical notation and capturing both its structure and content. Expires: March 2004 1. Introduction The World Wide Web Consortium has issued the specification [MATHML] defining the Mathematical Markup Language (MathML). This memo provides information about the application/mathml+xml Media Type, intended to be used for transferring MathML documents. This document follows the convention set out in [XMLMIME] for the MIME subtype name; attaching the suffix "+xml" to denote that the entity being described conforms to the XML syntax as defined in XML 1.0 [XML]. This document was prepared by members of the W3C Math working group. Please send comments to www-math@w3.org, a public mailing list with archives at . 2. Registration of MIME media type application/mathml+xml MIME media type name: application MIME subtype name: mathml+xml Required parameters: none Optional parameters: none Encoding considerations: See Section 4 of this document. Security considerations: See Section 7 of this document. Interoperability considerations: MathML [MATHML] specifies user agent conformance rules that dictate behaviour that must be followed when dealing with, among other things, unrecognized elements. Published specification: MathML is now defined as a W3C Recommendation; the latest published versions is at [MATHML]. Applications which use this media type: Some content authors have already begun hand and tool authoring on the Web with MathML. However that content is currently described as "text/xml" or "application/xml", allowing existing Web browsers to process it without reconfiguration for a new media type. This new type is being registered in order to allow for the expected deployment of MathML on the World Wide Web, as a first class XML application where authors can expect that user agents are conformant XML 1.0 [XML] processors. Additional information: Magic number: There is no single initial byte sequence that is always present for MathML files. However, Section 5 below gives some guidelines for recognizing MathML files. See also section 3.1 in [XMLMIME]. File extension: There most common file extension that is currently in use for MathML is ".mml". Macintosh File Type code: TEXT Person & email address to contact for further information: Max Froumentin Intended usage: COMMON Author/Change controller: The MathML specification is a work product of the World Wide Web Consortium's Math Working Group. The W3C has change control over these specifications. 3. Encoding considerations By virtue of MathML content being XML, it has the same considerations when sent as 'application/mathml+xml' as does XML. See [XMLMIME], section 3.2. 4. Recognizing MathML files All MathML documents will have the string " [HTML401] Raggett, D., et al., "HTML 4.01 Specification", W3C Recommendation. Available at (or ). [MIME] Freed, N. and N. Borenstein, "Multipurpose Internet Mail Extensions (MIME) Part Two: Media Types", RFC 2046, November 1996. [URI] Berners-Lee, T., Fielding, R. and L. Masinter, "Uniform Resource Identifiers (URI): Generic Syntax", RFC 2396, August 1998. [XHTML1] "XHTML 1.0: The Extensible HyperText Markup Language: A Reformulation of HTML 4 in XML 1.0", W3C Recommendation. Available at . [XML] "Extensible Markup Language (XML) 1.0", W3C Recommendation. Available at (or ). [TEXTHTML] Connolly, D. and L. Masinter, "The 'text/html' Media Type", RFC 2854, June 2000. [XMLMIME] Murata, M., St.Laurent, S. and D. Kohn, "XML Media Types", RFC 3023, January 2001. [XHTMLM12N] "Modularization of XHTML", W3C Recommendation. Available at: 10. Full Copyright Statement Copyright (C) The Internet Society (2002). All Rights Reserved. This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English. The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns. This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Acknowledgement Funding for the RFC Editor function is currently provided by the Internet Society. >From bkovitz@caltech.edu Wed Oct 8 13:42:04 2003 From: bkovitz at caltech.edu (Ben Kovitz) Date: Wed Oct 8 21:42:09 2003 Subject: Internet draft for sbml+xml media type Message-ID: <1065642124.3f84688c56dd2@webmail.nethere.net> Hi, I've just submitted an Internet Draft for the sbml+xml media type. I and the other folks responsible for SBML (the Systems Biology Markup Langage) have incorporated the comments and suggestions from the folks on this list, especially getting a definite, persistent, named organization in place to serve as the change owner. The draft is here: http://www.ietf.org/internet-drafts/draft-sbml-media-type-00.txt Your comments are solicited. Thanks! Ben Kovitz bkovitz at caltech.edu Control and Dynamical Systems Dept. California Institute of Technology http://sbml.org From: mf at w3.org (Max Froumentin) Date: Tue Jan 3 16:22:36 2006 Subject: update: application/mathml+xml media type submission Message-ID: <871xtuy61y.fsf@w3.org> Following the first submission at [1], the W3C Math Working Group is submitting a revised version of the application/mathml+xml media type registration. This version removes the charset parameter, considered dangerous as prone to conflicts with XML encoding declaration, and corrects a typo in the draft. Max. -------------- next part -------------- Network Working Group M. Froumentin INTERNET DRAFT W3C draft-froumentin-mathml-media-type-01.txt October 2003 The application/mathml+xml Media Type Status of this Memo This document is anhttp://www.ietf.org/rfc/rfc2026.txt Internet-Draft and is subject to all provisions of Section 10 of RFC2026. http://www.ietf.org/rfc/rfc2026.txt Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents ashttp://www.ietf.org/rfc/rfc2026.txt Internet-Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet- Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/1id-abstracts.html The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html Abstract This document specifies the Media Type for the W3C Mathematical Markup Language (MathML). MathML is an XML application for describing mathematical notation and capturing both its structure and content. Expires: March 2004 1. Introduction The World Wide Web Consortium has issued the specification [MATHML] defining the Mathematical Markup Language (MathML). This memo provides information about the application/mathml+xml Media Type, intended to be used for transferring MathML documents. This document follows the convention set out in [XMLMIME] for the MIME subtype name; attaching the suffix "+xml" to denote that the entity being described conforms to the XML syntax as defined in XML 1.0 [XML]. This document was prepared by members of the W3C Math working group. Please send comments to www-math@w3.org, a public mailing list with archives at . 2. Registration of MIME media type application/mathml+xml MIME media type name: application MIME subtype name: mathml+xml Required parameters: none Optional parameters: none Encoding considerations: See Section 4 of this document. Security considerations: See Section 7 of this document. Interoperability considerations: MathML [MATHML] specifies user agent conformance rules that dictate behaviour that must be followed when dealing with, among other things, unrecognized elements. Published specification: MathML is now defined as a W3C Recommendation; the latest published versions is at [MATHML]. Applications which use this media type: Some content authors have already begun hand and tool authoring on the Web with MathML. However that content is currently described as "text/xml" or "application/xml", allowing existing Web browsers to process it without reconfiguration for a new media type. This new type is being registered in order to allow for the expected deployment of MathML on the World Wide Web, as a first class XML application where authors can expect that user agents are conformant XML 1.0 [XML] processors. Additional information: Magic number: There is no single initial byte sequence that is always present for MathML files. However, Section 5 below gives some guidelines for recognizing MathML files. See also section 3.1 in [XMLMIME]. File extension: There most common file extension that is currently in use for MathML is ".mml". Macintosh File Type code: TEXT Person & email address to contact for further information: Max Froumentin Intended usage: COMMON Author/Change controller: The MathML specification is a work product of the World Wide Web Consortium's Math Working Group. The W3C has change control over these specifications. 3. Encoding considerations By virtue of MathML content being XML, it has the same considerations when sent as 'application/mathml+xml' as does XML. See [XMLMIME], section 3.2. 4. Recognizing MathML files All MathML documents will have the string " [HTML401] Raggett, D., et al., "HTML 4.01 Specification", W3C Recommendation. Available at (or ). [MIME] Freed, N. and N. Borenstein, "Multipurpose Internet Mail Extensions (MIME) Part Two: Media Types", RFC 2046, November 1996. [URI] Berners-Lee, T., Fielding, R. and L. Masinter, "Uniform Resource Identifiers (URI): Generic Syntax", RFC 2396, August 1998. [XHTML1] "XHTML 1.0: The Extensible HyperText Markup Language: A Reformulation of HTML 4 in XML 1.0", W3C Recommendation. Available at . [XML] "Extensible Markup Language (XML) 1.0", W3C Recommendation. Available at (or ). [TEXTHTML] Connolly, D. and L. Masinter, "The 'text/html' Media Type", RFC 2854, June 2000. [XMLMIME] Murata, M., St.Laurent, S. and D. Kohn, "XML Media Types", RFC 3023, January 2001. [XHTMLM12N] "Modularization of XHTML", W3C Recommendation. Available at: 10. Full Copyright Statement Copyright (C) The Internet Society (2002). All Rights Reserved. This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English. The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns. This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Acknowledgement Funding for the RFC Editor function is currently provided by the Internet Society. >From bkovitz@caltech.edu Wed Oct 8 21:42:04 2003 From: bkovitz at caltech.edu (Ben Kovitz) Date: Tue Jan 3 16:22:36 2006 Subject: Internet draft for sbml+xml media type Message-ID: <1065642124.3f84688c56dd2@webmail.nethere.net> Hi, I've just submitted an Internet Draft for the sbml+xml media type. I and the other folks responsible for SBML (the Systems Biology Markup Langage) have incorporated the comments and suggestions from the folks on this list, especially getting a definite, persistent, named organization in place to serve as the change owner. The draft is here: http://www.ietf.org/internet-drafts/draft-sbml-media-type-00.txt Your comments are solicited. Thanks! Ben Kovitz bkovitz at caltech.edu Control and Dynamical Systems Dept. California Institute of Technology http://sbml.org