Subject: Registration of media type "application/nss"
From: sah at 428cobrajet.net (Scott Hollenbeck)
Date: Fri Dec 31 01:59:03 2004

Mike,

Request received.  I will shepherd your request once the ietf-types review
has been completed and any comments have been addressed.  Please contact me
directly at the end of the two-week review period and we'll go from there.

Can you provide a link to the published specification referenced below?

-Scott-

> -----Original Message-----
> From: Mike Hammer [mailto:[email-masked]] 
> Sent: Thursday, December 30, 2004 1:52 PM
> To: [email-masked]
> Cc: [email-masked]; [email-masked]
> Subject: Registration of media type "application/nss"
> 
> This email requests that the IESG approve the assignment of 
> the media subtype as described in the registration template below.
> 
> Reference:  draft-freed-media-type-reg-01.txt, August 17, 2004,
>             Media Type Specifications and Registration Procedures, 
>             Section 5, Registration Procedures,
>             Section 10, Registration Template.
> 
> To: [email-masked]
> Subject: Registration of media type "application/nss"
> 
> Type name: application
> 
> Subtype name: nss
> 
> Required parameters: none
> 
> Optional parameters: charset
> 
> Encoding considerations: binary (Note:  Data is in US-ASCII range.)
> 
> Restrictions on usage: none
> 
> Security considerations: 
> 
>    NSS has the potential to disclose private customer information
>    and the potential for modification of NSS bodies during message
>    transport to manipulate call setup, mid-call events, or call 
>    release.  Modification means the addition of an NSS body where
>    none existed, the removal of an NSS body where one existed, or 
>    the changing of contents of existing NSS bodies in messages.   
>    NSS can reveal information about telephone subscribers that is 
>    requested to remain private.  Security mechanisms must be 
>    provided to meet privacy agreements and regulations.  
> 
>    NSS can be deployed as an interdomain signaling mechanism and 
>    may be subject to trust relationships and agreements between 
>    administrative domains as well as legal requirements in various 
>    jurisdictions.  NSS can affect routing of telephone calls and 
>    associated billing.  Security mechanisms must be provided to 
>    control fraud, malicious intents, and unintended consequences.
>    Such mechanisms include the ability to selectively filter or map
>    and forward each information element within NSS upon entry or exit
>    of an administrative domain.  All information from unauthenticated
>    entities must be validated and authorized before being mapped and 
>    forwarded in subsequent signaling messages.  Such checks are 
>    particularly needed when information is mapped to/from SIP headers.
> 
>    When encapsulated by SIP, the integrity and confidentiality of SIP 
>    messages containing NSS bodies MUST be addressed through 
> the use of 
>    Transport Layer Security (TLS) or Internet Protocol 
> Security (IPSEC) 
>    mechanisms as described in the Session Initiation Protocol RFC 3261
>    on signaling hops between nodes trusted to handle PSTN signaling.  
>    When intermediate hops are not trusted, end-to-end integrity and 
>    confidentiality may be addressed using RFC 2633, 
> "Secure/Multipurpose
>    Internet Mail Extensions (S/MIME) Version 3 Message 
> Specification", 
>    June 1999.  NSS MIME bodies SHOULD be secured using S/MIME 
> to mitigate
>    concerns with authentication of the sender, integrity protection 
>    during transit, and confidentiality protection from disclosure to 
>    unauthorized third parties.  NSS endpoints MUST support S/MIME 
>    signatures and SHOULD support S/MIME encryption.  
> 
>    For H.323-based encapsulation of NSS bodies, the security 
> mechanisms
>    of ITU-T Recommendation H.235, "Security and encryption 
> for H-series
>    (H.323 and other H.245-based) multimedia terminals", 
> August 2003, must 
>    be used to provide integrity and confidentiality.
> 
>    NSS consists of well defined message types and parameters. 
>  Arbitrary 
>    content or directives within field values is not permitted.
> 
>    NSS does not employ "active content."
> 
>    NSS contains fields which instruct whether privacy data such as 
>    calling party's number is to be presented or restricted.
> 
>    NSS is used without and is silent about compression.  Use 
> of compression 
>    in conjunction with NSS does not present any security issues.
> 
> Interoperability considerations:  Compatibility mechanisms are 
>    defined in Q.1980.1.
> 
> Published specification:  ITU-T Recommendation Q.1980.1, "The 
> Narrowband 
>    Signalling Syntax (NSS) - Syntax Definition", December 2004.
> 
> Applications which use this media type:  Applications in PSTN
>    Gateways and call control application servers.
> 
> Additional Information:
> 
>    Magic numbers:  None
> 
>    File Extensions:  None
> 
>    Macintosh File Type Codes:  None
> 
>    Object Identifiers:  {itu-t(0) recommendation(0) q(17) 1980 1}
>                         (0.0.17.1980.1)
>       See ITU-T Recommendation H.323 Annex M.4 "Tunnelling of 
>       Narrowband Signalling Syntax (NSS) for H.323", December 2004.
> 
>    Intended Usage:  COMMON
> 
> Person to contact for further information:
> 
>    Name:  Michael Hammer
>    E-Mail:  [email-masked]
>    Author/Change controller:  ITU-T Study Group 11
> 
> END
> 
> 

From: sah at 428cobrajet.net (Scott Hollenbeck)
Date: Tue Jan  3 16:22:53 2006
Subject: Registration of media type "application/nss"
In-Reply-To: <[email-masked]>
Message-ID: <20041231005848.ZRJR16610.lakermmtao08.cox.net@A31P>

Mike,

Request received.  I will shepherd your request once the ietf-types review
has been completed and any comments have been addressed.  Please contact me
directly at the end of the two-week review period and we'll go from there.

Can you provide a link to the published specification referenced below?

-Scott-

> -----Original Message-----
> From: Mike Hammer [mailto:[email-masked]] 
> Sent: Thursday, December 30, 2004 1:52 PM
> To: [email-masked]
> Cc: [email-masked]; [email-masked]
> Subject: Registration of media type "application/nss"
> 
> This email requests that the IESG approve the assignment of 
> the media subtype as described in the registration template below.
> 
> Reference:  draft-freed-media-type-reg-01.txt, August 17, 2004,
>             Media Type Specifications and Registration Procedures, 
>             Section 5, Registration Procedures,
>             Section 10, Registration Template.
> 
> To: [email-masked]
> Subject: Registration of media type "application/nss"
> 
> Type name: application
> 
> Subtype name: nss
> 
> Required parameters: none
> 
> Optional parameters: charset
> 
> Encoding considerations: binary (Note:  Data is in US-ASCII range.)
> 
> Restrictions on usage: none
> 
> Security considerations: 
> 
>    NSS has the potential to disclose private customer information
>    and the potential for modification of NSS bodies during message
>    transport to manipulate call setup, mid-call events, or call 
>    release.  Modification means the addition of an NSS body where
>    none existed, the removal of an NSS body where one existed, or 
>    the changing of contents of existing NSS bodies in messages.   
>    NSS can reveal information about telephone subscribers that is 
>    requested to remain private.  Security mechanisms must be 
>    provided to meet privacy agreements and regulations.  
> 
>    NSS can be deployed as an interdomain signaling mechanism and 
>    may be subject to trust relationships and agreements between 
>    administrative domains as well as legal requirements in various 
>    jurisdictions.  NSS can affect routing of telephone calls and 
>    associated billing.  Security mechanisms must be provided to 
>    control fraud, malicious intents, and unintended consequences.
>    Such mechanisms include the ability to selectively filter or map
>    and forward each information element within NSS upon entry or exit
>    of an administrative domain.  All information from unauthenticated
>    entities must be validated and authorized before being mapped and 
>    forwarded in subsequent signaling messages.  Such checks are 
>    particularly needed when information is mapped to/from SIP headers.
> 
>    When encapsulated by SIP, the integrity and confidentiality of SIP 
>    messages containing NSS bodies MUST be addressed through 
> the use of 
>    Transport Layer Security (TLS) or Internet Protocol 
> Security (IPSEC) 
>    mechanisms as described in the Session Initiation Protocol RFC 3261
>    on signaling hops between nodes trusted to handle PSTN signaling.  
>    When intermediate hops are not trusted, end-to-end integrity and 
>    confidentiality may be addressed using RFC 2633, 
> "Secure/Multipurpose
>    Internet Mail Extensions (S/MIME) Version 3 Message 
> Specification", 
>    June 1999.  NSS MIME bodies SHOULD be secured using S/MIME 
> to mitigate
>    concerns with authentication of the sender, integrity protection 
>    during transit, and confidentiality protection from disclosure to 
>    unauthorized third parties.  NSS endpoints MUST support S/MIME 
>    signatures and SHOULD support S/MIME encryption.  
> 
>    For H.323-based encapsulation of NSS bodies, the security 
> mechanisms
>    of ITU-T Recommendation H.235, "Security and encryption 
> for H-series
>    (H.323 and other H.245-based) multimedia terminals", 
> August 2003, must 
>    be used to provide integrity and confidentiality.
> 
>    NSS consists of well defined message types and parameters. 
>  Arbitrary 
>    content or directives within field values is not permitted.
> 
>    NSS does not employ "active content."
> 
>    NSS contains fields which instruct whether privacy data such as 
>    calling party's number is to be presented or restricted.
> 
>    NSS is used without and is silent about compression.  Use 
> of compression 
>    in conjunction with NSS does not present any security issues.
> 
> Interoperability considerations:  Compatibility mechanisms are 
>    defined in Q.1980.1.
> 
> Published specification:  ITU-T Recommendation Q.1980.1, "The 
> Narrowband 
>    Signalling Syntax (NSS) - Syntax Definition", December 2004.
> 
> Applications which use this media type:  Applications in PSTN
>    Gateways and call control application servers.
> 
> Additional Information:
> 
>    Magic numbers:  None
> 
>    File Extensions:  None
> 
>    Macintosh File Type Codes:  None
> 
>    Object Identifiers:  {itu-t(0) recommendation(0) q(17) 1980 1}
>                         (0.0.17.1980.1)
>       See ITU-T Recommendation H.323 Annex M.4 "Tunnelling of 
>       Narrowband Signalling Syntax (NSS) for H.323", December 2004.
> 
>    Intended Usage:  COMMON
> 
> Person to contact for further information:
> 
>    Name:  Michael Hammer
>    E-Mail:  [email-masked]
>    Author/Change controller:  ITU-T Study Group 11
> 
> END
> 
> 

From: mhammer at cisco.com (Mike Hammer)
Date: Thu Jan 20 19:33:09 2005
Subject: Registration of media type "application/nss"
Message-ID: <[email-masked]>

This email requests that the IESG approve the assignment of the 
media subtype as described in the registration template below.

Reference:  draft-freed-media-type-reg-01.txt, August 17, 2004,
            Media Type Specifications and Registration Procedures, 
            Section 5, Registration Procedures,
            Section 10, Registration Template.

To: [email-masked]
Subject: Registration of media type "application/nss"

Type name: application

Subtype name: nss

Required parameters: none

Optional parameters: charset

Encoding considerations: binary (Note:  Data is in US-ASCII range.)

Restrictions on usage: none

Security considerations: 

   NSS has the potential to disclose private customer information
   and the potential for modification of NSS bodies during message
   transport to manipulate call setup, mid-call events, or call 
   release.  Modification means the addition of an NSS body where
   none existed, the removal of an NSS body where one existed, or 
   the changing of contents of existing NSS bodies in messages.   
   NSS can reveal information about telephone subscribers that is 
   requested to remain private.  Security mechanisms must be 
   provided to meet privacy agreements and regulations.  

   NSS can be deployed as an interdomain signaling mechanism and 
   may be subject to trust relationships and agreements between 
   administrative domains as well as legal requirements in various 
   jurisdictions.  NSS can affect routing of telephone calls and 
   associated billing.  Security mechanisms must be provided to 
   control fraud, malicious intents, and unintended consequences.
   Such mechanisms include the ability to selectively filter or map
   and forward each information element within NSS upon entry or exit
   of an administrative domain.  All information from unauthenticated
   entities must be validated and authorized before being mapped and 
   forwarded in subsequent signaling messages.  Such checks are 
   particularly needed when information is mapped to/from SIP headers.

   When encapsulated by SIP, the integrity and confidentiality of SIP 
   messages containing NSS bodies MUST be addressed through the use of 
   Transport Layer Security (TLS) or Internet Protocol Security (IPSEC) 
   mechanisms as described in the Session Initiation Protocol RFC 3261
   on signaling hops between nodes trusted to handle PSTN signaling.  
   When intermediate hops are not trusted, end-to-end integrity and 
   confidentiality may be addressed using RFC 2633, "Secure/Multipurpose
   Internet Mail Extensions (S/MIME) Version 3 Message Specification", 
   June 1999.  NSS MIME bodies SHOULD be secured using S/MIME to mitigate
   concerns with authentication of the sender, integrity protection 
   during transit, and confidentiality protection from disclosure to 
   unauthorized third parties.  NSS endpoints MUST support S/MIME 
   signatures and SHOULD support S/MIME encryption.  

   For H.323-based encapsulation of NSS bodies, the security mechanisms
   of ITU-T Recommendation H.235, "Security and encryption for H-series
   (H.323 and other H.245-based) multimedia terminals", August 2003, must 
   be used to provide integrity and confidentiality.

   NSS consists of well defined message types and parameters.  Arbitrary 
   content or directives within field values is not permitted.

   NSS does not employ "active content."

   NSS contains fields which instruct whether privacy data such as 
   calling party's number is to be presented or restricted.

   NSS is used without and is silent about compression.  Use of compression 
   in conjunction with NSS does not present any security issues.

Interoperability considerations:  Compatibility mechanisms are 
   defined in Q.1980.1.

Published specification:  ITU-T Recommendation Q.1980.1, "The Narrowband 
   Signalling Syntax (NSS) - Syntax Definition", December 2004.

Applications which use this media type:  Applications in PSTN
   Gateways and call control application servers.

Additional Information:

   Magic numbers:  None

   File Extensions:  None

   Macintosh File Type Codes:  None

   Object Identifiers:  {itu-t(0) recommendation(0) q(17) 1980 1}
                        (0.0.17.1980.1)
      See ITU-T Recommendation H.323 Annex M.4 "Tunnelling of 
      Narrowband Signalling Syntax (NSS) for H.323", December 2004.

   Intended Usage:  COMMON

Person to contact for further information:

   Name:  Michael Hammer
   E-Mail:  [email-masked]
   Author/Change controller:  ITU-T Study Group 11

END
>From [email-masked]  Wed Dec  1 20:57:32 2004
From: mankin at psg.com (Allison Mankin)
Date: Tue Jan  3 16:22:52 2006
Subject: Media Type review request for video/h264
Message-ID: <[email-masked]>

The Transport Area requests a Media Type review for a new type,
video/h264, intended for the IETF tree, and specified in 
http://www.ietf.org/internet-drafts/draft-ietf-avt-rtp-h264-11.txt
(Section 8.1).

We believe the change controller should be the IESG rather than a
working group.  Please let us know any other issues asap.

Thanks,

Allison

From: mhammer at cisco.com (Mike Hammer)
Date: Tue Jan  3 16:22:54 2006
Subject: Registration of media type "application/nss"
Message-ID: <[email-masked]>

This email requests that the IESG approve the assignment of the 
media subtype as described in the registration template below.

Reference:  draft-freed-media-type-reg-01.txt, August 17, 2004,
            Media Type Specifications and Registration Procedures, 
            Section 5, Registration Procedures,
            Section 10, Registration Template.

To: [email-masked]
Subject: Registration of media type "application/nss"

Type name: application

Subtype name: nss

Required parameters: none

Optional parameters: charset

Encoding considerations: binary (Note:  Data is in US-ASCII range.)

Restrictions on usage: none

Security considerations: 

   NSS has the potential to disclose private customer information
   and the potential for modification of NSS bodies during message
   transport to manipulate call setup, mid-call events, or call 
   release.  Modification means the addition of an NSS body where
   none existed, the removal of an NSS body where one existed, or 
   the changing of contents of existing NSS bodies in messages.   
   NSS can reveal information about telephone subscribers that is 
   requested to remain private.  Security mechanisms must be 
   provided to meet privacy agreements and regulations.  

   NSS can be deployed as an interdomain signaling mechanism and 
   may be subject to trust relationships and agreements between 
   administrative domains as well as legal requirements in various 
   jurisdictions.  NSS can affect routing of telephone calls and 
   associated billing.  Security mechanisms must be provided to 
   control fraud, malicious intents, and unintended consequences.
   Such mechanisms include the ability to selectively filter or map
   and forward each information element within NSS upon entry or exit
   of an administrative domain.  All information from unauthenticated
   entities must be validated and authorized before being mapped and 
   forwarded in subsequent signaling messages.  Such checks are 
   particularly needed when information is mapped to/from SIP headers.

   When encapsulated by SIP, the integrity and confidentiality of SIP 
   messages containing NSS bodies MUST be addressed through the use of 
   Transport Layer Security (TLS) or Internet Protocol Security (IPSEC) 
   mechanisms as described in the Session Initiation Protocol RFC 3261
   on signaling hops between nodes trusted to handle PSTN signaling.  
   When intermediate hops are not trusted, end-to-end integrity and 
   confidentiality may be addressed using RFC 2633, "Secure/Multipurpose
   Internet Mail Extensions (S/MIME) Version 3 Message Specification", 
   June 1999.  NSS MIME bodies SHOULD be secured using S/MIME to mitigate
   concerns with authentication of the sender, integrity protection 
   during transit, and confidentiality protection from disclosure to 
   unauthorized third parties.  NSS endpoints MUST support S/MIME 
   signatures and SHOULD support S/MIME encryption.  

   For H.323-based encapsulation of NSS bodies, the security mechanisms
   of ITU-T Recommendation H.235, "Security and encryption for H-series
   (H.323 and other H.245-based) multimedia terminals", August 2003, must 
   be used to provide integrity and confidentiality.

   NSS consists of well defined message types and parameters.  Arbitrary 
   content or directives within field values is not permitted.

   NSS does not employ "active content."

   NSS contains fields which instruct whether privacy data such as 
   calling party's number is to be presented or restricted.

   NSS is used without and is silent about compression.  Use of compression 
   in conjunction with NSS does not present any security issues.

