[admin] Missed spam (was Re: Registration of MIME media type application/ocsp-response
distobj at acm.org (Mark Baker) Tue, 16 August 2005 19:28 UTC
From: "distobj at acm.org"
Date: Tue, 16 Aug 2005 19:28:44 +0000
Subject: [admin] Missed spam (was Re: Registration of MIME media type application/ocsp-response
In-Reply-To: <20050815111454.867776CA09@proxy3.suda.edu.cn>
References: <20050815111454.867776CA09@proxy3.suda.edu.cn>
Message-ID: <20050816173026.GP14127@markbaker.ca>
X-Date: Tue Aug 16 19:28:44 2005
Oops, my bad; sorry for letting that one through. So much for eyeing the subject-line as a time-saving spam checking strategy. *sigh* Mark. >From hugo@w3.org Wed Aug 17 12:47:42 2005 From: hugo at w3.org (Hugo Haas) Date: Wed Aug 17 12:47:47 2005 Subject: Registration of media type application/wsdl+xml Message-ID: <20050817104742.GD24041@w3.org> Following the procedure outlined in How to Register an Internet Media Type for a W3C Specification[1], I would like to request comments about the definition of the application/wsdl+xml media type. This new media type is defined in Web Services Description Language (WSDL) Version 2.0 Part 1: Core Language, W3C Working Draft 3 August 2005, which is a Last Call Working Draft[2], for which comments are invited until 19 September 2005 to the public-ws-desc-comments@w3.org mailing list (Reply-To set appropriately). The Web Services Description Language Version 2.0 (WSDL 2.0) is an XML language for describing Web services. Note that a previous Last Call Working Draft was published on 3 August 2005, for which feedback on the registration of application/wsdl+xml was requested on 4 October 2004[3] and the comment received[4] has been addressed in this new version. The definition of the media type can be found in appendix A. The application/wsdl+xml Media Type[5] of Web Services Description Language (WSDL) Version 2.0 Part 1: Core Language. A text copy of the section follows: A. The application/wsdl+xml Media Type This appendix defines the "application/wsdl+xml" media type which can be used to describe WSDL 2.0 documents serialized as XML. A.1 Registration MIME media type name: application MIME subtype name: wsdl+xml Required parameters: none Optional parameters: charset This parameter has identical semantics to the charset parameter of the "application/xml" media type as specified in [RFC 3023]. Encoding considerations: Identical to those of "application/xml" as described in [RFC 3023 ], section 3.2, as applied to the WSDL document Infoset. Security considerations: See section A.3 Security considerations. Interoperability considerations: There are no known interoperability issues. Published specifications: This document and [WSDL 2.0 Adjuncts]. Applications which use this media type: No known applications currently use this media type. Additional information: File extension: wsdl Fragment identifiers: Either a syntax identical to that of "application/xml" as described in [RFC 3023], section 5 or the syntax defined in A.2 Fragment Identifiers. Base URI: As specified in [RFC 3023], section 6. Macintosh File Type code: WSDL Person and email address to contact for further information: World Wide Web Consortium <web-human@w3.org> Intended usage: COMMON Author/Change controller: The WSDL 2.0 specification set is a work product of the World Wide Web Consortium's Web Service Description Working Group. The W3C has change control over these specifications. A.2 Fragment Identifiers This section defines a fragment identifier syntax for identifying components of a WSDL 2.0 document. This fragment identifier syntax is compliant with the [XPointer Framework]. A WSDL 2.0 fragment identifier consists of zero or more xmlns pointer parts followed by a pointer part as defined below. The pointer parts have a scheme name that corresponds to one of the standard WSDL 2.0 component types, and scheme data that is a path composed of names that identify the components. The scheme names all begin with the prefix "wsdl." to avoid name conflicts with other schemes. The names in the path are of type either QName, NCName, IRI, URI, or Pointer Part depending on the context. For QNames, any prefix MUST be defined by a preceding xmlns pointer part. If a QName does not have a prefix then its namespace name is the target namespace of the WSDL 2.0 document. The fragment identifier is typically constructed from the {name} property of the component and the {name} properties of its ancestors as a path according to Table A-1. The first column of this table gives the name of the WSDL 2.0 component. Columns labeled 1 through 4 specify the identifiers that uniquely identify the component within its context. Identifiers are typically formed from the {name} property, although in several cases references to other components are used. These identifiers are then used to construct the pointer part in the last column. Table A-1. Rules for determining pointer parts for WSDL 2.0 components ???????????????????????????????????????????????????????????????????????????????????????????????? ? Component ? 1 ? 2 ? 3 ? 4 ? Pointer Part ? ???????????????????????????????????????????????????????????????????????????????????????????????? ?Description?n/a ?n/a ?n/a ?n/a ?wsdl.description() ? ???????????????????????????????????????????????????????????????????????????????????????????????? ?Element ?element ?n/a ?n/a ?n/a ?wsdl.elementDeclaration( ? ?Declaration?QName ? ? ? ?element) ? ???????????????????????????????????????????????????????????????????????????????????????????????? ?Element ?element ?system URI ?n/a ?n/a ?wsdl.elementDeclaration( ? ?Declaration?QName ? ? ? ?element,system) ? ???????????????????????????????????????????????????????????????????????????????????????????????? ?Type ?type ?n/a ?n/a ?n/a ?wsdl.typeDefinition(type) ? ?Definition ?QName ? ? ? ? ? ???????????????????????????????????????????????????????????????????????????????????????????????? ?Type ?type ?system URI ?n/a ?n/a ?wsdl.typeDefinition(type, ? ?Definition ?QName ? ? ? ?system) ? ???????????????????????????????????????????????????????????????????????????????????????????????? ?Interface ?interface?n/a ?n/a ?n/a ?wsdl.interface(interface) ? ? ?NCName ? ? ? ? ? ???????????????????????????????????????????????????????????????????????????????????????????????? ?Interface ?interface?fault NCName ?n/a ?n/a ?wsdl.interfaceFault(interface/? ?Fault ?NCName ? ? ? ?fault) ? ???????????????????????????????????????????????????????????????????????????????????????????????? ?Interface ?interface?operation NCName ?n/a ?n/a ?wsdl.interfaceOperation( ? ?Operation ?NCName ? ? ? ?interface/operation) ? ???????????????????????????????????????????????????????????????????????????????????????????????? ?Interface ?interface? ?message? ?wsdl.interfaceMessageReference? ?Message ?NCName ?operation NCName ?NCName ?n/a ?(interface/operation/message) ? ?Reference ? ? ? ? ? ? ???????????????????????????????????????????????????????????????????????????????????????????????? ?Interface ?interface? ?message?fault ?wsdl.interfaceFaultReference( ? ?Fault ?NCName ?operation NCName ?NCName ?QName ?interface/operation/message/ ? ?Reference ? ? ? ? ?fault) ? ???????????????????????????????????????????????????????????????????????????????????????????????? ?Binding ?binding ?n/a ?n/a ?n/a ?wsdl.binding(binding) ? ? ?NCName ? ? ? ? ? ???????????????????????????????????????????????????????????????????????????????????????????????? ?Binding ?binding ?fault QName ?n/a ?n/a ?wsdl.bindingFault(binding/ ? ?Fault ?NCName ? ? ? ?fault) ? ???????????????????????????????????????????????????????????????????????????????????????????????? ?Binding ?binding ?operation QName ?n/a ?n/a ?wsdl.bindingOperation(binding/? ?Operation ?NCName ? ? ? ?operation) ? ???????????????????????????????????????????????????????????????????????????????????????????????? ?Binding ?binding ? ?message? ?wsdl.bindingMessageReference( ? ?Message ?NCName ?operation QName ?NCName ?n/a ?binding/operation/message) ? ?Reference ? ? ? ? ? ? ???????????????????????????????????????????????????????????????????????????????????????????????? ?Binding ?binding ? ?fault ?message?wsdl.bindingFaultReference( ? ?Fault ?NCName ?operation QName ?QName ?NCName ?binding/operation/fault/ ? ?Reference ? ? ? ? ?message) ? ???????????????????????????????????????????????????????????????????????????????????????????????? ?Service ?service ?n/a ?n/a ?n/a ?wsdl.service(service) ? ? ?NCName ? ? ? ? ? ???????????????????????????????????????????????????????????????????????????????????????????????? ?Endpoint ?service ?endpoint NCName ?n/a ?n/a ?wsdl.endpoint(service/endpoint? ? ?NCName ? ? ? ?) ? ???????????????????????????????????????????????????????????????????????????????????????????????? ? ?parent ? ? ? ? ? ?Feature ?Pointer ?feature IRI ?n/a ?n/a ?wsdl.feature(parent/feature) ? ? ?Part ? ? ? ? ? ???????????????????????????????????????????????????????????????????????????????????????????????? ? ?parent ? ? ? ? ? ?Property ?Pointer ?property IRI ?n/a ?n/a ?wsdl.property(parent/property)? ? ?Part ? ? ? ? ? ???????????????????????????????????????????????????????????????????????????????????????????????? ?Extensions ?namespace?identifier ?n/a ?n/a ?wsdl.extension(namespace, ? ? ?URI ?extension-specific-syntax? ? ?identifier) ? ???????????????????????????????????????????????????????????????????????????????????????????????? Note that the above rules are defined in terms of component properties rather than the XML Infoset representation of the component model. The following sections specify in detail how the pointer parts are constructed from the component model. A.2.1 The Description Component wsdl.description() A.2.2 The Element Declaration Component wsdl.elementDeclaration(element) wsdl.elementDeclaration(element,system) 1. element is the {name} property of the Element Declaration component. 2. system is the absolute URI of the extension type system used for the Element Declaration component. This parameter is absent if XML Schema is the type system. A.2.3 The Type Definition Component wsdl.typeDefinition(type) wsdl.typeDefinition(type,system) 1. type is the {name} property of the Type Definition component. 2. system is the absolute URI of the extension type system used for the Type Definition component. This parameter is absent if XML Schema is the type system. A.2.4 The Interface Component wsdl.interface(interface) 1. interface is the local name of the {name} property of the Interface component. A.2.5 The Interface Fault Component wsdl.interfaceFault(interface/fault) 1. interface is the local name of the {name} property of the parent Interface component. 2. fault is the local name of the {name} property of the Interface Fault component. A.2.6 The Interface Operation Component wsdl.interfaceOperation(interface/operation) 1. interface is the local name of the {name} property of the parent Interface component. 2. operation is the local name of the {name} property of the Interface Operation component. A.2.7 The Interface Message Reference Component wsdl.interfaceMessageReference(interface/operation/message) 1. interface is the local name of the {name} property of the grandparent Interface component. 2. operation is the local name of the {name} property of the parent Interface Operation component. 3. message is the {message label} property of the Interface Message Reference component. A.2.8 The Interface Fault Reference Component wsdl.interfaceFaultReference(interface/operation/message/fault) 1. interface is the local name of the {name} property of the grandparent Interface component. 2. operation is the local name of the {name} property of the parent Interface Operation component. 3. message is the {message label} property of the Interface Fault Reference component. 4. fault is the {name} property of the Interface Fault component referred to by the {interface fault} property of the Interface Fault Reference component. A.2.9 The Binding Component wsdl.binding(binding) 1. binding is the local name of the {name} property of the Binding component. A.2.10 The Binding Fault Component wsdl.bindingFault(binding/fault) 1. binding is the local name of the {name} property of the parent Binding component. 2. fault is the {name} property of the Interface Fault component referred to by the {interface fault} property of the Binding Fault component. A.2.11 The Binding Operation Component wsdl.bindingOperation(binding/operation) 1. binding is the local name of the {name} property of the parent Binding component. 2. operation is the {name} property of the Interface Operation component referred to by the {interface operation} property of the Binding Operation component. A.2.12 The Binding Message Reference Component wsdl.bindingMessageReference(binding/operation/message) 1. binding is the local name of the {name} property of the grandparent Binding component. 2. operation is the {name} property of the Interface Operation component referred to by the {interface operation} property of the parent Binding Operation component. 3. message is the {message label} property of the Interface Message Reference component referred to by the {interface message reference} property of the Binding Message Reference component. A.2.13 The Binding Fault Reference Component wsdl.bindingFaultReference(binding/operation/fault/message) 1. binding is the local name of the {name} property of the grandparent Binding component. 2. operation is the {name} property of the Interface Operation component referred to by the {interface operation} property of the parent Binding Operation component. 3. fault is the {name} property of the Interface Fault component referred to by the {interface fault} property of the Interface Fault Reference component referred to by the {interface fault reference} property of the Binding Fault Reference component. 4. message is the {message label} property of the Interface Fault Reference component referred to by the {interface fault reference } property of the Binding Fault Reference component. A.2.14 The Service Component wsdl.service(service) 1. service is the local name of the {name} property of the Service component. A.2.15 The Endpoint Component wsdl.endpoint(service/endpoint) 1. service is the local name of the {name} property of the parent Service component. 2. endpoint is the {name} property of the Endpoint component. A.2.16 The Feature Component wsdl.feature(parent/feature) 1. parent is the pointer part of the parent component. 2. feature is the {ref} property of the Feature component. A.2.17 The Property Component wsdl.property(parent/property) 1. parent is the pointer part of the parent component. 2. property is the {ref} property of the Property component. A.2.18 Extension Components WSDL 2.0 is extensible and it is possible for an extension to define new components types. The XPointer Framework scheme for extension components is: wsdl.extension(namespace, identifier) 1. namespace is the namespace URI that identifies the extension, e.g. for the WSDL 2.0 SOAP 1.2 Binding the namespace is http:// www.w3.org/2005/08/wsdl/soap. 2. identifier is defined by the extension using a syntax specific to the extension. The owner of the extension must define any components contributed by the extension and a syntax for identifying them. A.3 Security considerations This media type uses the "+xml" convention, it shares the same security considerations as described in [RFC 3023], section 10. Regards, Hugo 1. http://www.w3.org/2002/06/registering-mediatype#Planned 2. http://www.w3.org/2004/02/Process-20040205/tr.html#last-call 3. http://eikenes.alvestrand.no/pipermail/ietf-types/2004-October/000438.html 4. http://www.alvestrand.no/pipermail/ietf-types/2005-February/000595.html 5. http://www.w3.org/TR/2005/WD-wsdl20-20050803/#ietf-draft -- Hugo Haas - W3C mailto:hugo@w3.org - http://www.w3.org/People/Hugo/ -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 307 bytes Desc: Digital signature Url : http://eikenes.alvestrand.no/pipermail/ietf-types/attachments/20050817/3914d65a/attachment-0001.bin >From eburger@brooktrout.com Tue Aug 23 16:55:37 2005 From: eburger at brooktrout.com (Eric Burger) Date: Tue Aug 23 17:07:08 2005 Subject: Registration for application/mediaservercontrol+xml Message-ID: <330A23D8336C0346B5C1A5BB19666647D92FB2@ATLANTIS.Brooktrout.com> This is a request for comments regarding the internet draft draft-vandyke-mscml-06 for media type "application/mediaservercontrol+xml". This media type is for media server control markup language documents. The MSCML specification is located at http://www.ietf.org/internet-drafts/draft-vandyke-mscml-06.txt Thanks. >From magnus.westerlund@ericsson.com Wed Aug 31 12:00:35 2005 From: magnus.westerlund at ericsson.com (Magnus Westerlund) Date: Wed Aug 31 12:26:28 2005 Subject: Request for review of 9 MIME type for 3GPP SA4 Message-ID: <43157FC3.4090809@ericsson.com> Hi, attached is a word document with a proposal for 9 MIME type that will go into the 3GPP Technical Specification 26.346 and when present in that be requested to registered. Most of these media types are for XML formats, although not all of them. Please review them, comments received within a week can be directly addressed at the 3GPP SA4 meeting. TS 26.346 can in its latest form be fetched here: http://www.3gpp.org/ftp/Specs/archive/26_series/26.346/26346-610.zip However some of the references in the chapter relate to text that are being specified and added. They are available in the following document: http://www.3gpp.org/ftp/tsg_sa/WG4_CODEC/TSGS4_36/Docs/S4-050514.zip Thanks Magnus Westerlund Multimedia Technologies, Ericsson Research EAB/TVA/A ---------------------------------------------------------------------- Ericsson AB | Phone +46 8 4048287 Torshamsgatan 23 | Fax +46 8 7575550 S-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com -------------- next part -------------- A non-text attachment was scrubbed... Name: S4-050518-MIME.zip Type: application/zip Size: 28322 bytes Desc: not available Url : http://eikenes.alvestrand.no/pipermail/ietf-types/attachments/20050831/58129d61/S4-050518-MIME-0001.zip >From derhoermi@gmx.net Wed Aug 31 12:50:37 2005 From: derhoermi at gmx.net (Bjoern Hoehrmann) Date: Wed Aug 31 12:56:43 2005 Subject: Request for review of 9 MIME type for 3GPP SA4 In-Reply-To: <43157FC3.4090809@ericsson.com> References: <43157FC3.4090809@ericsson.com> Message-ID: <tm2bh1h7vt6kmj7r81b8v4ocutin43hivn@hive.bjoern.hoehrmann.de> * Magnus Westerlund wrote: >attached is a word document with a proposal for 9 MIME type that will go >into the 3GPP Technical Specification 26.346 and when present in that be >requested to registered. Most of these media types are for XML formats, >although not all of them. > >Please review them, comments received within a week can be directly >addressed at the 3GPP SA4 meeting. "NOTE: The detailed IANA registration information of this content type is tbd." is all I could find with respect to these types. Perhaps the documented is outdated? -- Bj?rn H?hrmann ? mailto:bjoern@hoehrmann.de ? 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 magnus.westerlund@ericsson.com Wed Aug 31 13:18:03 2005 From: magnus.westerlund at ericsson.com (Magnus Westerlund) Date: Wed Aug 31 13:17:55 2005 Subject: Request for review of 9 MIME type for 3GPP SA4 In-Reply-To: <tm2bh1h7vt6kmj7r81b8v4ocutin43hivn@hive.bjoern.hoehrmann.de> References: <43157FC3.4090809@ericsson.com> <tm2bh1h7vt6kmj7r81b8v4ocutin43hivn@hive.bjoern.hoehrmann.de> Message-ID: <431591EB.9020205@ericsson.com> Hi, Please review the proposal in the attached word document in the previous mail as it intended to fix the total lack of MIME type specifications in the referenced 26.346. Cheers Magnus Bjoern Hoehrmann wrote: > * Magnus Westerlund wrote: > >>attached is a word document with a proposal for 9 MIME type that will go >>into the 3GPP Technical Specification 26.346 and when present in that be >>requested to registered. Most of these media types are for XML formats, >>although not all of them. >> >>Please review them, comments received within a week can be directly >>addressed at the 3GPP SA4 meeting. > > > "NOTE: The detailed IANA registration information of this content type > is tbd." is all I could find with respect to these types. Perhaps the > documented is outdated? -- Magnus Westerlund Multimedia Technologies, Ericsson Research EAB/TVA/A ---------------------------------------------------------------------- Ericsson AB | Phone +46 8 4048287 Torshamsgatan 23 | Fax +46 8 7575550 S-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com >From derhoermi@gmx.net Wed Aug 31 14:28:58 2005 From: derhoermi at gmx.net (Bjoern Hoehrmann) Date: Wed Aug 31 14:28:22 2005 Subject: Request for review of 9 MIME type for 3GPP SA4 In-Reply-To: <431591EB.9020205@ericsson.com> References: <43157FC3.4090809@ericsson.com> <tm2bh1h7vt6kmj7r81b8v4ocutin43hivn@hive.bjoern.hoehrmann.de> <431591EB.9020205@ericsson.com> Message-ID: <hq7bh1115ake7c23j2q1epd1r4juk1evn2@hive.bjoern.hoehrmann.de> * Magnus Westerlund wrote: >Please review the proposal in the attached word document in the previous >mail as it intended to fix the total lack of MIME type specifications in >the referenced 26.346. Well, I did, but it seems that this information was added later to the document; not all viewers support such editing information, using more portable formats might be more appropriate here. The +xml types all lack a charset parameter. This is needed to allow general purpose XML applications like Validators to decode the format without hard coded knowledge of the media type. Some of the XML types have encoding considerations like "The content is well formed XML document without any binary parts" which sort of misses the point of the field. These should simply refer to the considerations in RFC 3023. For application/mbms envelope+xml it is unclear what the syntax of the optional parameters is, from the brief description it seems these are meant to be boolean parameters but it's not clear how to specify true or false values. This media format contains XML and may contain binary embedded objects using CDATA sections within the XML. Thus for transports not supporting binary content BASE64 [82] encoding is suitable. This is incorrect, XML documents cannot include binary data, only text. CDATA sections are not exception, they are just concerned with characters that introduce markup like & and <. application/mbms-user-service-description+xml is also a bit unclear about the serviceID parameter, in particular, it is not clear whether a single service identifier must stille be quoted, or if there are constraints about what is a legal identifier for the purposes of the paramter; it should be possible to derive a clear grammar for legal parameter values from the registration. The security considerations are This media format is used to configure the receiver on how to participate in a service. This format is highly suspectible to manipulation or spoofing for attacks desring to misslead a receiver about a session. Both integrity protection and source authentication is recommend to prevent missleading of the receiver. It is unclear how to protect the integrity of such data objects, a brief look at the corresponding schema suggest that e.g. use of XML digital signatures with such content is prohibited. -- Bj?rn H?hrmann ? mailto:bjoern@hoehrmann.de ? 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 magnus.westerlund@ericsson.com Wed Aug 31 15:13:24 2005 From: magnus.westerlund at ericsson.com (Magnus Westerlund) Date: Wed Aug 31 15:13:14 2005 Subject: Request for review of 9 MIME type for 3GPP SA4 In-Reply-To: <hq7bh1115ake7c23j2q1epd1r4juk1evn2@hive.bjoern.hoehrmann.de> References: <43157FC3.4090809@ericsson.com> <tm2bh1h7vt6kmj7r81b8v4ocutin43hivn@hive.bjoern.hoehrmann.de> <431591EB.9020205@ericsson.com> <hq7bh1115ake7c23j2q1epd1r4juk1evn2@hive.bjoern.hoehrmann.de> Message-ID: <4315ACF4.5030808@ericsson.com> Hi Bjoern, Many thanks for the quick review. See inline for comments and answers. I will work on an update and hopefully be able to send it out before we put it into the next version of the TS 26.346. Bjoern Hoehrmann wrote: > * Magnus Westerlund wrote: > >>Please review the proposal in the attached word document in the previous >>mail as it intended to fix the total lack of MIME type specifications in >>the referenced 26.346. > > > Well, I did, but it seems that this information was added later to the > document; not all viewers support such editing information, using more > portable formats might be more appropriate here. Sorry about that, word format with change marks are the by 3GPP required format for contributions. Converting into text would have required me to reformat the sections which wasn't time I like to spend on it. > > The +xml types all lack a charset parameter. This is needed to allow > general purpose XML applications like Validators to decode the format > without hard coded knowledge of the media type. Okay, adding an optional "charset" parameter is not a problem. If I understand this correctly this equals the encoding="UTF-8" attribute in a <?xml version="1"?> line? > > Some of the XML types have encoding considerations like "The content > is well formed XML document without any binary parts" which sort of > misses the point of the field. These should simply refer to the > considerations in RFC 3023. Okay, I will use the "Same as [charset parameter / encoding considerations] of text/xml as specified in RFC 3023." reference sentence. Although I don't think the RFC is easy to use when it comes to referencing it and separating what is for the types registered and what is the general parts. > > For application/mbms envelope+xml it is unclear what the syntax of the > optional parameters is, from the brief description it seems these are > meant to be boolean parameters but it's not clear how to specify true > or false values. They are intended to be boolean thou their presence or absence. > > This media format contains XML and may contain binary embedded > objects using CDATA sections within the XML. Thus for transports > not supporting binary content BASE64 [82] encoding is suitable. > > This is incorrect, XML documents cannot include binary data, only > text. CDATA sections are not exception, they are just concerned with > characters that introduce markup like & and <. Okay, this is something I will have to discuss with the group. I think there is some general lack in the scheme on how to embed files within the envelope. > > application/mbms-user-service-description+xml is also a bit unclear > about the serviceID parameter, in particular, it is not clear whether > a single service identifier must stille be quoted, or if there are > constraints about what is a legal identifier for the purposes of the > paramter; it should be possible to derive a clear grammar for legal > parameter values from the registration. The identifier is defined as "xs:anyURI" which I think is most suitable to always quote even single instances. I will clarify this. > > The security considerations are > > This media format is used to configure the receiver on how to > participate in a service. This format is highly suspectible to > manipulation or spoofing for attacks desring to misslead a receiver > about a session. Both integrity protection and source authentication > is recommend to prevent missleading of the receiver. > > It is unclear how to protect the integrity of such data objects, a > brief look at the corresponding schema suggest that e.g. use of XML > digital signatures with such content is prohibited. This protection is intended to be done through the security mechanisms in MBMS. I don't think using the XML digital signatures has been considered at all. Thanks Magnus Westerlund Multimedia Technologies, Ericsson Research EAB/TVA/A ---------------------------------------------------------------------- Ericsson AB | Phone +46 8 4048287 Torshamsgatan 23 | Fax +46 8 7575550 S-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com >From chris@w3.org Wed Aug 31 16:28:46 2005 From: chris at w3.org (Chris Lilley) Date: Wed Aug 31 16:54:06 2005 Subject: Request for review of 9 MIME type for 3GPP SA4 In-Reply-To: <4315ACF4.5030808@ericsson.com> References: <43157FC3.4090809@ericsson.com> <tm2bh1h7vt6kmj7r81b8v4ocutin43hivn@hive.bjoern.hoehrmann.de> <431591EB.9020205@ericsson.com> <hq7bh1115ake7c23j2q1epd1r4juk1evn2@hive.bjoern.hoehrmann.de> <4315ACF4.5030808@ericsson.com> Message-ID: <1196174337.20050831162846@w3.org> On Wednesday, August 31, 2005, 3:13:24 PM, Magnus wrote: MW> Hi Bjoern, MW> Many thanks for the quick review. See inline for comments and answers. I MW> will work on an update and hopefully be able to send it out before we MW> put it into the next version of the TS 26.346. MW> Bjoern Hoehrmann wrote: >> * Magnus Westerlund wrote: >> >>>Please review the proposal in the attached word document in the previous >>>mail as it intended to fix the total lack of MIME type specifications in >>>the referenced 26.346. >> >> >> Well, I did, but it seems that this information was added later to the >> document; not all viewers support such editing information, using more >> portable formats might be more appropriate here. MW> Sorry about that, word format with change marks are the by 3GPP required MW> format for contributions. Converting into text would have required me to MW> reformat the sections which wasn't time I like to spend on it. Even saving to PDF would have been an improvement there. >> >> The +xml types all lack a charset parameter. This is needed to allow >> general purpose XML applications like Validators to decode the format >> without hard coded knowledge of the media type. MW> Okay, adding an optional "charset" parameter is not a problem. If I MW> understand this correctly this equals the encoding="UTF-8" attribute in MW> a <?xml version="1"?> line? Note that this means that all handsets have to read this charset parameter if present, and use it to override the xml encoding declaration in the document if they differ. This is why some groups prefer to rely entirely on the XML encoding declaration, and under 'parameters' state that there is no charset parameter and that encoding is handled "exactly as per RFC 3023 in the case of a missing charset in application/xml". >> Some of the XML types have encoding considerations like "The content >> is well formed XML document without any binary parts" which sort of >> misses the point of the field. These should simply refer to the >> considerations in RFC 3023. MW> Okay, I will use the "Same as [charset parameter / MW> encoding considerations] of text/xml as specified in RFC 3023." Don't use text/xml as a model. Use application/xml. text/xml is being deprecated as it has a bunch of problems. MW> reference sentence. Although I don't think the RFC is easy to use when MW> it comes to referencing it and separating what is for the types MW> registered and what is the general parts. >> >> For application/mbms envelope+xml it is unclear what the syntax of the >> optional parameters is, from the brief description it seems these are >> meant to be boolean parameters but it's not clear how to specify true >> or false values. MW> They are intended to be boolean thou their presence or absence. Does MIME syntax allow that? >> This media format contains XML and may contain binary embedded >> objects using CDATA sections within the XML. Thus for transports >> not supporting binary content BASE64 [82] encoding is suitable. >> >> This is incorrect, XML documents cannot include binary data, only >> text. CDATA sections are not exception, they are just concerned with >> characters that introduce markup like & and <. MW> Okay, this is something I will have to discuss with the group. I think MW> there is some general lack in the scheme on how to embed files within MW> the envelope. You might want to take a look at XML-binary Optimized Packaging W3C Recommendation 25 January 2005 http://www.w3.org/TR/2005/REC-xop10-20050125/ -- Chris Lilley mailto:chris@w3.org Chair, W3C SVG Working Group W3C Graphics Activity Lead Co-Chair, W3C Hypertext CG