Subject: Please review application/shf+xml
From: chris at w3.org (Chris Lilley)
Date: Tue Jan 3 16:22:37 2006

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

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

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

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

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

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

On Mon, 27 Oct 2003 18:06:46 +0100 (MET)
Linus Walleij <[email-masked]> 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 <[email-masked]>

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

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

On Mon, 27 Oct 2003 18:06:46 +0100 (MET)
Linus Walleij <[email-masked]> 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 <[email-masked]>

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

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

On Fri, 24 Oct 2003 16:26:31 +0200
Chris Lilley <[email-masked]> 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 <[email-masked]>

From: chris at w3.org (Chris Lilley)
Date: Sun Oct 26 21:59:22 2003
Subject: Please review application/shf+xml
In-Reply-To: <[email-masked]>
References: <[email-masked]> <[email-masked]> <[email-masked]>
Message-ID: <[email-masked]>

On Sunday, October 26, 2003, 3:04:11 PM, MURATA wrote:

MM> On Fri, 24 Oct 2003 16:26:31 +0200
MM> Chris Lilley <[email-masked]> 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:[email-masked]

From: chris at w3.org (Chris Lilley)
Date: Tue Jan  3 16:22:37 2006
Subject: Please review application/shf+xml
In-Reply-To: <[email-masked]>
References: <[email-masked]> <[email-masked]> <[email-masked]>
Message-ID: <[email-masked]>

On Sunday, October 26, 2003, 3:04:11 PM, MURATA wrote:

MM> On Fri, 24 Oct 2003 16:26:31 +0200
MM> Chris Lilley <[email-masked]> 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:[email-masked]

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

On Fri, 24 Oct 2003 16:26:31 +0200
Chris Lilley <[email-masked]> 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 <[email-masked]>

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

On Tue, 14 Oct 2003 14:52:44 -0700
Ben Kovitz <[email-masked]> 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 <[email-masked]>

From: mutz at kde.org (Marc Mutz)
Date: Fri Oct 24 19:08:27 2003
Subject: please review 'application/pdf'
In-Reply-To: <[email-masked]>
References: <000001c399a8$ed849370$c3432099@MasinterT40> <[email-masked]> <[email-masked]>
Message-ID: <[email-masked]>

On Friday 24 October 2003 16:17, Chris Lilley wrote:
> On Friday, October 24, 2003, 1:14:24 PM, Marc wrote:
<snip>
> 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 [email-masked]  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: <[email-masked]> (Chris Lilley's message of
	"Fri, 24 Oct 2003 18:24:44 +0200")
References: <000001c399a8$ed849370$c3432099@MasinterT40>
	<[email-masked]>
	<[email-masked]>
	<[email-masked]> <[email-masked]>
	<[email-masked]>
Message-ID: <[email-masked]>

Chris Lilley <[email-masked]> writes:

> On Friday, October 24, 2003, 5:17:25 PM, Simon wrote:
>
> SJ> Chris Lilley <[email-masked]> 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: <[email-masked]>
References: <[email-masked]> <[email-masked]>
Message-ID: <[email-masked]>

On Fri, 24 Oct 2003 03:22:46 +0200
Chris Lilley <[email-masked]> 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 <[email-masked]>

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

On Fri, 24 Oct 2003 02:12:22 +0100
[email-masked] 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 <[email-masked]>

From: mutz at kde.org (Marc Mutz)
Date: Tue Jan  3 16:22:37 2006
Subject: please review 'application/pdf'
In-Reply-To: <[email-masked]>
References: <000001c399a8$ed849370$c3432099@MasinterT40> <[email-masked]> <[email-masked]>
Message-ID: <[email-masked]>

On Friday 24 October 2003 16:17, Chris Lilley wrote:
> On Friday, October 24, 2003, 1:14:24 PM, Marc wrote:
<snip>
> 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 [email-masked]  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: <[email-masked]> (Chris Lilley's message of
	"Fri, 24 Oct 2003 18:24:44 +0200")