Interoperability considerations:  Compatibility mechanisms are 
   defined in Q.1980.1.

Published specification:  ITU-T Recommendation Q.1980.1, "The Narrowband 
   Signalling Syntax (NSS) - Syntax Definition", December 2004.

Applications which use this media type:  Applications in PSTN
   Gateways and call control application servers.

Additional Information:

   Magic numbers:  None

   File Extensions:  None

   Macintosh File Type Codes:  None

   Object Identifiers:  {itu-t(0) recommendation(0) q(17) 1980 1}
                        (0.0.17.1980.1)
      See ITU-T Recommendation H.323 Annex M.4 "Tunnelling of 
      Narrowband Signalling Syntax (NSS) for H.323", December 2004.

   Intended Usage:  COMMON

Person to contact for further information:

   Name:  Michael Hammer
   E-Mail:  [email-masked]
   Author/Change controller:  ITU-T Study Group 11

END

From: mankin at psg.com (Allison Mankin)
Date: Wed Dec 22 19:51:39 2004
Subject: Media Type review request for video/raw
Message-ID: <[email-masked]>

The Transport Area requests a Media Type review for the proposed
new type video/raw, intended for the IETF tree, and specified in 
http://www.ietf.org/internet-drafts/draft-ietf-uncomp-video-06.txt
(Section 6.1).

We know of the following needed changes:

1.
Author will be separated from Change Controller,
and Change Controller will be modified to
"AVT Working Group delegated from the IESG"

2.
The text "No file format is defined at this time" should
be changed to something like "A file format media type
is not defined for this media type at this time"

We'll also advise removing the empty fields for Magic Number, File
extension, and Macintosh File Type.

Please provide any comments as soon as possible.

Thanks,

Allison

From: mankin at psg.com (Allison Mankin)
Date: Tue Jan  3 16:22:53 2006
Subject: Media Type review request for video/raw
Message-ID: <[email-masked]>

The Transport Area requests a Media Type review for the proposed
new type video/raw, intended for the IETF tree, and specified in 
http://www.ietf.org/internet-drafts/draft-ietf-uncomp-video-06.txt
(Section 6.1).

We know of the following needed changes:

1.
Author will be separated from Change Controller,
and Change Controller will be modified to
"AVT Working Group delegated from the IESG"

2.
The text "No file format is defined at this time" should
be changed to something like "A file format media type
is not defined for this media type at this time"

We'll also advise removing the empty fields for Magic Number, File
extension, and Macintosh File Type.

Please provide any comments as soon as possible.

Thanks,

Allison

From: mankin at psg.com (Allison Mankin)
Date: Tue Jan  3 16:22:53 2006
Subject: Media Type review request for audio/ video/ text/ and application/rtx
Message-ID: <[email-masked]>

The Transport Area requests a Media Type review for four proposed
new types: audio/rtx, video/rtx,  text/rxt and application/rtx,
intended for the IETF tree, and specified in 
http://www.ietf.org/internet-drafts/draft-ietf-avt-rtp-retransmission-10.txt
(Section 8).

We know of one needed change:

Author will be separated from Change Controller,
and Change Controller will be modified to
"AVT Working Group delegated from the IESG"

Please provide any other comments as soon as possible.  Note that
these media types are defined only for transport via RTP.

Thanks,

Allison

From: hisham.khartabil at telio.no (Hisham Khartabil)
Date: Thu Jan 20 19:33:06 2005
Subject: Media Types review
Message-ID: <[email-masked]>

The SIMPLE Working Group requests a Media Type review for the following 
4 new types:

- application/xcap-el+xml
- application/xcap-att+xml
- application/xcap-error+xml
- application/xcap-caps+xml MIME Type

These are intended for the IETF tree, and specified in section 14.2 of 
http://www.ietf.org/internet-drafts/draft-ietf-simple-xcap-05.txt

Thanks,
Hisham Khartabil
SIMPLE WG Co-chair

From: hisham.khartabil at telio.no (Hisham Khartabil)
Date: Tue Jan  3 16:22:54 2006
Subject: Media Types review
Message-ID: <[email-masked]>

The SIMPLE Working Group requests a Media Type review for the following 
4 new types:

- application/xcap-el+xml
- application/xcap-att+xml
- application/xcap-error+xml
- application/xcap-caps+xml MIME Type

These are intended for the IETF tree, and specified in section 14.2 of 
http://www.ietf.org/internet-drafts/draft-ietf-simple-xcap-05.txt

Thanks,
Hisham Khartabil
SIMPLE WG Co-chair

From: derhoermi at gmx.net (Bjoern Hoehrmann)
Date: Sat Dec 11 01:06:52 2004
Subject: SVG12: image/svg+xml gzip requirements
In-Reply-To: <[email-masked]>
References: <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]>
Message-ID: <[email-masked]>

* Chris Lilley wrote:
>>>No, it does not. An xml encoding declaration is sender provided
>>>metadata. However, in the case where a charset parameter is allowed, and
>>>where it can be different, and thus where one has to win over the other,
>>>metadata is indeed being overridden. I agree with you that silent
>>>recovery here is not inthe user interest and a warning should be shown.
>
>BH> You either missed that the mail you responded to did not discuss the
>BH> charset parameter at all, or you are trying to suggest that there is
>BH> a character encoding that is based on gzip.
>
>Neither, but you missed that I was deleting the bits about gzip and
>responding only to character encoding, not content transfer encoding. I
>should have signalled that with a change to the subject line.

I am sorry if my message gave you the impression that it is reasonable
to imply that it discussed anything but gzip compressed image/svg+xml
content that is not marked as such. I assumed that this was obvious from
the subject line, the context of the message, the parts I've quoted and
the literal message text which all mentioned gzip but did not mention
character encodings.
-- 
Bj?rn H?hrmann ? mailto:[email-masked] ? http://bjoern.hoehrmann.de
Weinh. Str. 22 ? Telefon: +49(0)621/4309674 ? http://www.bjoernsworld.de
68309 Mannheim ? PGP Pub. KeyID: 0xA4357E78 ? http://www.websitedev.de/ 
>From [email-masked]  Wed Dec 22 17:06:07 2004
From: mankin at psg.com (Allison Mankin)
Date: Wed Dec 22 17:06:12 2004
Subject: Media Type review request for audio/ video/ text/ and
	application/rtx
Message-ID: <[email-masked]>

The Transport Area requests a Media Type review for four proposed
new types: audio/rtx, video/rtx,  text/rxt and application/rtx,
intended for the IETF tree, and specified in 
http://www.ietf.org/internet-drafts/draft-ietf-avt-rtp-retransmission-10.txt
(Section 8).

We know of one needed change:

Author will be separated from Change Controller,
and Change Controller will be modified to
"AVT Working Group delegated from the IESG"

Please provide any other comments as soon as possible.  Note that
these media types are defined only for transport via RTP.

Thanks,

Allison

From: derhoermi at gmx.net (Bjoern Hoehrmann)
Date: Tue Jan  3 16:22:53 2006
Subject: SVG12: image/svg+xml gzip requirements
In-Reply-To: <[email-masked]>
References: <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]>
Message-ID: <[email-masked]>

* Chris Lilley wrote:
>>>No, it does not. An xml encoding declaration is sender provided
>>>metadata. However, in the case where a charset parameter is allowed, and
>>>where it can be different, and thus where one has to win over the other,
>>>metadata is indeed being overridden. I agree with you that silent
>>>recovery here is not inthe user interest and a warning should be shown.
>
>BH> You either missed that the mail you responded to did not discuss the
>BH> charset parameter at all, or you are trying to suggest that there is
>BH> a character encoding that is based on gzip.
>
>Neither, but you missed that I was deleting the bits about gzip and
>responding only to character encoding, not content transfer encoding. I
>should have signalled that with a change to the subject line.

I am sorry if my message gave you the impression that it is reasonable
to imply that it discussed anything but gzip compressed image/svg+xml
content that is not marked as such. I assumed that this was obvious from
the subject line, the context of the message, the parts I've quoted and
the literal message text which all mentioned gzip but did not mention
character encodings.
-- 
Bj?rn H?hrmann ? mailto:[email-masked] ? http://bjoern.hoehrmann.de
Weinh. Str. 22 ? Telefon: +49(0)621/4309674 ? http://www.bjoernsworld.de
68309 Mannheim ? PGP Pub. KeyID: 0xA4357E78 ? http://www.websitedev.de/ 

From: chris at w3.org (Chris Lilley)
Date: Sat Dec 11 00:26:40 2004
Subject: SVG12: image/svg+xml gzip requirements
In-Reply-To: <[email-masked]>
References: <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]>
Message-ID: <[email-masked]>

On Friday, December 10, 2004, 5:15:01 AM, Boris wrote:

BZ> Chris Lilley wrote:
>> IH> I would strongly recommend that specs disallow sniffing of any kind,
>> IH> treating all metadata as authorative
>> 
>> They do, although the xml encoding declaration is metadata too.

BZ> Note that none of this has to do with XML encoding declarations or
BZ> "charset" parameter of the Content-Type header, and it's unfortunate
BZ> that the two issues ended up getting intermixed this way...

I agree that they should be kept separate. i was trying to focus on the
latter, and should have changed the subject line.

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

From: chris at w3.org (Chris Lilley)
Date: Tue Jan  3 16:22:53 2006
Subject: SVG12: image/svg+xml gzip requirements
In-Reply-To: <[email-masked]>
References: <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]>
Message-ID: <[email-masked]>

On Friday, December 10, 2004, 5:15:01 AM, Boris wrote:

BZ> Chris Lilley wrote:
>> IH> I would strongly recommend that specs disallow sniffing of any kind,
>> IH> treating all metadata as authorative
>> 
>> They do, although the xml encoding declaration is metadata too.

BZ> Note that none of this has to do with XML encoding declarations or
BZ> "charset" parameter of the Content-Type header, and it's unfortunate
BZ> that the two issues ended up getting intermixed this way...

I agree that they should be kept separate. i was trying to focus on the
latter, and should have changed the subject line.

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

From: chris at w3.org (Chris Lilley)
Date: Sat Dec 11 00:25:30 2004
Subject: SVG12: image/svg+xml gzip requirements
In-Reply-To: <[email-masked]>
References: <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]>
Message-ID: <[email-masked]>

On Friday, December 10, 2004, 6:33:19 AM, Bjoern wrote:

BH> * Chris Lilley wrote:
>>BH> Use of the +xml convention implies that such metadata needs to be
>>BH> overridden
>>
>>No, it does not. An xml encoding declaration is sender provided
>>metadata. However, in the case where a charset parameter is allowed, and
>>where it can be different, and thus where one has to win over the other,
>>metadata is indeed being overridden. I agree with you that silent
>>recovery here is not inthe user interest and a warning should be shown.

BH> You either missed that the mail you responded to did not discuss the
BH> charset parameter at all, or you are trying to suggest that there is
BH> a character encoding that is based on gzip.

Neither, but you missed that I was deleting the bits about gzip and
responding only to character encoding, not content transfer encoding. I
should have signalled that with a change to the subject line.

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

From: chris at w3.org (Chris Lilley)
Date: Tue Jan  3 16:22:53 2006
Subject: SVG12: image/svg+xml gzip requirements
In-Reply-To: <[email-masked]>
References: <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]>
Message-ID: <[email-masked]>

On Friday, December 10, 2004, 6:33:19 AM, Bjoern wrote:

BH> * Chris Lilley wrote:
>>BH> Use of the +xml convention implies that such metadata needs to be
>>BH> overridden
>>
>>No, it does not. An xml encoding declaration is sender provided
>>metadata. However, in the case where a charset parameter is allowed, and
>>where it can be different, and thus where one has to win over the other,
>>metadata is indeed being overridden. I agree with you that silent
>>recovery here is not inthe user interest and a warning should be shown.

BH> You either missed that the mail you responded to did not discuss the
BH> charset parameter at all, or you are trying to suggest that there is
BH> a character encoding that is based on gzip.

Neither, but you missed that I was deleting the bits about gzip and
responding only to character encoding, not content transfer encoding. I
should have signalled that with a change to the subject line.

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

From: tonym at essentialsecurity.com (Tony Mohr)
Date: Tue Jan  3 16:22:53 2006
Subject: Registration of MIME media type *.ECC
Message-ID: <[email-masked]>

To: [email-masked]
     Subject: Registration of MIME media type *.ECC
 
     MIME media type name: Application        
 
     MIME subtype name: .ECC
 
     Required parameters: none
 
     Optional parameters: none

          Encoding considerations: ESS files are binary data and thus should
be encoded for MIME mail transmission. 

The same guidelines that apply to application/octet-stream apply to this.

     Security considerations: none
 
     Interoperability considerations: none
 
     Published specification: The specifications for this content type are
proprietary. They are specified by Essential Security Software, Inc.
 
     Applications which use this media type: Essential Security Software
product, Essential Security Suite and Ecrypt-it. Contains encrypted
information.
 
     Additional information:
 
       Magic number(s): none   
       File extension(s): *.ECC
       Macintosh File Type Code(s): none
 
     Person & email address to contact for further information:
 
        Tony Mohr
        [email-masked]
        425.454.2632
 
     Intended usage: common
 
     (One of COMMON, LIMITED USE or OBSOLETE)

Best Regards,

Tony Mohr

Essential Security Software

Director - Business Development

Desk: 425-454-2632

Cell: 425-443-6713

Email: tonym@essentialsecurity,com
Web:  <blocked::blocked::BLOCKED::http://www.essentialsecurity.com>
www.essentialsecurity.com 

"Security Made Simple"

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.alvestrand.no/pipermail/ietf-types/attachments/20041210/bda828ae/attachment.html
>From [email-masked]  Fri Dec 10 09:51:51 2004
From: tonym at essentialsecurity.com (Tony Mohr)
Date: Tue Jan  3 16:22:54 2006
Subject: Registration of MIME media type .pss
Message-ID: <[email-masked]>

To: [email-masked]
     Subject: Registration of MIME media type *.pss
 
     MIME media type name: Application        
 
     MIME subtype name: .pss
 
     Required parameters: none
 
     Optional parameters: none

          Encoding considerations: ESS files are binary data and thus should
be encoded for MIME mail transmission. 

The same guidelines that apply to application/octet-stream apply to this.

     Security considerations: none
 
     Interoperability considerations: none
 
     Published specification: The specifications for this content type are
proprietary. They are specified by Essential Security Software, Inc.
 
     Applications which use this media type: Essential Security Software
product, Essential Security Suite and Ecrypt-it. Contains encrypted
information.
 
     Additional information:
 
       Magic number(s): none   
       File extension(s): *.pss
       Macintosh File Type Code(s): none
 
     Person & email address to contact for further information:
 
        Tony Mohr
        [email-masked]
        425.454.2632
 
     Intended usage: common
 
     (One of COMMON, LIMITED USE or OBSOLETE)

 

Best Regards,

Tony Mohr

Essential Security Software

Director - Business Development

Desk: 425-454-2632

Cell: 425-443-6713

Email: tonym@essentialsecurity,com
Web:  <blocked::blocked::BLOCKED::http://www.essentialsecurity.com>
www.essentialsecurity.com 

"Security Made Simple"

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.alvestrand.no/pipermail/ietf-types/attachments/20041210/57142a68/attachment.html
>From [email-masked]  Thu Dec 16 13:23:44 2004
From: hisham.khartabil at telio.no (Hisham Khartabil)
Date: Tue Jan  3 16:22:54 2006
Subject: Media Type review request for "application/resource-lists+xml" and
	"application/rls-services+xml"
Message-ID: <[email-masked]>

The SIMPLE Working Group requests a Media Type review for the following  
2 new types:

- application/resource-lists+xml
- application/rls-services+xml

These are intended for the IETF tree, and specified in section 8.2 of  
http://www.ietf.org/internet-drafts/draft-ietf-simple-xcap-list-usage 
-04.txt

Thanks,
Hisham Khartabil
SIMPLE WG Co-chair

From: derhoermi at gmx.net (Bjoern Hoehrmann)
Date: Tue Jan  3 16:22:53 2006
Subject: SVG12: image/svg+xml gzip requirements
In-Reply-To: <[email-masked]>
References: <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]>
Message-ID: <[email-masked]>

