Re: Hi

Re: Thank you!

MIME Type Review Request: image/svg+xml

Please review the Media Type registration template described below. It
is available in HTML [1] or in plain text form [2] and relates to the
SVG specification [3]. Registration of this Media Type in the standards
tree is requested, in conformance with [4] and [5].

      [1] http://www.w3.org/TR/SVG12/mimereg.html
      [2] http://www.w3.org/TR/SVG12/mimereg.html,text
      [3] http://www.w3.org/TR/SVG12/
      [4] http://www.ietf.org/internet-drafts/draft-freed-media-type-reg-01.txt
      [5] http://www.w3.org/2002/06/registering-mediatype

Registration of Media Type image/svg+xml

   MIME media type name:
          image

   MIME subtype name:
          svg+xml

   Required parameters:
          None.

   Optional parameters:
          None

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

      [6] http://www.w3.org/TR/SVG12/references

   Encoding considerations:
          Same as for application/xml. See [7]RFC3023 , section 3.2.

      [7] http://www.w3.org/TR/SVG12/references

   Restrictions on usage:
          None

   Security considerations:
          As with other XML types and as noted in [8]RFC3023 section 10,
          repeated expansion of maliciously constructed XML entities can
          be used to consume large amounts of memory, which may cause XML
          processors in constrained environments to fail.

      [8] http://www.w3.org/TR/SVG12/references

          SVG documents may be transmitted in compressed form using gzip
          compression. For systems which employ MIME-like mechanisms,
          such as HTTP, this is indicated by the
          Content-Transfer-Encoding header; for systems which do not,
          such as direct filesystem access, this is indicated by the
          filename extension and by the Macintosh File Type Codes. In
          addition, gzip compressed content is readily recognised by the
          initial byte sequence as described in [9]RFC1952 section 2.3.1.

      [9] http://www.w3.org/TR/SVG12/references

          Several SVG elements may cause arbitrary URIs to be referenced.
          In this case, the security issues of [10]RFC2396, section 7,
          should be considered.

     [10] http://www.w3.org/TR/SVG12/references

          In common with HTML, SVG documents may reference external media
          such as images, audio, video, style sheets, and scripting
          languages. Scripting languages are executable content. In this
          case, the security considerations in the Media Type
          registrations for those formats apply.

          In addition, because of the extensibility features for SVG and
          of XML in general, it is possible that "image/svg+xml" may
          describe content that has security implications beyond those
          described here. However, if the processor follows only the
          normative semantics of this specification, this content will be
          outside the SVG namespace and will be ignored. Only in the case
          where the processor recognizes and processes the additional
          content, or where further processing of that content is
          dispatched to other processors, would security issues
          potentially arise. And in that case, they would fall outside
          the domain of this registration document.

   Interoperability considerations:
          This specification describes processing semantics that dictate
          behavior that must be followed when dealing with, among other
          things, unrecognized elements and attributes, both in the SVG
          namespace and in other namespaces.

          Because SVG is extensible, conformant "image/svg+xml"
          processors must expect that content received is well-formed
          XML, but it cannot be guaranteed that the content is valid to a
          particular DTD or Schema or that the processor will recognize
          all of the elements and attributes in the document.

          SVG has a published Test Suite and associated implementation
          report showing which implementations passed which tests at the
          time of the report. This information is periodically updated as
          new tests are added or as implementations improve.

   Published specification:
          This media type registration is extracted from Appendix G of
          the SVG 1.2 specification.

   Additional information:

   Person & email address to contact for further information:
          Dean Jackson, (dean <at> w3.org).

   Intended usage:
          COMMON

   Author/Change controller:
          The SVG specification is a work product of the World Wide Web
          Consortium's SVG Working Group. The W3C has change control over
          these specifications.

--

-- 
 Chris Lilley                    mailto:chris <at> w3.org
 Chair, W3C SVG Working Group
 Member, W3C Technical Architecture Group

Re:

Potentially Dangerous Attachment Removed. The file "price.com" has been blocked.  File quarantined as: "".