References: <000001c399a8$ed849370$c3432099@MasinterT40>
	<[email-masked]>
	<[email-masked]>
	<[email-masked]> <[email-masked]>
	<[email-masked]>
Message-ID: <[email-masked]>

Chris Lilley <[email-masked]> writes:

> On Friday, October 24, 2003, 5:17:25 PM, Simon wrote:
>
> SJ> Chris Lilley <[email-masked]> 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: <[email-masked]> (Chris Lilley's message of "Fri, 24 Oct 2003 16:17:29 +0200")
References: <000001c399a8$ed849370$c3432099@MasinterT40> <[email-masked]> <[email-masked]> <[email-masked]>
Message-ID: <[email-masked]>

Chris Lilley <[email-masked]> writes:

> On Friday, October 24, 2003, 1:14:24 PM, Marc wrote:
>
> MM> On Friday 24 October 2003 00:13, Chris Lilley wrote:
> MM> <snip>
>>> 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> <snip>
>
> 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 ([email-masked])
Date: Fri Oct 24 17:41:57 2003
Subject: please review 'application/pdf'
In-Reply-To: <[email-masked]>
References: <000001c399a8$ed849370$c3432099@MasinterT40> <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]>
Message-ID: <[email-masked]>

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 [email-masked]  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: <[email-masked]>
References: <000001c399a8$ed849370$c3432099@MasinterT40>
	<[email-masked]>
	<[email-masked]>
Message-ID: <[email-masked]>

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 [email-masked]  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: <[email-masked]>
References: <000001c399a8$ed849370$c3432099@MasinterT40>
	<[email-masked]>
	<[email-masked]>
	<[email-masked]> <[email-masked]>
Message-ID: <[email-masked]>

On Friday, October 24, 2003, 5:17:25 PM, Simon wrote:

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

From: ben at morrow.me.uk ([email-masked])
Date: Tue Jan  3 16:22:37 2006
Subject: please review 'application/pdf'
In-Reply-To: <[email-masked]>
References: <000001c399a8$ed849370$c3432099@MasinterT40> <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]>
Message-ID: <[email-masked]>

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: <[email-masked]>
References: <000001c399a8$ed849370$c3432099@MasinterT40> <[email-masked]> <[email-masked]>
Message-ID: <[email-masked]>

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 [email-masked]  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: <[email-masked]>
References: <000001c399a8$ed849370$c3432099@MasinterT40>
	<[email-masked]>
	<[email-masked]>
	<[email-masked]> <[email-masked]>
Message-ID: <[email-masked]>

On Friday, October 24, 2003, 5:17:25 PM, Simon wrote:

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

From: chris at w3.org (Chris Lilley)
Date: Fri Oct 24 16:27:06 2003
Subject: Please review application/shf+xml
In-Reply-To: <[email-masked]>
References: <[email-masked]> <[email-masked]> <[email-masked]>
Message-ID: <[email-masked]>

On Friday, October 24, 2003, 11:44:30 AM, MURATA wrote:

MM> On Fri, 24 Oct 2003 03:22:46 +0200
MM> Chris Lilley <[email-masked]> 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:[email-masked]