* Chris Lilley wrote:
>BH> Use of the +xml convention implies that such metadata needs to be
>BH> overridden
>
>No, it does not. An xml encoding declaration is sender provided
>metadata. However, in the case where a charset parameter is allowed, and
>where it can be different, and thus where one has to win over the other,
>metadata is indeed being overridden. I agree with you that silent
>recovery here is not inthe user interest and a warning should be shown.

You either missed that the mail you responded to did not discuss the
charset parameter at all, or you are trying to suggest that there is
a character encoding that is based on gzip. Such a character encoing
would of course by easy to construct,

  In order to encode a XML document using the gzip-xml character
  encoding, the XML document is first serialized using a second
  character encoding such that the resulting octet sequence meets
  the requirements of the XML 1.0 Recommendation. The new octet
  sequence is then compressed using the gzip method as defined in
  RFC 1952.

  In order to decode a gzip-xml encoded XML document, the octet
  stream that represents the XML document is first uncompressed
  using the method defined in RFC 1952. The decoder determines
  then the character encoding of the resulting octet sequence as
  defined in the XML 1.0 Recommendation and decodes the sequence
  according to this character encoding with the exception that
  the resulting character sequence must be constructed such that
  XML processors that would processes the character sequence
  would only read EncName nonterminals that match "gzip-xml" in
  order to circumvent the the requirment in the XML 1.0 Rec that
    
    ... it is a fatal error for an entity including an encoding
    declaration to be presented to the XML processor in an
    encoding other than that named in the declaration ...

  Implementations may implement other algorithms than those
  described above as long as those alternate algorithms yield
  in the same processing result.

If you imply this gzip-xml character encoding then there is indeed
no metadata that is overriden (unless there happend to be higher-
level protocol information that would require XML processors to
determine a character encoding that is different from "gzip-xml").
If that is your point, I should probably request that support for
this gzip-xml character encoding is required for SVG Viewers...
-- 
Bj?rn H?hrmann ? mailto:[email-masked] ? http://bjoern.hoehrmann.de
Weinh. Str. 22 ? Telefon: +49(0)621/4309674 ? http://www.bjoernsworld.de
68309 Mannheim ? PGP Pub. KeyID: 0xA4357E78 ? http://www.websitedev.de/ 

From: bzbarsky at MIT.EDU (Boris Zbarsky)
Date: Fri Dec 10 09:42:06 2004
Subject: SVG12: image/svg+xml gzip requirements
In-Reply-To: <[email-masked]>
References: <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]>
Message-ID: <[email-masked]>

Chris Lilley wrote:
> IH> I would strongly recommend that specs disallow sniffing of any kind,
> IH> treating all metadata as authorative
> 
> They do, although the xml encoding declaration is metadata too.

I'm sorry, but that's not what was being claimed about user-agents receiving 
content with a Cotent-Type of image/xml+svg, and Content-Encoding or 
Transfer-Encoding that happened to look like it was compressed (the argument was 
about gzip, but I'm not sure it was ever claimed that gzip compression is 
special in this regard, except insofar as support for it is required by the SVG 
specification).

The claim was that under these circumstances, the UA should disregard the 
server-provided encoding value ("identity", in the only way that it can be 
provided), should decompress the data based on its guess as to what type of 
compression was used, and should tell the user that it did so.

The futher claim was that this is consistent with all existing specifications 
and best practices and was a desirable behavior.

These claims hinged on the claim that the magic numbers at the beginning of 
common compressed formats are actually metadata.  Per this argument, of course, 
it's not clear why we have Content-Encoding and Transfer-Encoding headers at 
all, but such was the argument.

Note that none of this has to do with XML encoding declarations or "charset" 
parameter of the Content-Type header, and it's unfortunate that the two issues 
ended up getting intermixed this way...

-Boris
>From [email-masked]  Fri Dec 10 04:59:16 2004
From: chris at w3.org (Chris Lilley)
Date: Fri Dec 10 09:42:16 2004
Subject: SVG12: image/svg+xml gzip requirements
In-Reply-To: <[email-masked]>
References: <[email-masked]>
	<[email-masked]>
	<[email-masked]>
	<[email-masked]>
	<[email-masked]>
	<[email-masked]>
	<[email-masked]>
	<[email-masked]>
	<[email-masked]>
Message-ID: <[email-masked]>

On Wednesday, December 8, 2004, 10:39:53 PM, Bjoern wrote:

BH> * Thomas DeWeese wrote:
>>>>   Huh?  If the network layer detects that the HTTP response
>>>>is in fact GZip encoded even though the header isn't set and decodes
>>>>it why is this a problem?
>>> 
>>> Because such software does not interoperate with software that does not
>>> perform such error correction. 
>>
>>    Well, you are free to your option but don't reference a TAG finding
>>saying it doesn't support this behavior when it clearly does!

BH> <http://www.w3.org/2001/tag/doc/mime-respect.html>:

BH> [...]
BH>   Format specifications SHOULD NOT work against the Web architecture
BH>   by requiring or suggesting that a recipient override sender-provided
BH>   metadata without user consent.
BH> [...]

And thus, a charset which conflicts with the instance, although
authoritative, is a source of problems. Which is why we say not to
provide one, unless its known to not conflict, and even then, no really
good reason to.

BH> Use of the +xml convention implies that such metadata needs to be
BH> overridden

No, it does not. An xml encoding declaration is sender provided
metadata. However, in the case where a charset parameter is allowed, and
where it can be different, and thus where one has to win over the other,
metadata is indeed being overridden. I agree with you that silent
recovery here is not inthe user interest and a warning should be shown.

BH> (e.g. by implying further metadata) in order to process the
BH> content any further than the first character. You will find further
BH> information in the TAG finding that supports my claim, for example, the
BH> HTML sniffing in section 2.1 is not much different from gzip compression
BH> sniffing. You will also find that the AWWW document goes even further
BH> and constraints "Agents MUST NOT ignore message metadata without the
BH> consent of the user" and includes the principle "Agents that recover
BH> from error by making a choice without the user's consent are not acting
BH> on the user's behalf". The proposed registration does not discuss user
BH> consent in any way and is thus inconsistent with the requirement in the
BH> TAG finding, and actually with the "Architecture of the World Wide Web",
BH> too.

Actually, its specicially written to be very consistent with it, by not
allowing a source of conflict and thus never getting into the situation
where conflicting metadata needs to be handled. So, the user does not
need to assent to anything. Simple, really.

BH> If the registration is changed to require user consent to this operation
BH> it might be more consistent with these TAG findings;

No, it would just conflict with the parts you already quoted and with
other parts you didn't.

BH>  I would not accept
BH> such a resolution though.

Great.

BH> I very much disagree that the TAG supports
BH> silent error recovery.

It doesn't.

BH>  If you think my interpretation of these TAG
BH> publications is not what the TAG really intended,

That would be a 'yes'

BH> please request that
BH> the TAG clarifies their materials so we can discuss this on more solid
BH> grounds.

The materials are clear, but you seem determined to go for the less
interoperable path and to bend the TAG materials through 180 degrees,
for reasons that I find hard to understand.

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

From: bzbarsky at MIT.EDU (Boris Zbarsky)
Date: Tue Jan  3 16:22:53 2006
Subject: SVG12: image/svg+xml gzip requirements
In-Reply-To: <[email-masked]>
References: <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]>
Message-ID: <[email-masked]>

Chris Lilley wrote:
> IH> I would strongly recommend that specs disallow sniffing of any kind,
> IH> treating all metadata as authorative
> 
> They do, although the xml encoding declaration is metadata too.

I'm sorry, but that's not what was being claimed about user-agents receiving 
content with a Cotent-Type of image/xml+svg, and Content-Encoding or 
Transfer-Encoding that happened to look like it was compressed (the argument was 
about gzip, but I'm not sure it was ever claimed that gzip compression is 
special in this regard, except insofar as support for it is required by the SVG 
specification).

The claim was that under these circumstances, the UA should disregard the 
server-provided encoding value ("identity", in the only way that it can be 
provided), should decompress the data based on its guess as to what type of 
compression was used, and should tell the user that it did so.

The futher claim was that this is consistent with all existing specifications 
and best practices and was a desirable behavior.

These claims hinged on the claim that the magic numbers at the beginning of 
common compressed formats are actually metadata.  Per this argument, of course, 
it's not clear why we have Content-Encoding and Transfer-Encoding headers at 
all, but such was the argument.

Note that none of this has to do with XML encoding declarations or "charset" 
parameter of the Content-Type header, and it's unfortunate that the two issues 
ended up getting intermixed this way...

-Boris

From: chris at w3.org (Chris Lilley)
Date: Tue Jan  3 16:22:53 2006
Subject: SVG12: image/svg+xml gzip requirements
In-Reply-To: <[email-masked]>
References: <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]>
Message-ID: <[email-masked]>

On Wednesday, December 8, 2004, 10:39:53 PM, Bjoern wrote:

BH> * Thomas DeWeese wrote:
>>>>   Huh?  If the network layer detects that the HTTP response
>>>>is in fact GZip encoded even though the header isn't set and decodes
>>>>it why is this a problem?
>>> 
>>> Because such software does not interoperate with software that does not
>>> perform such error correction. 
>>
>>    Well, you are free to your option but don't reference a TAG finding
>>saying it doesn't support this behavior when it clearly does!

BH> <http://www.w3.org/2001/tag/doc/mime-respect.html>:

BH> [...]
BH>   Format specifications SHOULD NOT work against the Web architecture
BH>   by requiring or suggesting that a recipient override sender-provided
BH>   metadata without user consent.
BH> [...]

And thus, a charset which conflicts with the instance, although
authoritative, is a source of problems. Which is why we say not to
provide one, unless its known to not conflict, and even then, no really
good reason to.

BH> Use of the +xml convention implies that such metadata needs to be
BH> overridden

No, it does not. An xml encoding declaration is sender provided
metadata. However, in the case where a charset parameter is allowed, and
where it can be different, and thus where one has to win over the other,
metadata is indeed being overridden. I agree with you that silent
recovery here is not inthe user interest and a warning should be shown.

BH> (e.g. by implying further metadata) in order to process the
BH> content any further than the first character. You will find further
BH> information in the TAG finding that supports my claim, for example, the
BH> HTML sniffing in section 2.1 is not much different from gzip compression
BH> sniffing. You will also find that the AWWW document goes even further
BH> and constraints "Agents MUST NOT ignore message metadata without the
BH> consent of the user" and includes the principle "Agents that recover
BH> from error by making a choice without the user's consent are not acting
BH> on the user's behalf". The proposed registration does not discuss user
BH> consent in any way and is thus inconsistent with the requirement in the
BH> TAG finding, and actually with the "Architecture of the World Wide Web",
BH> too.

Actually, its specicially written to be very consistent with it, by not
allowing a source of conflict and thus never getting into the situation
where conflicting metadata needs to be handled. So, the user does not
need to assent to anything. Simple, really.

BH> If the registration is changed to require user consent to this operation
BH> it might be more consistent with these TAG findings;

No, it would just conflict with the parts you already quoted and with
other parts you didn't.

BH>  I would not accept
BH> such a resolution though.

Great.

BH> I very much disagree that the TAG supports
BH> silent error recovery.

It doesn't.

BH>  If you think my interpretation of these TAG
BH> publications is not what the TAG really intended,

That would be a 'yes'

BH> please request that
BH> the TAG clarifies their materials so we can discuss this on more solid
BH> grounds.

The materials are clear, but you seem determined to go for the less
interoperable path and to bend the TAG materials through 180 degrees,
for reasons that I find hard to understand.

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

From: chris at w3.org (Chris Lilley)
Date: Tue Jan  3 16:22:53 2006
Subject: SVG12: image/svg+xml gzip requirements
In-Reply-To: <[email-masked]>
References: <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]>
Message-ID: <[email-masked]>

On Wednesday, December 8, 2004, 9:56:10 PM, Ian wrote:

IH> Indeed; the logical conclusion of the "correct it in the network layer"
IH> thinking is how you get to the world where IE will treat anything that
IH> happens to contain the string "<html>" as an HTML document, even if it is
IH> sent as text/plain.

But only if its in the first 256 bytes, so be carefull with those long
comments before the root element.

It also led to anything with Content transfer encoding being saved to
disk! which is why some SVG content was served without that, as an IE
workaround. It seems to be becoming less common. And of course, Firefox
and Opera and Safari don't have those sort of problems. Its something of
a FAQ.

IH> That kind of "magic error fixing" has security 
IH> implications (hence why XPSP2 reduced the amount of sniffing in IE).

IH> I would strongly recommend that specs disallow sniffing of any kind,
IH> treating all metadata as authorative

They do, although the xml encoding declaration is metadata too.

IH> (and giving explicit priorities to handle metadata contradictions).
IH> In certain rare cases where sniffing is required due to missing
IH> metadata (as in the lack of byte order information when no
IH> authorative default is stated), then the sniffing performed should
IH> be well defined in order to allow all UAs to have exact
IH> interoperability.

Yes. And reading an explicit xml encoding declaration, or choosing
between UTF-8, UTF-8 (with BOM) and UTF-16 (with BOM) is well defined in
the XML specification.

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

From: chris at w3.org (Chris Lilley)
Date: Fri Dec 10 09:42:01 2004
Subject: SVG12: image/svg+xml gzip requirements
In-Reply-To: <[email-masked]>
References: <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]>
Message-ID: <[email-masked]>

On Wednesday, December 8, 2004, 7:18:50 PM, Thomas wrote:

TD>     Saying there can/should not be a charset parameter for
TD> image/svg+xml or if there is one it _must_ match the XML document's
TD> encoding is not the same as defining inconsistent processing rules, it
TD> is supporting the TAG finding.

Yes. Which is why its defined that way in the MIME registration.

TD>     What I don't get is why you think image/svg+xml can not possibly
TD> have anything different about it from text/xml.