Re: MIME Type Review Request: image/svg+xml

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

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

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

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

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

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

Regards,    Martin.

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

Re: 3023 update (was Re: Agenda TAG Telcon: 8th Nov 2004)

[copying ietf-xml-mime <at> imc.org, because that's really where discussion
on the RFC 3023 update should occur]

At 10:22 04/11/16, Tim Bray wrote:
 >
 >On Nov 8, 2004, at 12:01 PM, Chris Lilley wrote:
 >
 >> - the addition of XPointer as fragment identifiers (in current -00
 >> draft)
 >
 >I oppose this, at least partly on the grounds of absence of use-cases.

I think "XPointer as fragment id" is much too general to be able to
agree or disagree. Possibilities range from "we suggest to stay within
the XPointer framework when defining fragment ids for +xml media types"
to "all +xml media types from now on have to understand the following
XPointer schemes .... (long list)".

Please publish a draft, so that everybody can look at it and comment.

Regards,   Martin. 

Re: 3023 update (was Re: Agenda TAG Telcon: 8th Nov 2004)

On Fri, 19 Nov 2004 08:58:52 +0900
Martin Duerst <duerst <at> w3.org> wrote:

> Please publish a draft, so that everybody can look at it and comment.

http://www.ietf.org/internet-drafts/draft-murata-kohn-lilley-xml-00.txt 
(published in July) already has a section for XPointer.  It allows 
a bare minimum.

Cheers,
Makoto

> 5.  Fragment Identifiers
> 
>    Uniform Resource Identifiers (URIs) may contain fragement identifiers
>    (see Section 3.5 of [RFC2396bis]).  Likewise, Internationalized
>    Resource Identifiers (IRIs) [IRI] may contain fragement identifiers.
> 
>    A family of specifications define fragment identifiers for XML media
>    types.  The fragment identifier syntax for application/xml is defined
>    by two W3C Recommendations in this family, namely [XPointerFramework]
>    and [XPointerElement].  Schemes other than the element scheme MUST
>    NOT be specified as part of fragment identifiers for these media
>    types.  In particular, the xpointer scheme MUST NOT be specified
>    since it is still at the W3C working draft stage.
> 
>    When an XML-based MIME media type follows the naming convention
>    '+xml', the fragment identifier syntax for this media type SHALL
>    include the fragment identifier syntax for application/xml and
>    application/xml-external-parsed-entity.  It MAY further allow other
>    schemes such as the xmlns scheme and other schemes.
> 
>    If an XML-based media type requires a fragment identifier syntax
>    other than XPointer, the media type SHOULD NOT follow the naming
>    convention '+xml'.
> 
>    When a URI has a fragment identifier, it is encoded by a limited
>    subset of the repertoire of US-ASCII [ASCII] characters, as defined
>    in [RFC2396bis].  When a IRI contains a fragment identifier, it is
>    encoded by a much wider repertoire of characters.  The conversion
>    between IRI fragment identifiers and URI fragment identifiers is
>    presented in Section 7 of [IRI].
> 

--

-- 
MURATA Makoto <murata <at> hokkaido.email.ne.jp>

Re: Hi

Dangerous Attachment has been Removed.  The file "Joke.exe" has been removed because of a virus.  It was
infected with the "W32/Bagle.BC-mm" virus.  File quarantined as: "". http://www.fortinet.com/VirusEncyclopedia/search/encyclopediaSearch.do?method=quickSearchDirectly&virusName=W32%2FBagle.BC-mm

Re: MIME Type Review Request: image/svg+xml

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

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

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

Thanks, I will take a look.

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

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

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

Yes.

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

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

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

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

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

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

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

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

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

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

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

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

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

In conclusion your proposed addition increases complexity, decreases
interoperability, is contrary to existing practice, and provides no
benefit. I thus find it a less than compelling addition.

--

-- 
 Chris Lilley                    mailto:chris <at> w3.org
 Chair, W3C SVG Working Group
 Member, W3C Technical Architecture Group

Re: MIME Type Review Request: image/svg+xml

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

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

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

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

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

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

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

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