From: jas at extundo.com (Simon Josefsson)
Date: Tue Jan  3 16:22:37 2006
Subject: please review 'application/pdf'
In-Reply-To: <[email-masked]> (Chris Lilley's message of "Fri, 24 Oct 2003 16:17:29 +0200")
References: <000001c399a8$ed849370$c3432099@MasinterT40> <[email-masked]> <[email-masked]> <[email-masked]>
Message-ID: <[email-masked]>

Chris Lilley <[email-masked]> writes:

> On Friday, October 24, 2003, 1:14:24 PM, Marc wrote:
>
> MM> On Friday 24 October 2003 00:13, Chris Lilley wrote:
> MM> <snip>
>>> 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> <snip>
>
> 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: <[email-masked]>
References: <[email-masked]> <[email-masked]> <[email-masked]>
Message-ID: <[email-masked]>

On Friday, October 24, 2003, 11:44:30 AM, MURATA wrote:

MM> On Fri, 24 Oct 2003 03:22:46 +0200
MM> Chris Lilley <[email-masked]> 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:[email-masked]

From: mutz at kde.org (Marc Mutz)
Date: Fri Oct 24 13:29:28 2003
Subject: please review 'application/pdf'
In-Reply-To: <[email-masked]>
References: <000001c399a8$ed849370$c3432099@MasinterT40> <[email-masked]>
Message-ID: <[email-masked]>

On Friday 24 October 2003 00:13, Chris Lilley wrote:
<snip>
> 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.
<snip>

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 [email-masked]  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: <[email-masked]>
References: <000001c399a8$ed849370$c3432099@MasinterT40>
	<[email-masked]>
	<[email-masked]>
Message-ID: <[email-masked]>

On Friday, October 24, 2003, 1:14:24 PM, Marc wrote:

MM> On Friday 24 October 2003 00:13, Chris Lilley wrote:
MM> <snip>
>> 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> <snip>

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

From: mutz at kde.org (Marc Mutz)
Date: Tue Jan  3 16:22:37 2006
Subject: please review 'application/pdf'
In-Reply-To: <[email-masked]>
References: <000001c399a8$ed849370$c3432099@MasinterT40> <[email-masked]>
Message-ID: <[email-masked]>

On Friday 24 October 2003 00:13, Chris Lilley wrote:
<snip>
> 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.
<snip>

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 [email-masked]  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: <[email-masked]>
References: <000001c399a8$ed849370$c3432099@MasinterT40>
	<[email-masked]>
	<[email-masked]>
Message-ID: <[email-masked]>

On Friday, October 24, 2003, 1:14:24 PM, Marc wrote:

MM> On Friday 24 October 2003 00:13, Chris Lilley wrote:
MM> <snip>
>> 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> <snip>

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

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

On Tue, 14 Oct 2003 14:52:44 -0700
Ben Kovitz <[email-masked]> 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 <[email-masked]>

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

On Fri, 24 Oct 2003 03:22:46 +0200
Chris Lilley <[email-masked]> 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 <[email-masked]>

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

On Fri, 24 Oct 2003 02:12:22 +0100
[email-masked] 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 <[email-masked]>

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

On Wed, 22 Oct 2003 16:39:17 +0200
Chris Lilley <[email-masked]> 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 <[email-masked]>

From: chris at w3.org (Chris Lilley)
Date: Tue Jan  3 16:22:36 2006
Subject: Please review application/shf+xml
In-Reply-To: <[email-masked]>
References: <[email-masked]> <[email-masked]> <[email-masked]>
Message-ID: <[email-masked]>

On Friday, October 24, 2003, 2:59:58 AM, MURATA wrote:

MM> On Wed, 22 Oct 2003 16:39:17 +0200
MM> Chris Lilley <[email-masked]> 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:[email-masked]

From: ben at morrow.me.uk ([email-masked])
Date: Fri Oct 24 03:12:38 2003
Subject: Please review application/shf+xml
In-Reply-To: <[email-masked]>
References: <[email-masked]> <[email-masked]> <[email-masked]>
Message-ID: <[email-masked]>

At  9am on 24/10/03 you (MURATA Makoto) wrote:
> 
> On Wed, 22 Oct 2003 16:39:17 +0200
> Chris Lilley <[email-masked]> 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
<snip>
|    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 [email-masked]  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: <[email-masked]>
References: <[email-masked]>
	<[email-masked]>
	<[email-masked]>
Message-ID: <[email-masked]>

On Friday, October 24, 2003, 2:59:58 AM, MURATA wrote:

MM> On Wed, 22 Oct 2003 16:39:17 +0200
MM> Chris Lilley <[email-masked]> 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:[email-masked]

From: ben at morrow.me.uk ([email-masked])
Date: Tue Jan  3 16:22:36 2006
Subject: Please review application/shf+xml
In-Reply-To: <[email-masked]>
References: <[email-masked]> <[email-masked]> <[email-masked]>
Message-ID: <[email-masked]>

At  9am on 24/10/03 you (MURATA Makoto) wrote:
> 
> On Wed, 22 Oct 2003 16:39:17 +0200
> Chris Lilley <[email-masked]> 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
<snip>
|    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: <[email-masked]>
References: <[email-masked]> <[email-masked]>
Message-ID: <[email-masked]>

On Wed, 22 Oct 2003 16:39:17 +0200
Chris Lilley <[email-masked]> 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 <[email-masked]>

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

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;[email-masked]%gt;

I guess that these should have been &lt; and &gt; in the xml source
and thus should be, in the text version,

  Adobe Developer Support <[email-masked]>

-- 
 Chris                            mailto:[email-masked]

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

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;[email-masked]%gt;

I guess that these should have been &lt; and &gt; in the xml source
and thus should be, in the text version,

  Adobe Developer Support <[email-masked]>

-- 
 Chris                            mailto:[email-masked]

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: <[email-masked]>
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 ([email-masked])
Date: Tue Jan  3 16:22:36 2006
Subject: Please review application/shf+xml
In-Reply-To: <[email-masked]>
References: <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]>
Message-ID: <[email-masked]>