Actually all text/* have sugfficient problems (mandatory fallback to
text/plain, suitability to be presented raw to the user as plain text,
mandatory fallback to us-ascii unless there is a charset parameter, een
for xml content with an encoding declaration) that text/*+xml is being
deprecated in RFC3023bis.

So we are left with image, application (heck, video, audio, model) /*+xml

TD>     I think that as long as someone _following_ the image/svg+xml
TD> mime-type registration does not break existing XML processors there
TD> is no legacy problem.

As shown by the past several years experience.

Relying on the xml encoding declaration allows content generation tools
to reliably state the character encoding used and to communicate this
reliably to the eventual parser without any special knowledge of a
particular server setup.

TD>  This would allow the registration to explicitly
TD> disallow charset and not break anything or require that it _always_
TD> match with undefined behavior if it doesn't.  If it specified the
TD> charset parameter was ignored that would be problematic.

Right, which is why it doesn't do that.

TD>     Does anyone think it really was a good idea to allow for a
TD> charset that differs from the content?

No, it was a really bad idea that snuck in with an attempt to make
text/*+xml work. It didn't work, and is being deprecated.

TD>  Or are we just propagating a
TD> bad decision on future generations?

Hopefully not.

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

From: chris at w3.org (Chris Lilley)
Date: Tue Jan  3 16:22:53 2006
Subject: SVG12: image/svg+xml gzip requirements
In-Reply-To: <[email-masked]>
References: <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]>
Message-ID: <[email-masked]>

On Wednesday, December 8, 2004, 7:18:50 PM, Thomas wrote:

TD>     Saying there can/should not be a charset parameter for
TD> image/svg+xml or if there is one it _must_ match the XML document's
TD> encoding is not the same as defining inconsistent processing rules, it
TD> is supporting the TAG finding.

Yes. Which is why its defined that way in the MIME registration.

TD>     What I don't get is why you think image/svg+xml can not possibly
TD> have anything different about it from text/xml.

Actually all text/* have sugfficient problems (mandatory fallback to
text/plain, suitability to be presented raw to the user as plain text,
mandatory fallback to us-ascii unless there is a charset parameter, een
for xml content with an encoding declaration) that text/*+xml is being
deprecated in RFC3023bis.

So we are left with image, application (heck, video, audio, model) /*+xml

TD>     I think that as long as someone _following_ the image/svg+xml
TD> mime-type registration does not break existing XML processors there
TD> is no legacy problem.

As shown by the past several years experience.

Relying on the xml encoding declaration allows content generation tools
to reliably state the character encoding used and to communicate this
reliably to the eventual parser without any special knowledge of a
particular server setup.

TD>  This would allow the registration to explicitly
TD> disallow charset and not break anything or require that it _always_
TD> match with undefined behavior if it doesn't.  If it specified the
TD> charset parameter was ignored that would be problematic.

Right, which is why it doesn't do that.

TD>     Does anyone think it really was a good idea to allow for a
TD> charset that differs from the content?

No, it was a really bad idea that snuck in with an attempt to make
text/*+xml work. It didn't work, and is being deprecated.

TD>  Or are we just propagating a
TD> bad decision on future generations?

Hopefully not.

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

From: chris at w3.org (Chris Lilley)
Date: Fri Dec 10 09:42:03 2004
Subject: SVG12: image/svg+xml gzip requirements
In-Reply-To: <[email-masked]>
References: <[email-masked]> <[email-masked]> <[email-masked]>
Message-ID: <[email-masked]>

On Wednesday, December 8, 2004, 6:38:43 PM, Bjoern wrote:

>>   I might also point out 4.2 where the last paragraph says:
>>
>>     Representation providers SHOULD NOT in general specify the
>>     character encoding for XML data in protocol headers since the data
>>     is self-describing.
>>
>>   Which would seem to support not including the character encoding
>>in the SVG mime type.

Yes, exactly.

BH> It does not.

It does, too! :) You know, I was i a TAG meeting last week and checked
with the other folks exactly what it says and what the intent is and, I
have to say, it does, too.

BH> It says you should not use the charset parameter,

Right. It says don't use it. I have spent some considerable time
discussing with Martin D?rst at the end of last week, and we identified
a couple of cases (dumb transcoders that don't know any XML, and JSP
generators) where its easier to generate a charset to fix up problems
than it is to generate a correct xml encoding declaration. In all the
resst of the cases, havin ga correct encoding declaration is far
preferable.

It then becomes a discussion of what is easier to fix

a) improve the dumb transcoders (for example, if they don't know any XML
then treat all +xml types as binary) and the dumb JSP, or
b) make every implementation have to deal with a charset parameter that
should not be used.

BH> it
BH> does not say XML MIME Type registrations should define inconsistent
BH> processing rules for XML resources that use the charset parameter.

No, it says that if present the charset parameter should give the same
information as the xml encoding declaration. In other words, it
recommends the well implemented, consistent and interoperable path
(nontext/*+xml with no charset parameter and a correct encoding
declaration ) rather than the vague and inconsistently implemented path
(mutually inconsistent metadata with priority rules, and a requirement
to rewrite instances when saving to disk or to upgrade all disk
operating systems to store per-file MIME metadata).

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

From: chris at w3.org (Chris Lilley)
Date: Tue Jan  3 16:22:53 2006
Subject: SVG12: image/svg+xml gzip requirements
In-Reply-To: <[email-masked]>
References: <[email-masked]> <[email-masked]> <[email-masked]>
Message-ID: <[email-masked]>

On Wednesday, December 8, 2004, 6:38:43 PM, Bjoern wrote:

>>   I might also point out 4.2 where the last paragraph says:
>>
>>     Representation providers SHOULD NOT in general specify the
>>     character encoding for XML data in protocol headers since the data
>>     is self-describing.
>>
>>   Which would seem to support not including the character encoding
>>in the SVG mime type.

Yes, exactly.

BH> It does not.

It does, too! :) You know, I was i a TAG meeting last week and checked
with the other folks exactly what it says and what the intent is and, I
have to say, it does, too.

BH> It says you should not use the charset parameter,

Right. It says don't use it. I have spent some considerable time
discussing with Martin D?rst at the end of last week, and we identified
a couple of cases (dumb transcoders that don't know any XML, and JSP
generators) where its easier to generate a charset to fix up problems
than it is to generate a correct xml encoding declaration. In all the
resst of the cases, havin ga correct encoding declaration is far
preferable.

It then becomes a discussion of what is easier to fix

a) improve the dumb transcoders (for example, if they don't know any XML
then treat all +xml types as binary) and the dumb JSP, or
b) make every implementation have to deal with a charset parameter that
should not be used.

BH> it
BH> does not say XML MIME Type registrations should define inconsistent
BH> processing rules for XML resources that use the charset parameter.

No, it says that if present the charset parameter should give the same
information as the xml encoding declaration. In other words, it
recommends the well implemented, consistent and interoperable path
(nontext/*+xml with no charset parameter and a correct encoding
declaration ) rather than the vague and inconsistently implemented path
(mutually inconsistent metadata with priority rules, and a requirement
to rewrite instances when saving to disk or to upgrade all disk
operating systems to store per-file MIME metadata).

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

From: Thomas.DeWeese at Kodak.com (Thomas DeWeese)
Date: Tue Jan  3 16:22:53 2006
Subject: SVG12: image/svg+xml gzip requirements
In-Reply-To: <[email-masked]>
References: <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]>
Message-ID: <[email-masked]>

Bjoern Hoehrmann wrote:

> If the registration is changed to require user consent to this operation
> it might be more consistent with these TAG findings; I would not accept
> such a resolution though. I very much disagree that the TAG supports
> silent error recovery.

    No this pretty much sums it up, the TAG supports this action with
user notification, and you don't.  I would certainly support a
clarification of the required UA behavior in the face of conflicting
metadata in the case of gzip encoded content.

> If you think my interpretation of these TAG
>  publications is not what the TAG really intended, please request that
> the TAG clarifies their materials so we can discuss this on more solid
> grounds.

    No, I think we have a common understanding. I just didn't like the
fact that you held this up as saying this wasn't allowed when it does
allow it, with user notification.

From: derhoermi at gmx.net (Bjoern Hoehrmann)
Date: Tue Jan  3 16:22:53 2006
Subject: SVG12: image/svg+xml gzip requirements
In-Reply-To: <[email-masked]>
References: <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]>
Message-ID: <[email-masked]>

* Thomas DeWeese wrote:
>>>   Huh?  If the network layer detects that the HTTP response
>>>is in fact GZip encoded even though the header isn't set and decodes
>>>it why is this a problem?
>> 
>> Because such software does not interoperate with software that does not
>> perform such error correction. 
>
>    Well, you are free to your option but don't reference a TAG finding
>saying it doesn't support this behavior when it clearly does!

<http://www.w3.org/2001/tag/doc/mime-respect.html>:

[...]
  Format specifications SHOULD NOT work against the Web architecture
  by requiring or suggesting that a recipient override sender-provided
  metadata without user consent.
[...]

Use of the +xml convention implies that such metadata needs to be
overridden (e.g. by implying further metadata) in order to process the
content any further than the first character. You will find further
information in the TAG finding that supports my claim, for example, the
HTML sniffing in section 2.1 is not much different from gzip compression
sniffing. You will also find that the AWWW document goes even further
and constraints "Agents MUST NOT ignore message metadata without the
consent of the user" and includes the principle "Agents that recover
from error by making a choice without the user's consent are not acting
on the user's behalf". The proposed registration does not discuss user
consent in any way and is thus inconsistent with the requirement in the
TAG finding, and actually with the "Architecture of the World Wide Web",
too.

If the registration is changed to require user consent to this operation
it might be more consistent with these TAG findings; I would not accept
such a resolution though. I very much disagree that the TAG supports
silent error recovery. If you think my interpretation of these TAG
publications is not what the TAG really intended, please request that
the TAG clarifies their materials so we can discuss this on more solid
grounds.
-- 
Bj?rn H?hrmann ? mailto:[email-masked] ? http://bjoern.hoehrmann.de
Weinh. Str. 22 ? Telefon: +49(0)621/4309674 ? http://www.bjoernsworld.de
68309 Mannheim ? PGP Pub. KeyID: 0xA4357E78 ? http://www.websitedev.de/ 

From: Thomas.DeWeese at Kodak.com (Thomas DeWeese)
Date: Thu Jan 20 19:32:47 2005
Subject: SVG12: image/svg+xml gzip requirements
In-Reply-To: <[email-masked]>
References: <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]>
Message-ID: <[email-masked]>

Ian Hickson wrote:

> I would strongly recommend that specs disallow sniffing of any kind, 
> treating all metadata as authorative (and giving explicit priorities to 
> handle metadata contradictions).

    I guess the issue is what do you consider metadata?  I consider the
fact that a file starts with the magic number for a gzip stream a
very reliable piece of metadata (much more reliable than HTTP
headers - oh and much more reliable than searching a document in
an unknown encoding for 'html').

    So, in my view you would have a metadata contradiction.

> In certain rare cases where sniffing is 
> required due to missing metadata (as in the lack of byte order information 
> when no authorative default is stated), then the sniffing performed should 
> be well defined in order to allow all UAs to have exact interoperability.

    I would actually be _very_ happy to see the SVG spec define how
this should be done, and in fact I think the portion of the spec
originally quoted was doing this.  The problem is that for some
bizzare reason people don't seem to want to consider the file it's
self a good source of metadata about what the file contains.

    For freeform text files I can understand this but gzip is a binary
format it's structure is very rigid and if it is not a gzip
stream you will find out quite quickly, not to mention it
even includes a CRC of the uncompressed data, it is essentially
beyond reason to consider a case where a gzip stream uncompresses
successfully and it is not in fact a gzip stream.

    Now if what you are left with is an SVG document or not is
a much tricker proposition.
>From [email-masked]  Wed Dec  8 22:51:32 2004
From: Thomas.DeWeese at Kodak.com (Thomas DeWeese)
Date: Thu Jan 20 19:32:50 2005
Subject: SVG12: image/svg+xml gzip requirements
In-Reply-To: <[email-masked]>
References: <[email-masked]>
	<[email-masked]>
	<[email-masked]>
	<[email-masked]>
	<[email-masked]>
	<[email-masked]>
	<[email-masked]>
	<[email-masked]>
	<[email-masked]>
Message-ID: <[email-masked]>

Bjoern Hoehrmann wrote:

> If the registration is changed to require user consent to this operation
> it might be more consistent with these TAG findings; I would not accept
> such a resolution though. I very much disagree that the TAG supports
> silent error recovery.

    No this pretty much sums it up, the TAG supports this action with
user notification, and you don't.  I would certainly support a
clarification of the required UA behavior in the face of conflicting
metadata in the case of gzip encoded content.

> If you think my interpretation of these TAG
>  publications is not what the TAG really intended, please request that
> the TAG clarifies their materials so we can discuss this on more solid
> grounds.

    No, I think we have a common understanding. I just didn't like the
fact that you held this up as saying this wasn't allowed when it does
allow it, with user notification.

From: Thomas.DeWeese at Kodak.com (Thomas DeWeese)
Date: Tue Jan  3 16:22:53 2006
Subject: SVG12: image/svg+xml gzip requirements
In-Reply-To: <[email-masked]>
References: <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]>
Message-ID: <[email-masked]>

Ian Hickson wrote:

> I would strongly recommend that specs disallow sniffing of any kind, 
> treating all metadata as authorative (and giving explicit priorities to 
> handle metadata contradictions).

    I guess the issue is what do you consider metadata?  I consider the
fact that a file starts with the magic number for a gzip stream a
very reliable piece of metadata (much more reliable than HTTP
headers - oh and much more reliable than searching a document in
an unknown encoding for 'html').

    So, in my view you would have a metadata contradiction.

> In certain rare cases where sniffing is 
> required due to missing metadata (as in the lack of byte order information 
> when no authorative default is stated), then the sniffing performed should 
> be well defined in order to allow all UAs to have exact interoperability.

    I would actually be _very_ happy to see the SVG spec define how
this should be done, and in fact I think the portion of the spec
originally quoted was doing this.  The problem is that for some
bizzare reason people don't seem to want to consider the file it's
self a good source of metadata about what the file contains.

    For freeform text files I can understand this but gzip is a binary
format it's structure is very rigid and if it is not a gzip
stream you will find out quite quickly, not to mention it
even includes a CRC of the uncompressed data, it is essentially
beyond reason to consider a case where a gzip stream uncompresses
successfully and it is not in fact a gzip stream.

    Now if what you are left with is an SVG document or not is
a much tricker proposition.

From: Thomas.DeWeese at Kodak.com (Thomas DeWeese)
Date: Thu Jan 20 19:32:44 2005
Subject: SVG12: image/svg+xml gzip requirements
In-Reply-To: <[email-masked]>
References: <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]>
Message-ID: <[email-masked]>

Bjoern Hoehrmann wrote:

> * Thomas DeWeese wrote:
> 
>>>The TAG finding has no impact whatsoever on SVG Viewer conformance
>>>requirements, I think the TAG will happily clarify this if you ask
>>>for it on www-tag. You would need to argue that this is allowed by
>>>the SVG Viewer conformance requirements. I think it is clear that
>>>this is not allowed by those conformance requirements.
>>
>>   Huh?  If the network layer detects that the HTTP response
>>is in fact GZip encoded even though the header isn't set and decodes
>>it why is this a problem?
> 
> Because such software does not interoperate with software that does not
> perform such error correction. 

    Well, you are free to your option but don't reference a TAG finding
saying it doesn't support this behavior when it clearly does!

From: Thomas.DeWeese at Kodak.com (Thomas DeWeese)
Date: Tue Jan  3 16:22:53 2006
Subject: SVG12: image/svg+xml gzip requirements
In-Reply-To: <[email-masked]>
References: <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]>
Message-ID: <[email-masked]>

Bjoern Hoehrmann wrote:

> * Thomas DeWeese wrote:
> 
>>>The TAG finding has no impact whatsoever on SVG Viewer conformance
>>>requirements, I think the TAG will happily clarify this if you ask
>>>for it on www-tag. You would need to argue that this is allowed by
>>>the SVG Viewer conformance requirements. I think it is clear that
>>>this is not allowed by those conformance requirements.
>>
>>   Huh?  If the network layer detects that the HTTP response
>>is in fact GZip encoded even though the header isn't set and decodes
>>it why is this a problem?
> 
> Because such software does not interoperate with software that does not
> perform such error correction. 

    Well, you are free to your option but don't reference a TAG finding
saying it doesn't support this behavior when it clearly does!

From: ian at hixie.ch (Ian Hickson)
Date: Thu Jan 20 19:32:55 2005
Subject: SVG12: image/svg+xml gzip requirements
In-Reply-To: <[email-masked]>
References: <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]>
Message-ID: <[email-masked]>

On Wed, 8 Dec 2004, Bjoern Hoehrmann wrote:
>>
>> Huh?  If the network layer detects that the HTTP response is in fact 
>> GZip encoded even though the header isn't set and decodes it why is 
>> this a problem?
> 
> Because such software does not interoperate with software that does not 
> perform such error correction. Would you also argue that for a ISO-8859- 
> 1 encoded document [...]
> I am not sure where you draw the line between errors this "network 
> layer" may correct.

Indeed; the logical conclusion of the "correct it in the network layer" 
thinking is how you get to the world where IE will treat anything that 
happens to contain the string "<html>" as an HTML document, even if it is 
sent as text/plain. That kind of "magic error fixing" has security 
implications (hence why XPSP2 reduced the amount of sniffing in IE).

I would strongly recommend that specs disallow sniffing of any kind, 
treating all metadata as authorative (and giving explicit priorities to 
handle metadata contradictions). In certain rare cases where sniffing is 
required due to missing metadata (as in the lack of byte order information 
when no authorative default is stated), then the sniffing performed should 
be well defined in order to allow all UAs to have exact interoperability.

IMHO.

-- 
Ian Hickson               U+1047E                )\._.,--....,'``.    fL
http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'
>From [email-masked]  Fri Dec 10 09:51:49 2004
From: tonym at essentialsecurity.com (Tony Mohr)
Date: Thu Jan 20 19:32:57 2005
Subject: Registration of MIME media type *.ECC
Message-ID: <[email-masked]>

To: [email-masked]
     Subject: Registration of MIME media type *.ECC
 
     MIME media type name: Application        
 
     MIME subtype name: .ECC
 
     Required parameters: none
 
     Optional parameters: none

          Encoding considerations: ESS files are binary data and thus should
be encoded for MIME mail transmission. 

The same guidelines that apply to application/octet-stream apply to this.

     Security considerations: none
 
     Interoperability considerations: none
 
     Published specification: The specifications for this content type are
proprietary. They are specified by Essential Security Software, Inc.
 
     Applications which use this media type: Essential Security Software
product, Essential Security Suite and Ecrypt-it. Contains encrypted
information.
 
     Additional information:
 
       Magic number(s): none   
       File extension(s): *.ECC
       Macintosh File Type Code(s): none
 
     Person & email address to contact for further information:
 
        Tony Mohr
        [email-masked]
        425.454.2632
 
     Intended usage: common
 
     (One of COMMON, LIMITED USE or OBSOLETE)

Best Regards,

Tony Mohr

Essential Security Software

Director - Business Development

Desk: 425-454-2632

Cell: 425-443-6713

Email: tonym@essentialsecurity,com
Web:  <blocked::blocked::BLOCKED::http://www.essentialsecurity.com>
www.essentialsecurity.com 

"Security Made Simple"

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://eikenes.alvestrand.no/pipermail/ietf-types/attachments/20041210/bda828ae/attachment.htm
>From [email-masked]  Fri Dec 10 09:51:51 2004
From: tonym at essentialsecurity.com (Tony Mohr)
Date: Thu Jan 20 19:33:00 2005
Subject: Registration of MIME media type .pss
Message-ID: <[email-masked]>

To: [email-masked]
     Subject: Registration of MIME media type *.pss
 
     MIME media type name: Application        
 
     MIME subtype name: .pss
 
     Required parameters: none
 
     Optional parameters: none

          Encoding considerations: ESS files are binary data and thus should
be encoded for MIME mail transmission. 

The same guidelines that apply to application/octet-stream apply to this.

     Security considerations: none
 
     Interoperability considerations: none
 
     Published specification: The specifications for this content type are
proprietary. They are specified by Essential Security Software, Inc.
 
     Applications which use this media type: Essential Security Software
product, Essential Security Suite and Ecrypt-it. Contains encrypted
information.
 
     Additional information:
 
       Magic number(s): none   
       File extension(s): *.pss
       Macintosh File Type Code(s): none
 
     Person & email address to contact for further information:
 
        Tony Mohr
        [email-masked]
        425.454.2632
 
     Intended usage: common
 
     (One of COMMON, LIMITED USE or OBSOLETE)

 

Best Regards,

Tony Mohr

Essential Security Software

Director - Business Development

Desk: 425-454-2632

Cell: 425-443-6713

Email: tonym@essentialsecurity,com
Web:  <blocked::blocked::BLOCKED::http://www.essentialsecurity.com>
www.essentialsecurity.com 

"Security Made Simple"

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://eikenes.alvestrand.no/pipermail/ietf-types/attachments/20041210/57142a68/attachment.htm
>From [email-masked]  Thu Dec 16 13:23:44 2004
From: hisham.khartabil at telio.no (Hisham Khartabil)
Date: Thu Jan 20 19:33:03 2005
Subject: Media Type review request for "application/resource-lists+xml" and
	"application/rls-services+xml"
Message-ID: <[email-masked]>

The SIMPLE Working Group requests a Media Type review for the following  
2 new types:

- application/resource-lists+xml
- application/rls-services+xml

These are intended for the IETF tree, and specified in section 8.2 of  
http://www.ietf.org/internet-drafts/draft-ietf-simple-xcap-list-usage 
-04.txt

Thanks,
Hisham Khartabil
SIMPLE WG Co-chair

From: ian at hixie.ch (Ian Hickson)
Date: Tue Jan  3 16:22:53 2006
Subject: SVG12: image/svg+xml gzip requirements
In-Reply-To: <[email-masked]>
References: <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]>
Message-ID: <[email-masked]>

On Wed, 8 Dec 2004, Bjoern Hoehrmann wrote:
>>
>> Huh?  If the network layer detects that the HTTP response is in fact 
>> GZip encoded even though the header isn't set and decodes it why is 
>> this a problem?
> 
> Because such software does not interoperate with software that does not 
> perform such error correction. Would you also argue that for a ISO-8859- 
> 1 encoded document [...]
> I am not sure where you draw the line between errors this "network 
> layer" may correct.

Indeed; the logical conclusion of the "correct it in the network layer" 
thinking is how you get to the world where IE will treat anything that 
happens to contain the string "<html>" as an HTML document, even if it is 
sent as text/plain. That kind of "magic error fixing" has security 
implications (hence why XPSP2 reduced the amount of sniffing in IE).

I would strongly recommend that specs disallow sniffing of any kind, 
treating all metadata as authorative (and giving explicit priorities to 
handle metadata contradictions). In certain rare cases where sniffing is 
required due to missing metadata (as in the lack of byte order information 
when no authorative default is stated), then the sniffing performed should 
be well defined in order to allow all UAs to have exact interoperability.

IMHO.

-- 
Ian Hickson               U+1047E                )\._.,--....,'``.    fL
http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'

From: derhoermi at gmx.net (Bjoern Hoehrmann)
Date: Tue Jan  3 16:22:53 2006
Subject: SVG12: image/svg+xml gzip requirements
In-Reply-To: <[email-masked]>
References: <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]>
Message-ID: <[email-masked]>

* Thomas DeWeese wrote:
>> The TAG finding has no impact whatsoever on SVG Viewer conformance
>> requirements, I think the TAG will happily clarify this if you ask
>> for it on www-tag. You would need to argue that this is allowed by
>> the SVG Viewer conformance requirements. I think it is clear that
>> this is not allowed by those conformance requirements.
>
>    Huh?  If the network layer detects that the HTTP response
>is in fact GZip encoded even though the header isn't set and decodes
>it why is this a problem?

Because such software does not interoperate with software that does not
perform such error correction. Would you also argue that for a ISO-8859-
1 encoded document

  Content-Type: image/svg+xml

  <?xml version="1.0"?>
  ...
  <text>Bj?rn</text>
  ...

the "network layer" may detect that the resource is ISO-8859-1 encoded
and decodes it? The XML 1.0 Recommendation requires here, too, that the
processor aborts normal processing and reports a fatal error to the
application. I am not sure where you draw the line between errors this
"network layer" may correct.

>    I'll agree with this.  However you should then agree that there is
>no problem if the SVG mime-type registration states that there is _no_
>charset parameter for image/svg+xml, and merely suggests that if a
>processor encounters this non-existing parameter that it should be
>ignored.

The proposed registration implies "MUST ignore", changing that to SHOULD
ignore is even worse as it explicitly allows non-interoperable behavior.
-- 
Bj?rn H?hrmann ? mailto:[email-masked] ? http://bjoern.hoehrmann.de
Weinh. Str. 22 ? Telefon: +49(0)621/4309674 ? http://www.bjoernsworld.de
68309 Mannheim ? PGP Pub. KeyID: 0xA4357E78 ? http://www.websitedev.de/ 

From: Thomas.DeWeese at Kodak.com (Thomas DeWeese)
Date: Thu Jan 20 19:32:40 2005
Subject: SVG12: image/svg+xml gzip requirements
In-Reply-To: <[email-masked]>
References: <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]>
Message-ID: <[email-masked]>

Bjoern Hoehrmann wrote:

> * Thomas DeWeese wrote:

>>   But this is a case of inconsistent meta-data.  The sender says
>>that the data is not encoded, but the content indicates that it is
>>GZIP encoded.  Thus the user agent is allowed via the TAG to notice
>>this inconsistency and override the sender metadata (the UA at
>>this point should also notify the user of the override).  Once it
>>has overridden the sender data it can interpret the data stream as
>>GZIP compressed and get a valid XML Document.
> 
> The TAG finding has no impact whatsoever on SVG Viewer conformance
> requirements, I think the TAG will happily clarify this if you ask
> for it on www-tag. You would need to argue that this is allowed by
> the SVG Viewer conformance requirements. I think it is clear that
> this is not allowed by those conformance requirements.

    Huh?  If the network layer detects that the HTTP response
is in fact GZip encoded even though the header isn't set and decodes
it why is this a problem?

>>   Saying there can/should not be a charset parameter for
>>image/svg+xml or if there is one it _must_ match the XML document's
>>encoding is not the same as defining inconsistent processing rules, it
>>is supporting the TAG finding.
> 
> I agree that this is not the same thing, but I would like to point
> out that the proposed MIME Type registration does not discuss that
> such information must match, it rather requires implementations to
> ignore the charset parameter if provided which is inconsistent with
> the processing rules for all other XML MIME Types where it is re-
> quired that the charset parameter is honored.

    I'll agree with this.  However you should then agree that there is
no problem if the SVG mime-type registration states that there is _no_
charset parameter for image/svg+xml, and merely suggests that if a
processor encounters this non-existing parameter that it should be
ignored.

    This would keep existing XML processors conformant to the
mime-type registration (since such transfers violate the
mime-type registration[*] and anyway ignoring the 'non-existent'
parameter is merely a suggestion).  It would also give authors 
something to point to when convincing Admins that a charset should not
accompany the SVG content.

>>   As I have stated before if senders conform to the mime-type
>>registration no conflict can possibly occur, everyone processes the
>>content consistently.
> 
> This is false.

    Sorry, I was referring to my proposal here.

>>   Does anyone think it really was a good idea to allow for a
>>charset that differs from the content?  Or are we just propagating a
>>bad decision on future generations?
> 
> RFC 3023 revisions are best discussed on [email-masked].

   I'll take that as a no.

[*] It doesn't assume that the receiver has special knowledge of
image/svg+xml but it does "require" it of senders.

From: Thomas.DeWeese at Kodak.com (Thomas DeWeese)
Date: Tue Jan  3 16:22:53 2006
Subject: SVG12: image/svg+xml gzip requirements
In-Reply-To: <[email-masked]>
References: <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]>
Message-ID: <[email-masked]>

Bjoern Hoehrmann wrote:

> * Thomas DeWeese wrote:

>>   But this is a case of inconsistent meta-data.  The sender says
>>that the data is not encoded, but the content indicates that it is
>>GZIP encoded.  Thus the user agent is allowed via the TAG to notice
>>this inconsistency and override the sender metadata (the UA at
>>this point should also notify the user of the override).  Once it
>>has overridden the sender data it can interpret the data stream as
>>GZIP compressed and get a valid XML Document.
> 
> The TAG finding has no impact whatsoever on SVG Viewer conformance
> requirements, I think the TAG will happily clarify this if you ask
> for it on www-tag. You would need to argue that this is allowed by
> the SVG Viewer conformance requirements. I think it is clear that
> this is not allowed by those conformance requirements.

    Huh?  If the network layer detects that the HTTP response
is in fact GZip encoded even though the header isn't set and decodes
it why is this a problem?

>>   Saying there can/should not be a charset parameter for
>>image/svg+xml or if there is one it _must_ match the XML document's
>>encoding is not the same as defining inconsistent processing rules, it
>>is supporting the TAG finding.
> 
> I agree that this is not the same thing, but I would like to point
> out that the proposed MIME Type registration does not discuss that
> such information must match, it rather requires implementations to
> ignore the charset parameter if provided which is inconsistent with
> the processing rules for all other XML MIME Types where it is re-
> quired that the charset parameter is honored.

    I'll agree with this.  However you should then agree that there is
no problem if the SVG mime-type registration states that there is _no_
charset parameter for image/svg+xml, and merely suggests that if a
processor encounters this non-existing parameter that it should be
ignored.

    This would keep existing XML processors conformant to the
mime-type registration (since such transfers violate the
mime-type registration[*] and anyway ignoring the 'non-existent'
parameter is merely a suggestion).  It would also give authors 
something to point to when convincing Admins that a charset should not
accompany the SVG content.

>>   As I have stated before if senders conform to the mime-type
>>registration no conflict can possibly occur, everyone processes the
>>content consistently.
> 
> This is false.

    Sorry, I was referring to my proposal here.

>>   Does anyone think it really was a good idea to allow for a
>>charset that differs from the content?  Or are we just propagating a
>>bad decision on future generations?
> 
> RFC 3023 revisions are best discussed on [email-masked].

   I'll take that as a no.

[*] It doesn't assume that the receiver has special knowledge of
image/svg+xml but it does "require" it of senders.

From: derhoermi at gmx.net (Bjoern Hoehrmann)
Date: Tue Jan  3 16:22:53 2006
Subject: SVG12: image/svg+xml gzip requirements
In-Reply-To: <[email-masked]>
References: <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]>
Message-ID: <[email-masked]>

* Thomas DeWeese wrote:
>    But this is a case of inconsistent meta-data.  The sender says
>that the data is not encoded, but the content indicates that it is
>GZIP encoded.  Thus the user agent is allowed via the TAG to notice
>this inconsistency and override the sender metadata (the UA at
>this point should also notify the user of the override).  Once it
>has overridden the sender data it can interpret the data stream as
>GZIP compressed and get a valid XML Document.

The TAG finding has no impact whatsoever on SVG Viewer conformance
requirements, I think the TAG will happily clarify this if you ask
for it on www-tag. You would need to argue that this is allowed by
the SVG Viewer conformance requirements. I think it is clear that
this is not allowed by those conformance requirements.

>    Saying there can/should not be a charset parameter for
>image/svg+xml or if there is one it _must_ match the XML document's
>encoding is not the same as defining inconsistent processing rules, it
>is supporting the TAG finding.

I agree that this is not the same thing, but I would like to point
out that the proposed MIME Type registration does not discuss that
such information must match, it rather requires implementations to
ignore the charset parameter if provided which is inconsistent with
the processing rules for all other XML MIME Types where it is re-
quired that the charset parameter is honored.

>    As I have stated before if senders conform to the mime-type
>registration no conflict can possibly occur, everyone processes the
>content consistently.

This is false.

>    What I don't get is why you think image/svg+xml can not possibly
>have anything different about it from text/xml.  Does this mean that
>all the SVG UA's are in error because they process the document
>and display it as graphics?  After all that isn't what existing XML
>processors do they must be broken...

What an SVG Viewer might do in addition to XML processing is not of
concern here, but the XML processing is.

>    I think that as long as someone _following_ the image/svg+xml
>mime-type registration does not break existing XML processors there
>is no legacy problem.  This would allow the registration to explicitly
>disallow charset and not break anything or require that it _always_
>match with undefined behavior if it doesn't.  If it specified the
>charset parameter was ignored that would be problematic.

The proposed reqistration renders a broad range of applications non-
conforming, I've already mentioned the W3C Markup Validator, the W3C
CSS Validator, Microsoft's MSXML 4/5 XML toolkit, and Batik. I have
not seen a revised registration proposal so I can't comment on that.

>    Does anyone think it really was a good idea to allow for a
>charset that differs from the content?  Or are we just propagating a
>bad decision on future generations?

RFC 3023 revisions are best discussed on [email-masked].
-- 
Bj?rn H?hrmann ? mailto:[email-masked] ? http://bjoern.hoehrmann.de
Weinh. Str. 22 ? Telefon: +49(0)621/4309674 ? http://www.bjoernsworld.de
68309 Mannheim ? PGP Pub. KeyID: 0xA4357E78 ? http://www.websitedev.de/ 

From: Thomas.DeWeese at Kodak.com (Thomas DeWeese)
Date: Thu Jan 20 19:32:35 2005
Subject: SVG12: image/svg+xml gzip requirements
In-Reply-To: <[email-masked]>
References: <[email-masked]> <[email-masked]> <[email-masked]>
Message-ID: <[email-masked]>

Bjoern Hoehrmann wrote:

> * Thomas DeWeese wrote:
> 
>>  Please don't rewrite the TAG finding.  The TAG indicates that
>>User agents should 'notify' the user of the problem.  It does not say
>>that these documents must be rejected.
> 
> Appendix F.1 of the SVG 1.1 Recommendation requires that rendering must
> stop after a fatal error as defined in the XML 1.0 Recommendation has
> been encountered, which in case of the relevant documents means after
> reading the very first octet of the binary resource. The TAG finding,
> even if it disagrees with the SVG 1.1 Recommendation, has no authority
> to override this conformance requirement.

    But this is a case of inconsistent meta-data.  The sender says
that the data is not encoded, but the content indicates that it is
GZIP encoded.  Thus the user agent is allowed via the TAG to notice
this inconsistency and override the sender metadata (the UA at
this point should also notify the user of the override).  Once it
has overridden the sender data it can interpret the data stream as
GZIP compressed and get a valid XML Document.

    I don't see a reason why any UA that accepts XML content might
not follow this procedure, it is obviously more likely for SVG UA's
since they are required to support GZip compressed content.

>>  I might also point out 4.2 where the last paragraph says:
>>
>>    Representation providers SHOULD NOT in general specify the
>>    character encoding for XML data in protocol headers since the data
>>    is self-describing.
>>
>>  Which would seem to support not including the character encoding
>>in the SVG mime type.
> 
> It does not. It says you should not use the charset parameter, it
> does not say XML MIME Type registrations should define inconsistent
> processing rules for XML resources that use the charset parameter.

    Saying there can/should not be a charset parameter for
image/svg+xml or if there is one it _must_ match the XML document's
encoding is not the same as defining inconsistent processing rules, it
is supporting the TAG finding.

    As I have stated before if senders conform to the mime-type
registration no conflict can possibly occur, everyone processes the
content consistently.  If they don't follow the  mime-type 
registration than the transfer is invalid (and my suggestion
was to simply leave the results undefined).  After all the sender has
to "decide" to send "image/svg+xml" at the same time they should
"decide" not to send a charset (or ensure it matches).

    What I don't get is why you think image/svg+xml can not possibly
have anything different about it from text/xml.  Does this mean that
all the SVG UA's are in error because they process the document
and display it as graphics?  After all that isn't what existing XML
processors do they must be broken...

    I think that as long as someone _following_ the image/svg+xml
mime-type registration does not break existing XML processors there
is no legacy problem.  This would allow the registration to explicitly
disallow charset and not break anything or require that it _always_
match with undefined behavior if it doesn't.  If it specified the
charset parameter was ignored that would be problematic.

    Does anyone think it really was a good idea to allow for a
charset that differs from the content?  Or are we just propagating a
bad decision on future generations?

From: Thomas.DeWeese at Kodak.com (Thomas DeWeese)
Date: Tue Jan  3 16:22:53 2006
Subject: SVG12: image/svg+xml gzip requirements
In-Reply-To: <[email-masked]>
References: <[email-masked]> <[email-masked]> <[email-masked]>
Message-ID: <[email-masked]>

Bjoern Hoehrmann wrote:

> * Thomas DeWeese wrote:
> 
>>  Please don't rewrite the TAG finding.  The TAG indicates that
>>User agents should 'notify' the user of the problem.  It does not say
>>that these documents must be rejected.
> 
> Appendix F.1 of the SVG 1.1 Recommendation requires that rendering must
> stop after a fatal error as defined in the XML 1.0 Recommendation has
> been encountered, which in case of the relevant documents means after
> reading the very first octet of the binary resource. The TAG finding,
> even if it disagrees with the SVG 1.1 Recommendation, has no authority
> to override this conformance requirement.

    But this is a case of inconsistent meta-data.  The sender says
that the data is not encoded, but the content indicates that it is
GZIP encoded.  Thus the user agent is allowed via the TAG to notice
this inconsistency and override the sender metadata (the UA at
this point should also notify the user of the override).  Once it
has overridden the sender data it can interpret the data stream as
GZIP compressed and get a valid XML Document.

    I don't see a reason why any UA that accepts XML content might
not follow this procedure, it is obviously more likely for SVG UA's
since they are required to support GZip compressed content.

>>  I might also point out 4.2 where the last paragraph says:
>>
>>    Representation providers SHOULD NOT in general specify the
>>    character encoding for XML data in protocol headers since the data
>>    is self-describing.
>>
>>  Which would seem to support not including the character encoding
>>in the SVG mime type.
> 
> It does not. It says you should not use the charset parameter, it
> does not say XML MIME Type registrations should define inconsistent
> processing rules for XML resources that use the charset parameter.

    Saying there can/should not be a charset parameter for
image/svg+xml or if there is one it _must_ match the XML document's
encoding is not the same as defining inconsistent processing rules, it
is supporting the TAG finding.

    As I have stated before if senders conform to the mime-type
registration no conflict can possibly occur, everyone processes the
content consistently.  If they don't follow the  mime-type 
registration than the transfer is invalid (and my suggestion
was to simply leave the results undefined).  After all the sender has
to "decide" to send "image/svg+xml" at the same time they should
"decide" not to send a charset (or ensure it matches).

    What I don't get is why you think image/svg+xml can not possibly
have anything different about it from text/xml.  Does this mean that
all the SVG UA's are in error because they process the document
and display it as graphics?  After all that isn't what existing XML
processors do they must be broken...

    I think that as long as someone _following_ the image/svg+xml
mime-type registration does not break existing XML processors there
is no legacy problem.  This would allow the registration to explicitly
disallow charset and not break anything or require that it _always_
match with undefined behavior if it doesn't.  If it specified the
charset parameter was ignored that would be problematic.

    Does anyone think it really was a good idea to allow for a
charset that differs from the content?  Or are we just propagating a
bad decision on future generations?

From: derhoermi at gmx.net (Bjoern Hoehrmann)
Date: Tue Jan  3 16:22:53 2006
Subject: SVG12: image/svg+xml gzip requirements
In-Reply-To: <[email-masked]>
References: <[email-masked]> <[email-masked]>
Message-ID: <[email-masked]>

* Thomas DeWeese wrote:
>   Please don't rewrite the TAG finding.  The TAG indicates that
>User agents should 'notify' the user of the problem.  It does not say
>that these documents must be rejected.

Appendix F.1 of the SVG 1.1 Recommendation requires that rendering must
stop after a fatal error as defined in the XML 1.0 Recommendation has
been encountered, which in case of the relevant documents means after
reading the very first octet of the binary resource. The TAG finding,
even if it disagrees with the SVG 1.1 Recommendation, has no authority
to override this conformance requirement.

>   I might also point out 4.2 where the last paragraph says:
>
>     Representation providers SHOULD NOT in general specify the
>     character encoding for XML data in protocol headers since the data
>     is self-describing.
>
>   Which would seem to support not including the character encoding
>in the SVG mime type.

It does not. It says you should not use the charset parameter, it
does not say XML MIME Type registrations should define inconsistent
processing rules for XML resources that use the charset parameter.
-- 
Bj?rn H?hrmann ? mailto:[email-masked] ? http://bjoern.hoehrmann.de
Weinh. Str. 22 ? Telefon: +49(0)621/4309674 ? http://www.bjoernsworld.de
68309 Mannheim ? PGP Pub. KeyID: 0xA4357E78 ? http://www.websitedev.de/ 

From: Thomas.DeWeese at Kodak.com (Thomas DeWeese)
Date: Thu Jan 20 19:32:30 2005
Subject: SVG12: image/svg+xml gzip requirements
In-Reply-To: <[email-masked]>
References: <[email-masked]>
Message-ID: <[email-masked]>

Hi Bjoern,

   Please don't rewrite the TAG finding.  The TAG indicates that
User agents should 'notify' the user of the problem.  It does not say
that these documents must be rejected.  From
http://www.w3.org/2001/tag/doc/mime-respect.html#handling-inconsistency

     For example, a small "bug" icon in a graphical browser's user
     interface can indicate that the user agent has overridden sender
     metadata and can also act as a button through which a curious user
     might inspect the error or reverse the agent's choice.

   I might also point out 4.2 where the last paragraph says:

     Representation providers SHOULD NOT in general specify the
     character encoding for XML data in protocol headers since the data
     is self-describing.

   Which would seem to support not including the character encoding
in the SVG mime type.

----

Bjoern Hoehrmann wrote:

> Dear Scalable Vector Graphics Working Group,
> 
>   The current http://www.w3.org/TR/SVG12/mimereg.html notes:
> 
> [...]
>   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 RFC1952 section 2.3.1. 
> [...]
> 
> Unless the document is meant to introduce a new HTTP header, this is
> clearly false, RFC 2616 explicitly notes that Content-Transfer-Encoding
> is not used in HTTP/1.1, please change the text to refer to an actual
> HTTP header.
> 
> I am puzzled by the last sentence here, the text seems to suggest that
> implementations of the image/svg+xml MIME type are required to sniff for
> gzip compressed content so that much of the ill-formed SVG content
> 
>   http://lists.w3.org/Archives/Public/www-svg/2004Dec/0031.html
> 
> where content is compressed but the compression is not indicated through
> the relevant HTTP headers would actually be conforming. This is not
> accetable as it is inconsistent with the Authoritative Metadata TAG
> finding http://www.w3.org/2001/tag/doc/mime-respect.html and RFC 3023
> and 2616 which do not include such a requirement which means that such
> content would not work in general purpose XML processors which means
> that use of the +xml convention for image/svg+xml would not be
> appropriate.
> 
> Please change the text to clearly indicate that this is not allowed and
> that SVG Viewers are required to treat such content as ill-formed XML
> and thus reject it entirely.

From: Thomas.DeWeese at Kodak.com (Thomas DeWeese)
Date: Tue Jan  3 16:22:53 2006
Subject: SVG12: image/svg+xml gzip requirements
In-Reply-To: <[email-masked]>
References: <[email-masked]>
Message-ID: <[email-masked]>

Hi Bjoern,

   Please don't rewrite the TAG finding.  The TAG indicates that
User agents should 'notify' the user of the problem.  It does not say
that these documents must be rejected.  From
http://www.w3.org/2001/tag/doc/mime-respect.html#handling-inconsistency

     For example, a small "bug" icon in a graphical browser's user
     interface can indicate that the user agent has overridden sender
     metadata and can also act as a button through which a curious user
     might inspect the error or reverse the agent's choice.

   I might also point out 4.2 where the last paragraph says:

     Representation providers SHOULD NOT in general specify the
     character encoding for XML data in protocol headers since the data
     is self-describing.

   Which would seem to support not including the character encoding
in the SVG mime type.

----

Bjoern Hoehrmann wrote:

> Dear Scalable Vector Graphics Working Group,
> 
>   The current http://www.w3.org/TR/SVG12/mimereg.html notes:
> 
> [...]
>   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 RFC1952 section 2.3.1. 
> [...]
> 
> Unless the document is meant to introduce a new HTTP header, this is
> clearly false, RFC 2616 explicitly notes that Content-Transfer-Encoding
> is not used in HTTP/1.1, please change the text to refer to an actual
> HTTP header.
> 
> I am puzzled by the last sentence here, the text seems to suggest that
> implementations of the image/svg+xml MIME type are required to sniff for
> gzip compressed content so that much of the ill-formed SVG content
> 
>   http://lists.w3.org/Archives/Public/www-svg/2004Dec/0031.html
> 
> where content is compressed but the compression is not indicated through
> the relevant HTTP headers would actually be conforming. This is not
> accetable as it is inconsistent with the Authoritative Metadata TAG
> finding http://www.w3.org/2001/tag/doc/mime-respect.html and RFC 3023
> and 2616 which do not include such a requirement which means that such
> content would not work in general purpose XML processors which means
> that use of the +xml convention for image/svg+xml would not be
> appropriate.
> 
> Please change the text to clearly indicate that this is not allowed and
> that SVG Viewers are required to treat such content as ill-formed XML
> and thus reject it entirely.

From: derhoermi at gmx.net (Bjoern Hoehrmann)
Date: Tue Jan  3 16:22:52 2006
Subject: SVG12: image/svg+xml gzip requirements
Message-ID: <[email-masked]>

Dear Scalable Vector Graphics Working Group,

  The current http://www.w3.org/TR/SVG12/mimereg.html notes:

[...]
  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 RFC1952 section 2.3.1. 
[...]

Unless the document is meant to introduce a new HTTP header, this is
clearly false, RFC 2616 explicitly notes that Content-Transfer-Encoding
is not used in HTTP/1.1, please change the text to refer to an actual
HTTP header.

I am puzzled by the last sentence here, the text seems to suggest that
implementations of the image/svg+xml MIME type are required to sniff for
gzip compressed content so that much of the ill-formed SVG content

  http://lists.w3.org/Archives/Public/www-svg/2004Dec/0031.html

where content is compressed but the compression is not indicated through
the relevant HTTP headers would actually be conforming. This is not
accetable as it is inconsistent with the Authoritative Metadata TAG
finding http://www.w3.org/2001/tag/doc/mime-respect.html and RFC 3023
and 2616 which do not include such a requirement which means that such
content would not work in general purpose XML processors which means
that use of the +xml convention for image/svg+xml would not be
appropriate.

Please change the text to clearly indicate that this is not allowed and
that SVG Viewers are required to treat such content as ill-formed XML
and thus reject it entirely.

regards.
-- 
Bj?rn H?hrmann ? mailto:[email-masked] ? http://bjoern.hoehrmann.de
Weinh. Str. 22 ? Telefon: +49(0)621/4309674 ? http://www.bjoernsworld.de
68309 Mannheim ? PGP Pub. KeyID: 0xA4357E78 ? http://www.websitedev.de/ 

From: blilly at erols.com (Bruce Lilly)
Date: Tue Jan  3 16:22:52 2006
Subject: I-D ACTION:draft-lilly-text-troff-00.txt
In-Reply-To: <[email-masked]>
References: <[email-masked]> <[email-masked]>
Message-ID: <[email-masked]>

On Mon December 6 2004 23:09, Tony Hansen wrote:
> I have a serious problem with this parameter:
> 
>        process
>           Lists a recommended command pipeline for formatting.  The
>           parameter value may need to be quoted or encoded as provided
>           for by [RFC2045] as amended by [RFC2231] and [errata].
> 
> I'd hate to see someone actually implement a mechanism to automatically 
> execute the pipeline. I think this is just ASKING for someone to do so.

The draft registration text specifically addresses that issue
under Security considerations.  While I agree that *automatic*
execution of a pipeline should be avoided, I see no reason
why the suggested pipeline should not be presented to a user
for confirmation prior to execution (that would achieve the
same thing as manual rekeyboarding of the command
pipeline, but with less potential for typographical errors), if
the user initiated some action that would normally be
associated with execution.

> Now, the information provided in the pipeline IS useful; it provides the 
> list of the preprocessors that are needed to properly process the troff 
> souce. So instead, I'd recommend that there be a parameter that provides 
> just THAT information:
> 
>        preprocessors
> 	Lists the preprocessors that need to be invoked to properly
> 	process the troff input. The names of the preprocessors are
> 	comma separated. The parameter value may need to be quoted or
> 	encoded as provided for by [RFC2045] as amended by [RFC2231]
> 	and [errata].

But it isn't a mere "list of preprocessors"; it's an *ordered* list of
preprocessors, formatter, and postprocessors *with option flags*
and environment variable settings.  Invoking preprocessors in
the wrong order (e.g. running pic before grap) isn't useful, nor
is omitting option flags (e.g. macro packages).  And environment
variables can have a profound effect on operation (try the
latest version of groff's "nroff" w/o GROFF_NO_SGR to format
an I-D or RFC using ms macros NH or SH , for example). Finally,
a comma might well appear in the name of a preprocessor,
formatter, or postprocessor (nothing forbids that, as comma is
not a command interpreter (a.k.a. shell) metacharacter), so
that would require some additional escape or quoting mechanism.

Obfuscating a command pipeline by substituting commas for
vertical bars isn't going to prevent a wayward programmer
bent on automatic execution from making the reverse
translation.  Nor will it prevent careless users from doing the
same.

> In addition, there is one more MAJOR parameter that doesn't appear to be 
> specified anywhere: the macro package that was used in the troff 
> document, such as man, mm, ms, me, etc. So, I'd like to see this 
> optional parameter added:
> 
>       macro package
> 	Lists the macro package that needs to be used with the troff
> 	document. Examples of macro package names are man, mm, ms and
> 	me.

That's specified as an option flag to the formatter. It's also
theoretically possible to have multiple macro packages, though
major ones would almost certainly clash (however I have used
additional macros with -man to handle tables in man pages).
And one cannot have a parameter attribute name with an
embedded space character.

From: tony at att.com (Tony Hansen)
Date: Tue Jan  3 16:22:52 2006
Subject: I-D ACTION:draft-lilly-text-troff-00.txt
In-Reply-To: <[email-masked]>
References: <[email-masked]>
Message-ID: <[email-masked]>

I have a serious problem with this parameter:

       process
          Lists a recommended command pipeline for formatting.  The
          parameter value may need to be quoted or encoded as provided
          for by [RFC2045] as amended by [RFC2231] and [errata].

I'd hate to see someone actually implement a mechanism to automatically 
execute the pipeline. I think this is just ASKING for someone to do so.

Now, the information provided in the pipeline IS useful; it provides the 
list of the preprocessors that are needed to properly process the troff 
souce. So instead, I'd recommend that there be a parameter that provides 
just THAT information:

       preprocessors
	Lists the preprocessors that need to be invoked to properly
	process the troff input. The names of the preprocessors are
	comma separated. The parameter value may need to be quoted or
	encoded as provided for by [RFC2045] as amended by [RFC2231]
	and [errata].

In addition, there is one more MAJOR parameter that doesn't appear to be 
specified anywhere: the macro package that was used in the troff 
document, such as man, mm, ms, me, etc. So, I'd like to see this 
optional parameter added:

      macro package
	Lists the macro package that needs to be used with the troff
	document. Examples of macro package names are man, mm, ms and
	me.

	Tony Hansen
	[email-masked]

From: blilly at erols.com (Bruce Lilly)
Date: Mon Dec  6 22:55:29 2004
Subject: Testing the waters for text/troff
In-Reply-To: <[email-masked]>
References: <[email-masked]> <[email-masked]> <[email-masked]>
Message-ID: <[email-masked]>

On Mon December 6 2004 15:59, Simon Josefsson wrote:
> Bruce Lilly <[email-masked]> writes:
> 
> > ftp://ftp.isi.edu/in-notes/internet-drafts/draft-lilly-text-troff-00.txt
> 
> One comment on the "versions" parameter. If it is only meant to be
> humanly readable, why can it not be written as a comment?  MIME
> parameters are presumably intended for use by software.  It seems
> unnecessary to allocate a MIME parameter field for something that
> isn't used by software.

The versions parameter is intended to be human-readable.
"A comment" is somewhat nebulous (support for comments,
as well as specific syntax, may differ in some contexts). Also,
there is no expectation that comments will be preserved
during transport and processing, whereas there is no reason
to believe that any parameter would be discarded.  I see
nothing in RFCs 2045, 2048 that indicate that parameters
are intended solely for machine use.  The purpose of labeling
some content as a particular media type is presumably to
provide some useful metadata about the content, regardless
of whether that metadata is used by a human or by a
machine.

> The "process" parameter, as in:
> 
>    Content-Type: text/troff ;
>     process="GROFF_NO_SGR=1 dformat | pic -n | troff -ms"
> 
> makes me feel uneasy.  Are MUAs expected to parse the expression to
> recognize dangerous commands?

I would say that MUAs may ignore the parameter, or they may
offer to run commands subject to user approval.  Under no
circumstances should execution of general-purpose processing
programs be performed by MUAs without user consent -- see
RFC 2046 discussion of application/postscript.  In this case,
similar considerations apply (e.g. while it may be safe for a UA
to process this content via deroff, there should be no
automatic processing of the originator-specified command
pipeline.  I believe the issues are discussed in the Security
considerations section of the registration template.

Bear in mind the fact that the optional process parameter is
provided as a means of conveying formatting process
information associated with the media; such processing is
not necessary to read the *text* in the media (similar to
text/sgml).

> Is this portable? 

Portability issues are addressed in the Interoperability
considerations section of the registration template, and
via the versions parameter.
 
> I looked at how Gnus implement troff files:
> 
>     (".man"   . "application/x-troff-man")
>     (".me"    . "application/x-troff-me")
>     (".ms"    . "application/x-troff-ms")
>     (".tr"    . "application/x-troff")
>     (".troff" . "application/x-troff")
> 
> This suggest that maybe the troff format should not be a considered a
> separate MIME sub-type, but rather a set of languages.  Much like XML.
> 
> While I think the "+xml" for XML formats was a horrid idea, I can't
> help but feel that we'd might have the same situation here, as in:
> 
> text/man+troff
> text/ms+troff
> text/mdoc+troff
> 
> That is, those types would be interpreted by loading the -man, -ms and
> -mdoc macros, respectively, in troff.  That is, "troff -man", "troff
> -ms", "troff -mdoc" respectively.  You could create new types for
> dformat+pic data.

IMO that way lies madness.  Such details do not affect the
ability to read *text* in the media.  Moreover, there are so many
possibilities that the number of media sub-sub-subtypes would
be daunting -- I don't need and wouldn't want a
text/dformat+chem+grap+pic+eqn+tbl+mm+4014
media type, or a
text/dformat+chem+grap+pic+tbl+eqn+mm+4014
media type (depending on whether or not equations appear
within tables).   Now that might (or might not) make
sense for an *application* subtype scheme, but it is
uncalled for for the purpose of a *text* media type.  I
thought I had addressed that issue in section 3 of the
draft (Scope of Specification), but I can reword that
section more forcefully if necessary.
>From [email-masked]  Tue Dec  7 05:09:31 2004
From: tony at att.com (Tony Hansen)
Date: Tue Dec  7 05:09:51 2004
Subject: I-D ACTION:draft-lilly-text-troff-00.txt
In-Reply-To: <[email-masked]>
References: <[email-masked]>
Message-ID: <[email-masked]>

I have a serious problem with this parameter:

       process
          Lists a recommended command pipeline for formatting.  The
          parameter value may need to be quoted or encoded as provided
          for by [RFC2045] as amended by [RFC2231] and [errata].

I'd hate to see someone actually implement a mechanism to automatically 
execute the pipeline. I think this is just ASKING for someone to do so.

Now, the information provided in the pipeline IS useful; it provides the 
list of the preprocessors that are needed to properly process the troff 
souce. So instead, I'd recommend that there be a parameter that provides 
just THAT information:

       preprocessors
	Lists the preprocessors that need to be invoked to properly
	process the troff input. The names of the preprocessors are
	comma separated. The parameter value may need to be quoted or
	encoded as provided for by [RFC2045] as amended by [RFC2231]
	and [errata].

In addition, there is one more MAJOR parameter that doesn't appear to be 
specified anywhere: the macro package that was used in the troff 
document, such as man, mm, ms, me, etc. So, I'd like to see this 
optional parameter added:

      macro package
	Lists the macro package that needs to be used with the troff
	document. Examples of macro package names are man, mm, ms and
	me.

	Tony Hansen
	[email-masked]
>From [email-masked]  Tue Dec  7 06:29:04 2004
From: blilly at erols.com (Bruce Lilly)
Date: Tue Dec  7 06:29:12 2004
Subject: I-D ACTION:draft-lilly-text-troff-00.txt
In-Reply-To: <[email-masked]>
References: <[email-masked]> <[email-masked]>
Message-ID: <[email-masked]>

On Mon December 6 2004 23:09, Tony Hansen wrote:
> I have a serious problem with this parameter:
> 
>        process
>           Lists a recommended command pipeline for formatting.  The
>           parameter value may need to be quoted or encoded as provided
>           for by [RFC2045] as amended by [RFC2231] and [errata].
> 
> I'd hate to see someone actually implement a mechanism to automatically 
> execute the pipeline. I think this is just ASKING for someone to do so.

The draft registration text specifically addresses that issue
under Security considerations.  While I agree that *automatic*
execution of a pipeline should be avoided, I see no reason
why the suggested pipeline should not be presented to a user
for confirmation prior to execution (that would achieve the
same thing as manual rekeyboarding of the command
pipeline, but with less potential for typographical errors), if
the user initiated some action that would normally be
associated with execution.

> Now, the information provided in the pipeline IS useful; it provides the 
> list of the preprocessors that are needed to properly process the troff 
> souce. So instead, I'd recommend that there be a parameter that provides 
> just THAT information:
> 
>        preprocessors
> 	Lists the preprocessors that need to be invoked to properly
> 	process the troff input. The names of the preprocessors are
> 	comma separated. The parameter value may need to be quoted or
> 	encoded as provided for by [RFC2045] as amended by [RFC2231]
> 	and [errata].

But it isn't a mere "list of preprocessors"; it's an *ordered* list of
preprocessors, formatter, and postprocessors *with option flags*
and environment variable settings.  Invoking preprocessors in
the wrong order (e.g. running pic before grap) isn't useful, nor
is omitting option flags (e.g. macro packages).  And environment
variables can have a profound effect on operation (try the
latest version of groff's "nroff" w/o GROFF_NO_SGR to format
an I-D or RFC using ms macros NH or SH , for example). Finally,
a comma might well appear in the name of a preprocessor,
formatter, or postprocessor (nothing forbids that, as comma is
not a command interpreter (a.k.a. shell) metacharacter), so
that would require some additional escape or quoting mechanism.

Obfuscating a command pipeline by substituting commas for
vertical bars isn't going to prevent a wayward programmer
bent on automatic execution from making the reverse
translation.  Nor will it prevent careless users from doing the
same.

> In addition, there is one more MAJOR parameter that doesn't appear to be 
> specified anywhere: the macro package that was used in the troff 
> document, such as man, mm, ms, me, etc. So, I'd like to see this 
> optional parameter added:
> 
>       macro package
> 	Lists the macro package that needs to be used with the troff
> 	document. Examples of macro package names are man, mm, ms and
> 	me.

That's specified as an option flag to the formatter. It's also
theoretically possible to have multiple macro packages, though
major ones would almost certainly clash (however I have used
additional macros with -man to handle tables in man pages).
And one cannot have a parameter attribute name with an
embedded space character.
>From [email-masked]  Tue Dec  7 15:39:35 2004
From: derhoermi at gmx.net (Bjoern Hoehrmann)
Date: Tue Dec  7 15:39:38 2004
Subject: SVG12: image/svg+xml gzip requirements
Message-ID: <[email-masked]>

Dear Scalable Vector Graphics Working Group,

  The current http://www.w3.org/TR/SVG12/mimereg.html notes:

[...]
  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 RFC1952 section 2.3.1. 
[...]

Unless the document is meant to introduce a new HTTP header, this is
clearly false, RFC 2616 explicitly notes that Content-Transfer-Encoding
is not used in HTTP/1.1, please change the text to refer to an actual
HTTP header.

I am puzzled by the last sentence here, the text seems to suggest that
implementations of the image/svg+xml MIME type are required to sniff for
gzip compressed content so that much of the ill-formed SVG content

  http://lists.w3.org/Archives/Public/www-svg/2004Dec/0031.html

where content is compressed but the compression is not indicated through
the relevant HTTP headers would actually be conforming. This is not
accetable as it is inconsistent with the Authoritative Metadata TAG
finding http://www.w3.org/2001/tag/doc/mime-respect.html and RFC 3023
and 2616 which do not include such a requirement which means that such
content would not work in general purpose XML processors which means
that use of the +xml convention for image/svg+xml would not be
appropriate.

Please change the text to clearly indicate that this is not allowed and
that SVG Viewers are required to treat such content as ill-formed XML
and thus reject it entirely.

regards.
-- 
Bj?rn H?hrmann ? mailto:[email-masked] ? http://bjoern.hoehrmann.de
Weinh. Str. 22 ? Telefon: +49(0)621/4309674 ? http://www.bjoernsworld.de
68309 Mannheim ? PGP Pub. KeyID: 0xA4357E78 ? http://www.websitedev.de/ 
>From [email-masked]  Wed Dec  8 18:38:43 2004
From: derhoermi at gmx.net (Bjoern Hoehrmann)
Date: Wed Dec  8 18:38:46 2004
Subject: SVG12: image/svg+xml gzip requirements
In-Reply-To: <[email-masked]>
References: <[email-masked]>
	<[email-masked]>
Message-ID: <[email-masked]>

* Thomas DeWeese wrote:
>   Please don't rewrite the TAG finding.  The TAG indicates that
>User agents should 'notify' the user of the problem.  It does not say
>that these documents must be rejected.

Appendix F.1 of the SVG 1.1 Recommendation requires that rendering must
stop after a fatal error as defined in the XML 1.0 Recommendation has
been encountered, which in case of the relevant documents means after
reading the very first octet of the binary resource. The TAG finding,
even if it disagrees with the SVG 1.1 Recommendation, has no authority
to override this conformance requirement.

>   I might also point out 4.2 where the last paragraph says:
>
>     Representation providers SHOULD NOT in general specify the
>     character encoding for XML data in protocol headers since the data
>     is self-describing.
>
>   Which would seem to support not including the character encoding
>in the SVG mime type.

It does not. It says you should not use the charset parameter, it
does not say XML MIME Type registrations should define inconsistent
processing rules for XML resources that use the charset parameter.
-- 
Bj?rn H?hrmann ? mailto:[email-masked] ? http://bjoern.hoehrmann.de
Weinh. Str. 22 ? Telefon: +49(0)621/4309674 ? http://www.bjoernsworld.de
68309 Mannheim ? PGP Pub. KeyID: 0xA4357E78 ? http://www.websitedev.de/ 
>From [email-masked]  Wed Dec  8 20:35:21 2004
From: derhoermi at gmx.net (Bjoern Hoehrmann)
Date: Wed Dec  8 20:35:22 2004
Subject: SVG12: image/svg+xml gzip requirements
In-Reply-To: <[email-masked]>
References: <[email-masked]>
	<[email-masked]>
	<[email-masked]>
	<[email-masked]>
Message-ID: <[email-masked]>

* Thomas DeWeese wrote:
>    But this is a case of inconsistent meta-data.  The sender says
>that the data is not encoded, but the content indicates that it is
>GZIP encoded.  Thus the user agent is allowed via the TAG to notice
>this inconsistency and override the sender metadata (the UA at
>this point should also notify the user of the override).  Once it
>has overridden the sender data it can interpret the data stream as
>GZIP compressed and get a valid XML Document.

The TAG finding has no impact whatsoever on SVG Viewer conformance
requirements, I think the TAG will happily clarify this if you ask
for it on www-tag. You would need to argue that this is allowed by
the SVG Viewer conformance requirements. I think it is clear that
this is not allowed by those conformance requirements.

>    Saying there can/should not be a charset parameter for
>image/svg+xml or if there is one it _must_ match the XML document's
>encoding is not the same as defining inconsistent processing rules, it
>is supporting the TAG finding.

I agree that this is not the same thing, but I would like to point
out that the proposed MIME Type registration does not discuss that
such information must match, it rather requires implementations to
ignore the charset parameter if provided which is inconsistent with
the processing rules for all other XML MIME Types where it is re-
quired that the charset parameter is honored.

>    As I have stated before if senders conform to the mime-type
>registration no conflict can possibly occur, everyone processes the
>content consistently.

This is false.

>    What I don't get is why you think image/svg+xml can not possibly
>have anything different about it from text/xml.  Does this mean that
>all the SVG UA's are in error because they process the document
>and display it as graphics?  After all that isn't what existing XML
>processors do they must be broken...

What an SVG Viewer might do in addition to XML processing is not of
concern here, but the XML processing is.

>    I think that as long as someone _following_ the image/svg+xml
>mime-type registration does not break existing XML processors there
>is no legacy problem.  This would allow the registration to explicitly
>disallow charset and not break anything or require that it _always_
>match with undefined behavior if it doesn't.  If it specified the
>charset parameter was ignored that would be problematic.

The proposed reqistration renders a broad range of applications non-
conforming, I've already mentioned the W3C Markup Validator, the W3C
CSS Validator, Microsoft's MSXML 4/5 XML toolkit, and Batik. I have
not seen a revised registration proposal so I can't comment on that.

>    Does anyone think it really was a good idea to allow for a
>charset that differs from the content?  Or are we just propagating a
>bad decision on future generations?

RFC 3023 revisions are best discussed on [email-masked].
-- 
Bj?rn H?hrmann ? mailto:[email-masked] ? http://bjoern.hoehrmann.de
Weinh. Str. 22 ? Telefon: +49(0)621/4309674 ? http://www.bjoernsworld.de
68309 Mannheim ? PGP Pub. KeyID: 0xA4357E78 ? http://www.websitedev.de/ 
>From [email-masked]  Wed Dec  8 21:45:41 2004
From: derhoermi at gmx.net (Bjoern Hoehrmann)
Date: Wed Dec  8 21:45:42 2004
Subject: SVG12: image/svg+xml gzip requirements
In-Reply-To: <[email-masked]>
References: <[email-masked]>
	<[email-masked]>
	<[email-masked]>
	<[email-masked]>
	<[email-masked]>
	<[email-masked]>
Message-ID: <[email-masked]>

* Thomas DeWeese wrote:
>> The TAG finding has no impact whatsoever on SVG Viewer conformance
>> requirements, I think the TAG will happily clarify this if you ask
>> for it on www-tag. You would need to argue that this is allowed by
>> the SVG Viewer conformance requirements. I think it is clear that
>> this is not allowed by those conformance requirements.
>
>    Huh?  If the network layer detects that the HTTP response
>is in fact GZip encoded even though the header isn't set and decodes
>it why is this a problem?

Because such software does not interoperate with software that does not
perform such error correction. Would you also argue that for a ISO-8859-
1 encoded document

  Content-Type: image/svg+xml

  <?xml version="1.0"?>
  ...
  <text>Bj?rn</text>
  ...

the "network layer" may detect that the resource is ISO-8859-1 encoded
and decodes it? The XML 1.0 Recommendation requires here, too, that the
processor aborts normal processing and reports a fatal error to the
application. I am not sure where you draw the line between errors this
"network layer" may correct.

>    I'll agree with this.  However you should then agree that there is
>no problem if the SVG mime-type registration states that there is _no_
>charset parameter for image/svg+xml, and merely suggests that if a
>processor encounters this non-existing parameter that it should be
>ignored.

The proposed registration implies "MUST ignore", changing that to SHOULD
ignore is even worse as it explicitly allows non-interoperable behavior.
-- 
Bj?rn H?hrmann ? mailto:[email-masked] ? http://bjoern.hoehrmann.de
Weinh. Str. 22 ? Telefon: +49(0)621/4309674 ? http://www.bjoernsworld.de
68309 Mannheim ? PGP Pub. KeyID: 0xA4357E78 ? http://www.websitedev.de/ 
>From [email-masked]  Wed Dec  8 22:39:53 2004
From: derhoermi at gmx.net (Bjoern Hoehrmann)
Date: Wed Dec  8 22:39:53 2004
Subject: SVG12: image/svg+xml gzip requirements
In-Reply-To: <[email-masked]>
References: <[email-masked]>
	<[email-masked]>
	<[email-masked]>
	<[email-masked]>
	<[email-masked]>
	<[email-masked]>
	<[email-masked]>
	<[email-masked]>
Message-ID: <[email-masked]>

* Thomas DeWeese wrote:
>>>   Huh?  If the network layer detects that the HTTP response
>>>is in fact GZip encoded even though the header isn't set and decodes
>>>it why is this a problem?
>> 
>> Because such software does not interoperate with software that does not
>> perform such error correction. 
>
>    Well, you are free to your option but don't reference a TAG finding
>saying it doesn't support this behavior when it clearly does!

<http://www.w3.org/2001/tag/doc/mime-respect.html>:

[...]
  Format specifications SHOULD NOT work against the Web architecture
  by requiring or suggesting that a recipient override sender-provided
  metadata without user consent.
[...]

Use of the +xml convention implies that such metadata needs to be
overridden (e.g. by implying further metadata) in order to process the
content any further than the first character. You will find further
information in the TAG finding that supports my claim, for example, the
HTML sniffing in section 2.1 is not much different from gzip compression
sniffing. You will also find that the AWWW document goes even further
and constraints "Agents MUST NOT ignore message metadata without the
consent of the user" and includes the principle "Agents that recover
from error by making a choice without the user's consent are not acting
on the user's behalf". The proposed registration does not discuss user
consent in any way and is thus inconsistent with the requirement in the
TAG finding, and actually with the "Architecture of the World Wide Web",
too.

If the registration is changed to require user consent to this operation
it might be more consistent with these TAG findings; I would not accept
such a resolution though. I very much disagree that the TAG supports
silent error recovery. If you think my interpretation of these TAG
publications is not what the TAG really intended, please request that
the TAG clarifies their materials so we can discuss this on more solid
grounds.
-- 
Bj?rn H?hrmann ? mailto:[email-masked] ? http://bjoern.hoehrmann.de
Weinh. Str. 22 ? Telefon: +49(0)621/4309674 ? http://www.bjoernsworld.de
68309 Mannheim ? PGP Pub. KeyID: 0xA4357E78 ? http://www.websitedev.de/ 
>From [email-masked]  Fri Dec 10 06:33:19 2004
From: derhoermi at gmx.net (Bjoern Hoehrmann)
Date: Fri Dec 10 09:41:24 2004
Subject: SVG12: image/svg+xml gzip requirements
In-Reply-To: <[email-masked]>
References: <[email-masked]>
	<[email-masked]>
	<[email-masked]>
	<[email-masked]>
	<[email-masked]>
	<[email-masked]>
	<[email-masked]>
	<[email-masked]>
	<[email-masked]>
	<[email-masked]>
Message-ID: <[email-masked]>

* Chris Lilley wrote:
>BH> Use of the +xml convention implies that such metadata needs to be
>BH> overridden
>
>No, it does not. An xml encoding declaration is sender provided
>metadata. However, in the case where a charset parameter is allowed, and
>where it can be different, and thus where one has to win over the other,
>metadata is indeed being overridden. I agree with you that silent
>recovery here is not inthe user interest and a warning should be shown.

You either missed that the mail you responded to did not discuss the
charset parameter at all, or you are trying to suggest that there is
a character encoding that is based on gzip. Such a character encoing
would of course by easy to construct,

  In order to encode a XML document using the gzip-xml character
  encoding, the XML document is first serialized using a second
  character encoding such that the resulting octet sequence meets
  the requirements of the XML 1.0 Recommendation. The new octet
  sequence is then compressed using the gzip method as defined in
  RFC 1952.

  In order to decode a gzip-xml encoded XML document, the octet
  stream that represents the XML document is first uncompressed
  using the method defined in RFC 1952. The decoder determines
  then the character encoding of the resulting octet sequence as
  defined in the XML 1.0 Recommendation and decodes the sequence
  according to this character encoding with the exception that
  the resulting character sequence must be constructed such that
  XML processors that would processes the character sequence
  would only read EncName nonterminals that match "gzip-xml" in
  order to circumvent the the requirment in the XML 1.0 Rec that
    
    ... it is a fatal error for an entity including an encoding
    declaration to be presented to the XML processor in an
    encoding other than that named in the declaration ...

  Implementations may implement other algorithms than those
  described above as long as those alternate algorithms yield
  in the same processing result.

If you imply this gzip-xml character encoding then there is indeed
no metadata that is overriden (unless there happend to be higher-
level protocol information that would require XML processors to
determine a character encoding that is different from "gzip-xml").
If that is your point, I should probably request that support for
this gzip-xml character encoding is required for SVG Viewers...
-- 
Bj?rn H?hrmann ? mailto:[email-masked] ? http://bjoern.hoehrmann.de
Weinh. Str. 22 ? Telefon: +49(0)621/4309674 ? http://www.bjoernsworld.de
68309 Mannheim ? PGP Pub. KeyID: 0xA4357E78 ? http://www.websitedev.de/ 
>From [email-masked]  Fri Dec 10 04:51:38 2004
From: chris at w3.org (Chris Lilley)
Date: Fri Dec 10 09:41:53 2004
Subject: SVG12: image/svg+xml gzip requirements
In-Reply-To: <[email-masked]>
References: <[email-masked]>
	<[email-masked]>
	<[email-masked]>
	<[email-masked]>
	<[email-masked]>
	<[email-masked]>
	<[email-masked]>
	<[email-masked]>
Message-ID: <[email-masked]>

On Wednesday, December 8, 2004, 9:56:10 PM, Ian wrote:

IH> Indeed; the logical conclusion of the "correct it in the network layer"
IH> thinking is how you get to the world where IE will treat anything that
IH> happens to contain the string "<html>" as an HTML document, even if it is
IH> sent as text/plain.

But only if its in the first 256 bytes, so be carefull with those long
comments before the root element.

It also led to anything with Content transfer encoding being saved to
disk! which is why some SVG content was served without that, as an IE
workaround. It seems to be becoming less common. And of course, Firefox
and Opera and Safari don't have those sort of problems. Its something of
a FAQ.

IH> That kind of "magic error fixing" has security 
IH> implications (hence why XPSP2 reduced the amount of sniffing in IE).

IH> I would strongly recommend that specs disallow sniffing of any kind,
IH> treating all metadata as authorative

They do, although the xml encoding declaration is metadata too.

IH> (and giving explicit priorities to handle metadata contradictions).
IH> In certain rare cases where sniffing is required due to missing
IH> metadata (as in the lack of byte order information when no
IH> authorative default is stated), then the sniffing performed should
IH> be well defined in order to allow all UAs to have exact
IH> interoperability.

Yes. And reading an explicit xml encoding declaration, or choosing
between UTF-8, UTF-8 (with BOM) and UTF-16 (with BOM) is well defined in
the XML specification.

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

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

On Mon December 6 2004 15:59, Simon Josefsson wrote:
> Bruce Lilly <[email-masked]> writes:
> 
> > ftp://ftp.isi.edu/in-notes/internet-drafts/draft-lilly-text-troff-00.txt
> 
> One comment on the "versions" parameter. If it is only meant to be
> humanly readable, why can it not be written as a comment?  MIME
> parameters are presumably intended for use by software.  It seems
> unnecessary to allocate a MIME parameter field for something that
> isn't used by software.

The versions parameter is intended to be human-readable.
"A comment" is somewhat nebulous (support for comments,
as well as specific syntax, may differ in some contexts). Also,
there is no expectation that comments will be preserved
during transport and processing, whereas there is no reason
to believe that any parameter would be discarded.  I see
nothing in RFCs 2045, 2048 that indicate that parameters
are intended solely for machine use.  The purpose of labeling
some content as a particular media type is presumably to
provide some useful metadata about the content, regardless
of whether that metadata is used by a human or by a
machine.

> The "process" parameter, as in:
> 
>    Content-Type: text/troff ;
>     process="GROFF_NO_SGR=1 dformat | pic -n | troff -ms"
> 
> makes me feel uneasy.  Are MUAs expected to parse the expression to
> recognize dangerous commands?

I would say that MUAs may ignore the parameter, or they may
offer to run commands subject to user approval.  Under no
circumstances should execution of general-purpose processing
programs be performed by MUAs without user consent -- see
RFC 2046 discussion of application/postscript.  In this case,
similar considerations apply (e.g. while it may be safe for a UA
to process this content via deroff, there should be no
automatic processing of the originator-specified command
pipeline.  I believe the issues are discussed in the Security
considerations section of the registration template.

Bear in mind the fact that the optional process parameter is
provided as a means of conveying formatting process
information associated with the media; such processing is
not necessary to read the *text* in the media (similar to
text/sgml).

> Is this portable? 

Portability issues are addressed in the Interoperability
considerations section of the registration template, and
via the versions parameter.
 
> I looked at how Gnus implement troff files:
> 
>     (".man"   . "application/x-troff-man")
>     (".me"    . "application/x-troff-me")
>     (".ms"    . "application/x-troff-ms")
>     (".tr"    . "application/x-troff")
>     (".troff" . "application/x-troff")
> 
> This suggest that maybe the troff format should not be a considered a
> separate MIME sub-type, but rather a set of languages.  Much like XML.
> 
> While I think the "+xml" for XML formats was a horrid idea, I can't
> help but feel that we'd might have the same situation here, as in:
> 
> text/man+troff
> text/ms+troff
> text/mdoc+troff
> 
> That is, those types would be interpreted by loading the -man, -ms and
> -mdoc macros, respectively, in troff.  That is, "troff -man", "troff
> -ms", "troff -mdoc" respectively.  You could create new types for
> dformat+pic data.

IMO that way lies madness.  Such details do not affect the
ability to read *text* in the media.  Moreover, there are so many
possibilities that the number of media sub-sub-subtypes would
be daunting -- I don't need and wouldn't want a
text/dformat+chem+grap+pic+eqn+tbl+mm+4014
media type, or a
text/dformat+chem+grap+pic+tbl+eqn+mm+4014
media type (depending on whether or not equations appear
within tables).   Now that might (or might not) make
sense for an *application* subtype scheme, but it is
uncalled for for the purpose of a *text* media type.  I
thought I had addressed that issue in section 3 of the
draft (Scope of Specification), but I can reword that
section more forcefully if necessary.

From: al at akc.com (Al Costanzo)
Date: Mon Dec  6 22:07:18 2004
Subject: Testing the waters for text/troff
References: <[email-masked]><[email-masked]><[email-masked]><[email-masked]> <[email-masked]>
Message-ID: <002601c4dbd7$4bc6fc40$6301a8c0@vpngw>

I disagree.  I see no reason why you cannot allocate a param as a comment
and I support it.

Al
----- Original Message ----- 
From: "Simon Josefsson" <[email-masked]>
To: <[email-masked]>
Sent: Monday, December 06, 2004 3:59 PM
Subject: Re: Testing the waters for text/troff

> Bruce Lilly <[email-masked]> writes:
>
> > ftp://ftp.isi.edu/in-notes/internet-drafts/draft-lilly-text-troff-00.txt
>
> One comment on the "versions" parameter. If it is only meant to be
> humanly readable, why can it not be written as a comment?  MIME
> parameters are presumably intended for use by software.  It seems
> unnecessary to allocate a MIME parameter field for something that
> isn't used by software.
>
> The "process" parameter, as in:
>
>    Content-Type: text/troff ;
>     process="GROFF_NO_SGR=1 dformat | pic -n | troff -ms"
>
> makes me feel uneasy.  Are MUAs expected to parse the expression to
> recognize dangerous commands?  Is this portable?
>
> I looked at how Gnus implement troff files:
>
>     (".man"   . "application/x-troff-man")
>     (".me"    . "application/x-troff-me")
>     (".ms"    . "application/x-troff-ms")
>     (".tr"    . "application/x-troff")
>     (".troff" . "application/x-troff")
>
> This suggest that maybe the troff format should not be a considered a
> separate MIME sub-type, but rather a set of languages.  Much like XML.
>
> While I think the "+xml" for XML formats was a horrid idea, I can't
> help but feel that we'd might have the same situation here, as in:
>
> text/man+troff
> text/ms+troff
> text/mdoc+troff
>
> That is, those types would be interpreted by loading the -man, -ms and
> -mdoc macros, respectively, in troff.  That is, "troff -man", "troff
> -ms", "troff -mdoc" respectively.  You could create new types for
> dformat+pic data.
>
> Thanks,
> Simon
>
>

From: al at akc.com (Al Costanzo)
Date: Tue Jan  3 16:22:52 2006
Subject: Testing the waters for text/troff
References: <[email-masked]><[email-masked]><[email-masked]><[email-masked]> <[email-masked]>
Message-ID: <002601c4dbd7$4bc6fc40$6301a8c0@vpngw>

I disagree.  I see no reason why you cannot allocate a param as a comment
and I support it.

Al
----- Original Message ----- 
From: "Simon Josefsson" <[email-masked]>
To: <[email-masked]>
Sent: Monday, December 06, 2004 3:59 PM
Subject: Re: Testing the waters for text/troff

> Bruce Lilly <[email-masked]> writes:
>
> > ftp://ftp.isi.edu/in-notes/internet-drafts/draft-lilly-text-troff-00.txt
>
> One comment on the "versions" parameter. If it is only meant to be
> humanly readable, why can it not be written as a comment?  MIME
> parameters are presumably intended for use by software.  It seems
> unnecessary to allocate a MIME parameter field for something that
> isn't used by software.
>
> The "process" parameter, as in:
>
>    Content-Type: text/troff ;
>     process="GROFF_NO_SGR=1 dformat | pic -n | troff -ms"
>
> makes me feel uneasy.  Are MUAs expected to parse the expression to
> recognize dangerous commands?  Is this portable?
>
> I looked at how Gnus implement troff files:
>
>     (".man"   . "application/x-troff-man")
>     (".me"    . "application/x-troff-me")
>     (".ms"    . "application/x-troff-ms")
>     (".tr"    . "application/x-troff")
>     (".troff" . "application/x-troff")
>
> This suggest that maybe the troff format should not be a considered a
> separate MIME sub-type, but rather a set of languages.  Much like XML.
>
> While I think the "+xml" for XML formats was a horrid idea, I can't
> help but feel that we'd might have the same situation here, as in:
>
> text/man+troff
> text/ms+troff
> text/mdoc+troff
>
> That is, those types would be interpreted by loading the -man, -ms and
> -mdoc macros, respectively, in troff.  That is, "troff -man", "troff
> -ms", "troff -mdoc" respectively.  You could create new types for
> dformat+pic data.
>
> Thanks,
> Simon
>
>

From: jas at extundo.com (Simon Josefsson)
Date: Tue Jan  3 16:22:52 2006
Subject: Testing the waters for text/troff
References: <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]>
Message-ID: <[email-masked]>

Bruce Lilly <[email-masked]> writes:

> ftp://ftp.isi.edu/in-notes/internet-drafts/draft-lilly-text-troff-00.txt

One comment on the "versions" parameter. If it is only meant to be
humanly readable, why can it not be written as a comment?  MIME
parameters are presumably intended for use by software.  It seems
unnecessary to allocate a MIME parameter field for something that
isn't used by software.

The "process" parameter, as in:

   Content-Type: text/troff ;
    process="GROFF_NO_SGR=1 dformat | pic -n | troff -ms"

makes me feel uneasy.  Are MUAs expected to parse the expression to
recognize dangerous commands?  Is this portable?

I looked at how Gnus implement troff files:

    (".man"   . "application/x-troff-man")
    (".me"    . "application/x-troff-me")
    (".ms"    . "application/x-troff-ms")
    (".tr"    . "application/x-troff")
    (".troff" . "application/x-troff")

This suggest that maybe the troff format should not be a considered a
separate MIME sub-type, but rather a set of languages.  Much like XML.

While I think the "+xml" for XML formats was a horrid idea, I can't
help but feel that we'd might have the same situation here, as in:

text/man+troff
text/ms+troff
text/mdoc+troff

That is, those types would be interpreted by loading the -man, -ms and
-mdoc macros, respectively, in troff.  That is, "troff -man", "troff
-ms", "troff -mdoc" respectively.  You could create new types for
dformat+pic data.

Thanks,
Simon

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

FYI, I've prepared an Internet Draft for a text/troff type registration.
It's available via ftp from:
ftp://ftp.isi.edu/in-notes/internet-drafts/draft-lilly-text-troff-00.txt

PostScript and PDF versions are also available (there is some
difference in the example formatting detail and in such
minutiae as copyright symbol vs. "(C)") as:
ftp://ftp.isi.edu/in-notes/internet-drafts/draft-lilly-text-troff-00.ps
ftp://ftp.isi.edu/in-notes/internet-drafts/draft-lilly-text-troff-00.pdf

I plan the following changes for the next version:
  the command line for the example is missing "pic"
  more de-PC-ing of boilerplate ("HE/SHE" -- ptui)
  an additional example (approximation of the diagram
    in RFC 2821 section 2.1).

From: mankin at psg.com (Allison Mankin)
Date: Wed Dec  1 20:57:37 2004
Subject: Media Type review request for video/h264
Message-ID: <[email-masked]>

The Transport Area requests a Media Type review for a new type,
video/h264, intended for the IETF tree, and specified in 
http://www.ietf.org/internet-drafts/draft-ietf-avt-rtp-h264-11.txt
(Section 8.1).

We believe the change controller should be the IESG rather than a
working group.  Please let us know any other issues asap.

Thanks,

Allison
>From [email-masked]  Mon Dec  6 20:07:06 2004
From: blilly at erols.com (Bruce Lilly)
Date: Mon Dec  6 20:07:33 2004
Subject: Testing the waters for text/troff
In-Reply-To: <[email-masked]>
References: <[email-masked]>
	<[email-masked]>
	<[email-masked]>
Message-ID: <[email-masked]>

FYI, I've prepared an Internet Draft for a text/troff type registration.
It's available via ftp from:
ftp://ftp.isi.edu/in-notes/internet-drafts/draft-lilly-text-troff-00.txt

PostScript and PDF versions are also available (there is some
difference in the example formatting detail and in such
minutiae as copyright symbol vs. "(C)") as:
ftp://ftp.isi.edu/in-notes/internet-drafts/draft-lilly-text-troff-00.ps
ftp://ftp.isi.edu/in-notes/internet-drafts/draft-lilly-text-troff-00.pdf

I plan the following changes for the next version:
  the command line for the example is missing "pic"
  more de-PC-ing of boilerplate ("HE/SHE" -- ptui)
  an additional example (approximation of the diagram
    in RFC 2821 section 2.1).
>From [email-masked]  Mon Dec  6 21:59:16 2004
From: jas at extundo.com (Simon Josefsson)
Date: Mon Dec  6 22:01:24 2004
Subject: Testing the waters for text/troff
References: <[email-masked]>
	<[email-masked]>
	<[email-masked]>
	<[email-masked]>
Message-ID: <[email-masked]>

Bruce Lilly <[email-masked]> writes:

> ftp://ftp.isi.edu/in-notes/internet-drafts/draft-lilly-text-troff-00.txt

One comment on the "versions" parameter. If it is only meant to be
humanly readable, why can it not be written as a comment?  MIME
parameters are presumably intended for use by software.  It seems
unnecessary to allocate a MIME parameter field for something that
isn't used by software.

The "process" parameter, as in:

   Content-Type: text/troff ;
    process="GROFF_NO_SGR=1 dformat | pic -n | troff -ms"

makes me feel uneasy.  Are MUAs expected to parse the expression to
recognize dangerous commands?  Is this portable?

I looked at how Gnus implement troff files:

    (".man"   . "application/x-troff-man")
    (".me"    . "application/x-troff-me")
    (".ms"    . "application/x-troff-ms")
    (".tr"    . "application/x-troff")
    (".troff" . "application/x-troff")

This suggest that maybe the troff format should not be a considered a
separate MIME sub-type, but rather a set of languages.  Much like XML.

While I think the "+xml" for XML formats was a horrid idea, I can't
help but feel that we'd might have the same situation here, as in:

text/man+troff
text/ms+troff
text/mdoc+troff

That is, those types would be interpreted by loading the -man, -ms and
-mdoc macros, respectively, in troff.  That is, "troff -man", "troff
-ms", "troff -mdoc" respectively.  You could create new types for
dformat+pic data.

Thanks,
Simon