At  7pm on 23/10/03 you (Linus Walleij) wrote:
> On Wed, 22 Oct 2003 [email-masked] 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.:

<newformat>
  <metadata value="foo"/>
  <hexdump type="text/shf">
[here follows an SHF object]
  </hexdump>
</newformat>

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

On Wed, 22 Oct 2003 [email-masked] 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: <[email-masked]>
References: <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]>
Message-ID: <[email-masked]>

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 ([email-masked])
Date: Wed Oct 22 18:24:22 2003
Subject: Please review application/shf+xml
In-Reply-To: <[email-masked]>
References: <[email-masked]> <[email-masked]> <[email-masked]>
Message-ID: <[email-masked]>

At  2pm on 22/10/03 you (Linus Walleij) wrote:
> On Wed, 22 Oct 2003 [email-masked] 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 <http://www.w3.org/TR/REC-xml-names>? 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 [email-masked]  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: <[email-masked]>
References: <[email-masked]>
	<[email-masked]>
	<[email-masked]>
	<[email-masked]>
Message-ID: <[email-masked]>

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

On Wed, 22 Oct 2003 [email-masked] 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 [email-masked]  Thu Oct 23 19:54:25 2003
From: ben at morrow.me.uk ([email-masked])
Date: Thu Oct 23 19:54:42 2003
Subject: Please review application/shf+xml
In-Reply-To: <[email-masked]>
References: <[email-masked]>
	<[email-masked]>
	<[email-masked]>
	<[email-masked]>
	<[email-masked]>
Message-ID: <[email-masked]>

At  7pm on 23/10/03 you (Linus Walleij) wrote:
> On Wed, 22 Oct 2003 [email-masked] 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.:

<newformat>
  <metadata value="foo"/>
  <hexdump type="text/shf">
[here follows an SHF object]
  </hexdump>
</newformat>

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 [email-masked]  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: <[email-masked]>
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 ([email-masked])
Date: Tue Jan  3 16:22:36 2006
Subject: Please review application/shf+xml
In-Reply-To: <[email-masked]>
References: <[email-masked]> <[email-masked]> <[email-masked]>
Message-ID: <[email-masked]>

At  2pm on 22/10/03 you (Linus Walleij) wrote:
> On Wed, 22 Oct 2003 [email-masked] 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 <http://www.w3.org/TR/REC-xml-names>? 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: <[email-masked]>
References: <[email-masked]> <[email-masked]> <[email-masked]>
Message-ID: <[email-masked]>

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

From: chris at w3.org (Chris Lilley)
Date: Tue Jan  3 16:22:36 2006
Subject: Please review application/shf+xml
In-Reply-To: <[email-masked]>
References: <[email-masked]> <[email-masked]> <[email-masked]>
Message-ID: <[email-masked]>

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

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

Please follow RFC 3023 and provide the charset parameter. 

Cheers,

-- 
MURATA Makoto <[email-masked]>

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

Thanks Ben! Your effort is much appreciated.

On Wed, 22 Oct 2003 [email-masked] wrote:

> In section 6 the draft states
>
> | Refer to this DTD as:
> |
> |     <!ENTITY % SHF PUBLIC "-//IETF//DTD SHF//EN"
> |                "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. (<?xml version="1.0" encoding="foo" ?>) I hope the above
conveys this clearly. So, a pedantically specified SHF file would begin:

<?xml version="1.0" encoding="UTF-8" ?>
<!DOCTYPE shf PUBLIC "-//IETF//DTD SHF//EN" "http://ietf.org/shf.dtd">
<dump ... etc

> 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 ([email-masked])
Date: Tue Jan  3 16:22:36 2006
Subject: Please review application/shf+xml
In-Reply-To: <[email-masked]>
References: <[email-masked]>
Message-ID: <[email-masked]>

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:
|
|     <!ENTITY % SHF PUBLIC "-//IETF//DTD SHF//EN"
|                "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. 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: <[email-masked]>

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 [email-masked]  Wed Oct 22 01:26:48 2003
From: ben at morrow.me.uk ([email-masked])
Date: Wed Oct 22 01:27:05 2003
Subject: Please review application/shf+xml
In-Reply-To: <[email-masked]>
References: <[email-masked]>
Message-ID: <[email-masked]>

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:
|
|     <!ENTITY % SHF PUBLIC "-//IETF//DTD SHF//EN"
|                "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. 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 [email-masked]  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: <[email-masked]>
References: <[email-masked]>
	<[email-masked]>
Message-ID: <[email-masked]>

Thanks Ben! Your effort is much appreciated.

On Wed, 22 Oct 2003 [email-masked] wrote:

> In section 6 the draft states
>
> | Refer to this DTD as:
> |
> |     <!ENTITY % SHF PUBLIC "-//IETF//DTD SHF//EN"
> |                "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. (<?xml version="1.0" encoding="foo" ?>) I hope the above
conveys this clearly. So, a pedantically specified SHF file would begin:

<?xml version="1.0" encoding="UTF-8" ?>
<!DOCTYPE shf PUBLIC "-//IETF//DTD SHF//EN" "http://ietf.org/shf.dtd">
<dump ... etc

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

Please follow RFC 3023 and provide the charset parameter. 

Cheers,

-- 
MURATA Makoto <[email-masked]>

From: triad at df.lth.se (Linus Walleij)
Date: Tue Jan  3 16:22:36 2006
Subject: Please review application/shf+xml
Message-ID: <[email-masked]>

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

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: <[email-masked]> <1065813828.30956.3.camel@felicia>
Message-ID: <[email-masked]>

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

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

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

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: <[email-masked]> <1065813828.30956.3.camel@felicia>
Message-ID: <[email-masked]>

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

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

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

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

From: ben at morrow.me.uk ([email-masked])
Date: Thu Oct  9 20:15:56 2003
Subject: Internet draft for sbml+xml media type
In-Reply-To: <[email-masked]>
References: <[email-masked]>
Message-ID: <[email-masked]>

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

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

From: ben at morrow.me.uk ([email-masked])
Date: Tue Jan  3 16:22:36 2006
Subject: Internet draft for sbml+xml media type
In-Reply-To: <[email-masked]>
References: <[email-masked]>
Message-ID: <[email-masked]>

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

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 [email-masked], a public mailing
   list with archives at <http://lists.w3.org/Archives/Public/www-math/>.

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

   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 "<math" near the beginning
   of the document.  Some will also begin with an XML declaration which
   begins with "<?xml", though that alone does not indicate a MathML
   document.  

5. Charset default rules

   By virtue of all MathML content being XML, it has the same
   considerations when sent as 'application/mathml+xml' as does XML
   ([XMLMIME], section 3.2) in the absence of the charset parameter.

6. Security Considerations

   The considerations for 'application/xml' as specified in [XMLMIME],
   also hold for 'application/mathml+xml'.

   In addition, several MathML instructions may cause arbitrary URIs
   to be dereferenced. In this case, the security issues of RFC1738,
   section 6, should be considered.

   Furthermore, because of the extensibility features that MathML
   defines, it is possible that 'application/mathml+xml' may describe
   content that has security implications beyond those described here.
   However, if the user agent follows the user agent conformance rules
   in [MATHML], this content will be ignored.  Only in the case where
   the user agent recognizes and processes the additional content, or
   where further processing of that content is dispatched to other
   processors, would security issues potentially arise.  And in that
   case, they would fall outside the domain of this registration
   document.

7.  Author's Address

   Max Froumentin
   W3C/ERCIM
   2004, route des Lucioles - B.P. 93
   06902 Sophia Antipolis Cedex
   FRANCE

   Phone: +33 (0)492387889
   Fax:+33 (0)492387822
   EMail: [email-masked]

8.  References

   [MATHML]    "Mathematical Markup Language (MathML) Version 2.0"
	       W3C Recommendation. Available at 
               <http://www.w3.org/TR/MathML2/>

   [HTML401]   Raggett, D., et al., "HTML 4.01 Specification", W3C
               Recommendation. Available at
               <http://www.w3.org/TR/html401> (or
               <http://www.w3.org/TR/1999/REC-html401-19991224>).

   [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 <http://www.w3.org/TR/xhtml1>.

   [XML]       "Extensible Markup Language (XML) 1.0", W3C
               Recommendation.  Available at <http://www.w3.org/TR/REC-
               xml> (or <http://www.w3.org/TR/2000/REC-xml-20001006>).

   [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: <http://www.w3.org/TR/xhtml-modularization>

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

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

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 [email-masked], a public mailing
   list with archives at <http://lists.w3.org/Archives/Public/www-math/>.

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

   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 "<math" near the beginning
   of the document.  Some will also begin with an XML declaration which
   begins with "<?xml", though that alone does not indicate a MathML
   document.  

5. Charset default rules

   By virtue of all MathML content being XML, it has the same
   considerations when sent as 'application/mathml+xml' as does XML
   ([XMLMIME], section 3.2) in the absence of the charset parameter.

6. Security Considerations

   The considerations for 'application/xml' as specified in [XMLMIME],
   also hold for 'application/mathml+xml'.

   In addition, several MathML instructions may cause arbitrary URIs
   to be dereferenced. In this case, the security issues of RFC1738,
   section 6, should be considered.

   Furthermore, because of the extensibility features that MathML
   defines, it is possible that 'application/mathml+xml' may describe
   content that has security implications beyond those described here.
   However, if the user agent follows the user agent conformance rules
   in [MATHML], this content will be ignored.  Only in the case where
   the user agent recognizes and processes the additional content, or
   where further processing of that content is dispatched to other
   processors, would security issues potentially arise.  And in that
   case, they would fall outside the domain of this registration
   document.

7.  Author's Address

   Max Froumentin
   W3C/ERCIM
   2004, route des Lucioles - B.P. 93
   06902 Sophia Antipolis Cedex
   FRANCE

   Phone: +33 (0)492387889
   Fax:+33 (0)492387822
   EMail: [email-masked]

8.  References

   [MATHML]    "Mathematical Markup Language (MathML) Version 2.0"
	       W3C Recommendation. Available at 
               <http://www.w3.org/TR/MathML2/>

   [HTML401]   Raggett, D., et al., "HTML 4.01 Specification", W3C
               Recommendation. Available at
               <http://www.w3.org/TR/html401> (or
               <http://www.w3.org/TR/1999/REC-html401-19991224>).

   [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 <http://www.w3.org/TR/xhtml1>.

   [XML]       "Extensible Markup Language (XML) 1.0", W3C
               Recommendation.  Available at <http://www.w3.org/TR/REC-
               xml> (or <http://www.w3.org/TR/2000/REC-xml-20001006>).

   [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: <http://www.w3.org/TR/xhtml-modularization>

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

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