Subject: [admin] Missed spam (was Re: Registration of MIME media type application/ocsp-response
From: distobj at acm.org (Mark Baker)
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 [email-masked]  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: <[email-masked]>

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

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

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

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

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

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

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

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

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:[email-masked]
 Chair, W3C SVG Working Group
 W3C Graphics Activity Lead
 Co-Chair, W3C Hypertext CG

From: jose.kahan at w3.org (Jose Kahan)
Date: Tue Aug 16 19:02:22 2005
Subject: Registration of media type application/xenc+xml
Message-ID: <[email-masked]>

This is a media type registration as defined in Multipurpose Internet
Mail Extensions (MIME) Part Four: Registration Procedures [MIME-REG]
and Media Type Specifications and Registration Procedures
[MEDIA-TYPE-REG].

XML Encryption Syntax and Processing [XML-Encryption] specifies a
process for encrypting data and representing the result in XML. The
data may be arbitrary data (including an XML document), an XML
element, or XML element content. The result of encrypting data is an
XML Encryption element which contains or references the cipher data.

The application/xenc+xml media type allows XML Encryption applications
to identify encrypted documents. Additionally it allows applications
cognizant of this media-type (even if they are not XML Encryption
implementations) to note that the media type of the decrypted
(original) object might be a type other than XML.

---------------

Type name:

    application
     
Subtype name:

    xenc+xml

Required parameters: 

    none.
     
Optional parameters: 

    charset, as defined in section 3.1 of RFC 3023 [XML-MT].

Encoding considerations:

    The encoding considerations are identical to those given 
    for 'application/xml' in section 3.2 of RFC 3023 [XML-MT].

Security considerations:
     
     See section 6 of the [XML-Encryption].

Interoperability considerations: 

     none.

Published specification: 

     [XML-Encryption].

Applications which use this media type:

     XML Encryption is device-, platform-, and vendor-neutral 
     and is supported by a range of Web applications.
     See also section 4 of [XML-Encryption].

Additional information:

     Magic number(s): none

     Although no byte sequences can be counted on to consistently
     identify XML Encryption documents, they will be XML documents in
     which the root element's QName's LocalPart is 'EncryptedData' or
     'EncryptedKey' with an associated namespace name of
     'http://www.w3.org/2001/04/xmlenc#'.  The application/xenc+xml
     type name MUST only be used for data objects in which the root
     element is from the XML Encryption namespace. XML documents which
     contain these element types in places other than the root element
     can be described using facilities such as [XML-schema].

     File extension(s): .xml

     Macintosh file type code(s): "TEXT"

Person & email address to contact for further information:

     [email-masked]
     [email-masked] (public archived mailing 
     list for the XMLENC Recommendation)

Intended usage:

     COMMON

Restrictions on usage:

     none.

Author:
        
     The XML Encryption Recommendation is a work product of the World Wide
     Web Consortium (W3C) and was edited by:

       Donald Eastlake <[email-masked]>
       Joseph Reagle <[email-masked]> 

Change controller:

     The World Wide Web Consortium (W3C) has change control over the 
     XML Encryption Recommendation and its related media types.

References:

[MEDIA-TYPE-REG]
  draft-freed-media-type-reg-05: Media Type Specifications and
  Registration Procedures.  N. Freed, J. Klensin. Internet-Draft, July
  26, 2005.
  http://www.ietf.org/internet-drafts/draft-freed-media-type-reg-05.txt

[MIME-REG]
  draft-freed-mime-p4-07: Multipurpose Internet Mail Extensions (MIME)
  Part Four: Registration Procedures. N. Freed,
  J. Klensin. Internet-Draft, August 5, 2005.
  http://www.ietf.org/internet-drafts/draft-freed-mime-p4-07.txt

[XML-Encryption]
  XML Encryption Syntax and Processing. D. Eastlake and J. Reagle
  (eds). W3C Recommendation, December 2002.
  http://www.w3.org/TR/2002/CR-xmlenc-core-20020802/

[XML-MT]
  RFC 3023: XML Media Types. M. Murata, S. St. Laurent, and D. Kohn.
  Informational, January 2001.  http://www.ietf.org/rfc/rfc2376.txt

[XML-schema]
  XML Schema Part 1: Structures D. Beech, M. Maloney, and N.
  Mendelsohn. W3C Recommendation, May 2001.
  http://www.w3.org/TR/2001/REC-xmlschema-1-20010502/ XML Schema Part
  2: Datatypes. P. Biron and A. Malhotra. W3C Recommendation, May
  2001.  http://www.w3.org/TR/2001/REC-xmlschema-2-20010502/

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
Url : http://eikenes.alvestrand.no/pipermail/ietf-types/attachments/20050816/ba86381e/attachment.bin
>From [email-masked]  Tue Aug 16 19:08:50 2005
From: jose.kahan at w3.org (Jose Kahan)
Date: Tue Aug 16 19:09:08 2005
Subject: Registration of media type application/xenc+xm
Message-ID: <[email-masked]>

(Resending as the previous post failed. Sorry for the duplicate
posting. -jk)

This is a media type registration as defined in Multipurpose Internet
Mail Extensions (MIME) Part Four: Registration Procedures [MIME-REG]
and Media Type Specifications and Registration Procedures
[MEDIA-TYPE-REG].

XML Encryption Syntax and Processing [XML-Encryption] specifies a
process for encrypting data and representing the result in XML. The
data may be arbitrary data (including an XML document), an XML
element, or XML element content. The result of encrypting data is an
XML Encryption element which contains or references the cipher data.

The application/xenc+xml media type allows XML Encryption applications
to identify encrypted documents. Additionally it allows applications
cognizant of this media-type (even if they are not XML Encryption
implementations) to note that the media type of the decrypted
(original) object might be a type other than XML.

---------------

Type name:

    application
     
Subtype name:

    xenc+xml

Required parameters: 

    none.
     
Optional parameters: 

    charset, as defined in section 3.1 of RFC 3023 [XML-MT].

Encoding considerations:

    The encoding considerations are identical to those given 
    for 'application/xml' in section 3.2 of RFC 3023 [XML-MT].

Security considerations:
     
     See section 6 of the [XML-Encryption].

Interoperability considerations: 

     none.

Published specification: 

     [XML-Encryption].

Applications which use this media type:

     XML Encryption is device-, platform-, and vendor-neutral 
     and is supported by a range of Web applications.
     See also section 4 of [XML-Encryption].

Additional information:

     Magic number(s): none

     Although no byte sequences can be counted on to consistently
     identify XML Encryption documents, they will be XML documents in
     which the root element's QName's LocalPart is 'EncryptedData' or
     'EncryptedKey' with an associated namespace name of
     'http://www.w3.org/2001/04/xmlenc#'.  The application/xenc+xml
     type name MUST only be used for data objects in which the root
     element is from the XML Encryption namespace. XML documents which
     contain these element types in places other than the root element
     can be described using facilities such as [XML-schema].

     File extension(s): .xml

     Macintosh file type code(s): "TEXT"

Person & email address to contact for further information:

     [email-masked]
     [email-masked] (public archived mailing 
     list for the XMLENC Recommendation)

Intended usage:

     COMMON

Restrictions on usage:

     none.

Author:
        
     The XML Encryption Recommendation is a work product of the World Wide
     Web Consortium (W3C) and was edited by:

       Donald Eastlake <[email-masked]>
       Joseph Reagle <[email-masked]> 

Change controller:

     The World Wide Web Consortium (W3C) has change control over the 
     XML Encryption Recommendation and its related media types.

References:

[MEDIA-TYPE-REG]
  draft-freed-media-type-reg-05: Media Type Specifications and
  Registration Procedures.  N. Freed, J. Klensin. Internet-Draft, July
  26, 2005.
  http://www.ietf.org/internet-drafts/draft-freed-media-type-reg-05.txt

[MIME-REG]
  draft-freed-mime-p4-07: Multipurpose Internet Mail Extensions (MIME)
  Part Four: Registration Procedures. N. Freed,
  J. Klensin. Internet-Draft, August 5, 2005.
  http://www.ietf.org/internet-drafts/draft-freed-mime-p4-07.txt

[XML-Encryption]
  XML Encryption Syntax and Processing. D. Eastlake and J. Reagle
  (eds). W3C Recommendation, December 2002.
  http://www.w3.org/TR/2002/CR-xmlenc-core-20020802/

[XML-MT]
  RFC 3023: XML Media Types. M. Murata, S. St. Laurent, and D. Kohn.
  Informational, January 2001.  http://www.ietf.org/rfc/rfc2376.txt

[XML-schema]
  XML Schema Part 1: Structures D. Beech, M. Maloney, and N.
  Mendelsohn. W3C Recommendation, May 2001.
  http://www.w3.org/TR/2001/REC-xmlschema-1-20010502/ XML Schema Part
  2: Datatypes. P. Biron and A. Malhotra. W3C Recommendation, May
  2001.  http://www.w3.org/TR/2001/REC-xmlschema-2-20010502/

From: mccobb at us.ibm.com (Gerald McCobb)
Date: Sat Aug 13 00:33:27 2005
Subject: Request for comments regarding draft-mccobb-xv-media-type-00
Message-ID: <[email-masked]>

This is a request for comments regarding the internet draft 
draft-mccobb-xv-media-type-00 for media type "application/xv+xml".
This media type is for XHTML+Voice documents.  The XHTML+Voice 
specification
is located at http://www.voicexml.org/specs/multimodal/x+v/12/ .

Network Working Group                                          G. McCobb
Internet-Draft                                           IBM Corporation
Expires: January 27, 2006                                  July 26, 2005

                    XHTML+Voice - application/xv+xml
                     draft-mccobb-xv-media-type-00

Status of this Memo

   By submitting this Internet-Draft, each author represents that any
   applicable patent or other IPR claims of which he or she is aware
   have been or will be disclosed, and any of which he or she becomes
   aware will be disclosed, in accordance with Section 6 of BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF), its areas, and its working groups.  Note that
   other groups may also distribute working documents as Internet-
   Drafts.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   The list of current Internet-Drafts can be accessed at
   http://www.ietf.org/ietf/1id-abstracts.txt.

   The list of Internet-Draft Shadow Directories can be accessed at
   http://www.ietf.org/shadow.html.

   This Internet-Draft will expire on January 27, 2006.

Copyright Notice

   Copyright (C) The Internet Society (2005).

Abstract

   This document describes the registration of the MIME sub-type
   application/xv+xml.  This sub-type is intended for use as a media
   descriptor for XHTML+Voice multimodal language documents.  The XHTML+
   Voice 1.2 language specification is maintained by the VoiceXML Forum
   at <http://www.voicexml.org/specs/multimodal/x+v/12/>.

McCobb                  Expires January 27, 2006                [Page 1]

Internet-Draft      XHTML+Voice - application/xv+xml           July 2005

1.  Conventions used in this document

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
   document are to be interpreted as described in BCP 14, RFC 2119 [1].

2.  Introduction

   XHTML+Voice is a member of the XHTML family of document types, as
   specified by XHTML Modularization [6].  XHTML+Voice extends XHTML 1.1
   [7] with a modularized subset of VoiceXML 2.0 [11], XML Events [9],
   and a few extensions to both XHTML and VoiceXML 2.0.  XHTML 1.1,
   VoiceXML 2.0 and XML Events are W3C Recommendations.

   The language integration defined by XHTML+Voice supports all modules
   defined by XHTML Modularization, and adds voice interaction to XHTML
   elements to enable multimodal applications.  The defined document
   type for XHTML+Voice is XHTML Host language document type conformant.

   XHTML+Voice 1.2 [10] is maintained by the VoiceXML Forum, at URI
   location <http://www.voicexml.org/specs/multimodal/x+v/12/>.

2.1  application/xv+xml Usage

   The application/xv+xml media type is intended to be a media
   descriptor for XHTML+Voice multimodal documents.  It is used to
   inform applications that additional markup for running a voice
   browser component and activating handlers for DOM Level 2 events via
   XML Events [9] can be processed.

   This media type registration is not intended for e-mail usage.

3.  IANA Registration

      To: [email-masked]
      Subject: Registration of MIME media type
               application/xv+xml

      MIME media type name: application

      MIME subtype name: xv+xml

      Required parameters: none

      Optional parameters:

      charset: has the same semantics as the charset parameter of the
      "application/xml" media type specified in [3].

McCobb                  Expires January 27, 2006                [Page 2]

Internet-Draft      XHTML+Voice - application/xv+xml           July 2005

   Encoding considerations:

      XHTML+Voice has the same media type encoding considerations
      specified in section 3.2 of [3].

   Security considerations:

      XHTML+Voice is an extension of XHTML and has the same security
      issues as XHTML.  These include interpreting anchors and forms in
      XHTML documents, and scripting languages and other dynamic
      interactive capabilities.  See section 7 of [4].

      In addition, the scripting language can be accessed by both the
      XHTML and the VoiceXML 2.0 markup embedded in the XHTML+Voice
      document.  See section 1.3.1.5 of [10].

      XML-Events [9] allows an author to attach a handler to any node in
      the document.  The handler that is activated in response to a
      specified event may be either a voice dialog or a script that can
      be either in the same or an external document.

   Interoperability considerations:

      Because XHTML+Voice is built upon W3C standard recommendations, it
      is designed to be interoperable across a wide range of platforms
      and client devices.  Because the extensions to XHTML are
      identified by their namespaces, all browsers that have namespace
      support can run an XHTML+Voice document as an XHTML document
      without voice interaction.

   Published specification:

      The latest published version of XHTML+Voice is [10].

   Applications which use this media type:

      XHTML+Voice documents are intended to be deployed on the World
      Wide Web and rendered by multimodal browsers that support the
      visual and voice modes of interaction.  Because XHTML+Voice is an
      application of XML, authors can expect XHTML+Voice user agents to
      be conformant XML 1.0 [5] processors.  See section 2 of [4].

   Additional information:

      Magic number(s):  There is no single string that is always
      present.

      File extension(s):  mxml, xhvml, xvml, xvm

      Macintosh File Type Code(s):  TEXT

McCobb                  Expires January 27, 2006                [Page 3]

Internet-Draft      XHTML+Voice - application/xv+xml           July 2005

   Person & e-mail address to contact for further information:

      Gerald McCobb
      [email-masked]

   Intended usage:  LIMITED USE

   Author/Change controller:  Gerald McCobb

   Further information:

4.  Fragment Identifiers

   See section 3 of [4].  Following [4], fragment identifiers for XHTML+
   Voice documents designate the element with the corresponding ID
   attribute value (see [5] section 3.3.1).

   While XHTML+Voice adds new ID attributes with fragment identifier
   namespaces that are not in the same namespace as XHTML, uniqueness of
   the ID attribute values is preserved within the document.  See
   sections 1.3.1 and 5.3 of [10].

5.  Recognizing XHTML+Voice files

   Because XHTML+Voice is XML, an XHTML+Voice document [optionally]
   starts with an XML declaration which begins with "<?xml" and has a
   DOCTYPE declaration "<!DOCTYPE html".  XHTML+Voice 1.2 has the
   following DOCTYPE declaration:

   <!DOCTYPE html PUBLIC "-//VoiceXML Forum//DTD XHTML+Voice 1.2//EN"
 "http://www.voicexml.org/specs/multimodal/x+v/12/dtd/xhtml+voice12.dtd">

   Because XHTML+Voice is in the XHTML family of languages, the root
   element of an XHTML+Voice document is 'html' and '<html' can be found
   near the top of the document.

6.  Security Considerations

   Security considerations for this media type are discussed in the MIME
   type registration that appears in section 3.

McCobb                  Expires January 27, 2006                [Page 4]

Internet-Draft      XHTML+Voice - application/xv+xml           July 2005

7.  IANA Considerations

   As described in Section 3, this document specifies the registration
   of a MIME type for XHTML+Voice documents according to [3].

8.  Normative References

   [1]   Bradner, S., "Key words for use in RFCs to Indicate Requirement
         Levels, BCP 14", RFC 2119, March 1997.

   [2]   Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform
         Resource Identifiers (URI): Generic Syntax", RFC 2396,
         August 1998.

   [3]   Murata, M., St. Laurent, S., and D. Kohn, "XML Media Types",
         RFC 3023, January 2001.

   [4]   Baker, M. and P. Stark, "The 'application/xhtml+xml' Media
         Type", RFC 3236, January 2002.

   [5]   Bray, T. and others, "Extensible Markup Language (XML) 1.0, W3C
         Recommendation, http://www.w3.org/TR/REC-xml", February 2004.

   [6]   Dooley, S. and others, "Modularization of XHTML, W3C
         Recommendation, http://www.w3.org/TR/xhtml-modularization",
         April 2001.

   [7]   Altheim, M. and S. McCarron, "XHTML 1.1 - Module-based XHTML,
         W3C Recommendation, http://www.w3.org/TR/xhtml11/", May 2001.

   [8]   Pixley, T., "Document Object Model Level 2 Events
         Specification, W3C Recommendation,
         http://www.w3.org/TR/DOM-Level-2-Events/", November 2000.

   [9]   Pemberton, S., Raman, T., and S. McCarron, "XML Events - An
         events syntax for XML, W3C Recommendation,
         http://www.w3.org/TR/xml-events/", January 2002.

   [10]  Axelsson, J. and others, "XHTML+Voice Profile 1.2,
         http://www.voicexml.org/specs/multimodal/x+v/12/", March 2004.

   [11]  McGlashan, S. and others, "Voice Extensible Markup Language
         (VoiceXML), W3C Recommendation,
         http://www.w3.org/TR/voicexml20/", March 2004.

McCobb                  Expires January 27, 2006                [Page 5]

Internet-Draft      XHTML+Voice - application/xv+xml           July 2005

Author's Address

   Gerald McCobb
   International Business Machines Corporation
   8051 Congress Ave.
   Boca Raton, FL  33487
   USA

   Phone: +1 561 862 2109
   Email: [email-masked]

Intellectual Property Statement

   The IETF takes no position regarding the validity or scope of any
   Intellectual Property Rights or other rights that might be claimed to
   pertain to the implementation or use of the technology described in
   this document or the extent to which any license under such rights
   might or might not be available; nor does it represent that it has
   made any independent effort to identify any such rights.  Information
   on the procedures with respect to rights in RFC documents can be
   found in BCP 78 and BCP 79.

   Copies of IPR disclosures made to the IETF Secretariat and any
   assurances of licenses to be made available, or the result of an
   attempt made to obtain a general license or permission for the use of
   such proprietary rights by implementers or users of this
   specification can be obtained from the IETF on-line IPR repository at
   http://www.ietf.org/ipr.

   The IETF invites any interested party to bring to its attention any
   copyrights, patents or patent applications, or other proprietary
   rights that may cover technology that may be required to implement
   this standard.  Please address the information to the IETF at
   [email-masked].

Disclaimer of Validity

   This document and the information contained herein are provided on an
   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
   ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
   INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
   INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
   WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

McCobb                  Expires January 27, 2006                [Page 6]

Internet-Draft      XHTML+Voice - application/xv+xml           July 2005

Copyright Statement

   Copyright (C) The Internet Society (2005).  This document is subject
   to the rights, licenses and restrictions contained in BCP 78, and
   except as set forth therein, the authors retain all their rights.

Acknowledgment

   Funding for the RFC Editor function is currently provided by the
   Internet Society.

McCobb                  Expires January 27, 2006                [Page 7]

Regards,
Gerald McCobb
IBM
8051 Congress Avenue
Boca Raton, FL 33487
Tel. # 561-862-2109 T/L 975-2109
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://eikenes.alvestrand.no/pipermail/ietf-types/attachments/20050812/527cfbd9/attachment-0001.html
>From [email-masked]  Mon Aug 15 13:23:59 2005
From: 210313041 at suda.edu.cn (DCY)
Date: Tue Aug 16 19:02:21 2005
Subject: Registration of MIME media type application/ocsp-response 
Message-ID: <[email-masked]>

aWV0Zi10eXBlc6OsxPq6w6OhDQoNCgkNCg0KoaGhoaGhoaGhoaGhoaGhodbCDQrA8aOhDQogCQkJ
CQ0KDQqhoaGhoaGhoaGhoaGhoaGhRENZDQqhoaGhoaGhoaGhoaGhoaGhMjEwMzEzMDQxQHN1ZGEu
ZWR1LmNuDQqhoaGhoaGhoaGhoaGhoaGhoaGhoTIwMDUtMDQtMTkNCg==

From: derhoermi at gmx.net (Bjoern Hoehrmann)
Date: Tue Aug  2 10:14:21 2005
Subject: Registration of media type application/xhtml-voice+xml
In-Reply-To: <[email-masked]>
References: <[email-masked]> <[email-masked]>
Message-ID: <[email-masked]>

* Gerald McCobb wrote:
>XHTML+Voice adds the voice mode of interaction to web applications.  This
>additional mode of interaction is not that important for desktop clients.
>Voice Interaction is useful for clients with limited processing, memory,
>and network resources, such as cell phones and wireless PDAs.  For clients
>that don't accept XHTML+Voice markup it matters whether it has to receive
>and ignore additional markup.  For these clients it is important that
>applications send markup dedicated to what they support.

Well, application/xhtml+xml has a profile parameter to indicate
specific profiles such as XHTML+Voice; why is a new XHTML+Voice
media type preferable here?
-- 
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 Aug  3 13:14:49 2005
From: jax at opera.com (Jonny Axelsson)
Date: Sat Aug  6 16:36:15 2005
Subject: Registration of media type application/xhtml-voice+xml
In-Reply-To: <[email-masked]>
References: <[email-masked]>
	<[email-masked]>
	<[email-masked]>
Message-ID: <[email-masked]>

On Tue, 02 Aug 2005 10:14:02 +0200, Bjoern Hoehrmann <[email-masked]>  
wrote:

> Well, application/xhtml+xml has a profile parameter to indicate
> specific profiles such as XHTML+Voice; why is a new XHTML+Voice
> media type preferable here?

This is only semi-related to this question, but profile parameters are  
unreliable. OMA did something similar with a Mobile Profile of XHTML (an  
almost pure subset of XHTML), using the XHTML content type. As a  
consequence we tested parameters and found them somewhat unreliable. I  
don't remember the details but clients didn't always lop the parameters  
off, servers didn't always serve them.

I guess this just goes to show that if a feature is unused long enough  
interoperability suffers (that it is unused may also indicate that this  
wasn't such a good idea but that is another debate).

-- 
Jonny Axelsson, Core Technology, Opera Software ASA
>From [email-masked]  Sun Aug  7 01:53:33 2005
From: mankin at psg.com (Allison Mankin)
Date: Sun Aug  7 01:59:32 2005
Subject: Transport Area requests Media Type review for
	application/poc-settings+xml
Message-ID: <[email-masked]>

The Transport Area requests a Media Type review for the proposed new
media type application/poc-settings+xml, intended for the standards tree,
and specified in 
http://www.ietf.org/internet-drafts/draft-garcia-sipping-poc-isb-am-03.txt

The document has completed an RFC 3427 review by the SIPPING WG.

Please provide any comments before August 22.

Thanks,

Allison

From: distobj at acm.org (Mark Baker)
Date: Tue Aug 16 19:28:44 2005
Subject: [admin] Missed spam (was Re: Registration of MIME media type application/ocsp-response
In-Reply-To: <[email-masked]>
References: <[email-masked]>
Message-ID: <[email-masked]>

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

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

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

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

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

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

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

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

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

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:[email-masked]
 Chair, W3C SVG Working Group
 W3C Graphics Activity Lead
 Co-Chair, W3C Hypertext CG

From: jose.kahan at w3.org (Jose Kahan)
Date: Tue Aug 16 19:02:22 2005
Subject: Registration of media type application/xenc+xml
Message-ID: <[email-masked]>

This is a media type registration as defined in Multipurpose Internet
Mail Extensions (MIME) Part Four: Registration Procedures [MIME-REG]
and Media Type Specifications and Registration Procedures
[MEDIA-TYPE-REG].

XML Encryption Syntax and Processing [XML-Encryption] specifies a
process for encrypting data and representing the result in XML. The
data may be arbitrary data (including an XML document), an XML
element, or XML element content. The result of encrypting data is an
XML Encryption element which contains or references the cipher data.

The application/xenc+xml media type allows XML Encryption applications
to identify encrypted documents. Additionally it allows applications
cognizant of this media-type (even if they are not XML Encryption
implementations) to note that the media type of the decrypted
(original) object might be a type other than XML.

---------------

Type name:

    application
     
Subtype name:

    xenc+xml

Required parameters: 

    none.
     
Optional parameters: 

    charset, as defined in section 3.1 of RFC 3023 [XML-MT].

Encoding considerations:

    The encoding considerations are identical to those given 
    for 'application/xml' in section 3.2 of RFC 3023 [XML-MT].

Security considerations:
     
     See section 6 of the [XML-Encryption].

Interoperability considerations: 

     none.

Published specification: 

     [XML-Encryption].

Applications which use this media type:

     XML Encryption is device-, platform-, and vendor-neutral 
     and is supported by a range of Web applications.
     See also section 4 of [XML-Encryption].

Additional information:

     Magic number(s): none

     Although no byte sequences can be counted on to consistently
     identify XML Encryption documents, they will be XML documents in
     which the root element's QName's LocalPart is 'EncryptedData' or
     'EncryptedKey' with an associated namespace name of
     'http://www.w3.org/2001/04/xmlenc#'.  The application/xenc+xml
     type name MUST only be used for data objects in which the root
     element is from the XML Encryption namespace. XML documents which
     contain these element types in places other than the root element
     can be described using facilities such as [XML-schema].

     File extension(s): .xml

     Macintosh file type code(s): "TEXT"

Person & email address to contact for further information:

     [email-masked]
     [email-masked] (public archived mailing 
     list for the XMLENC Recommendation)

Intended usage:

     COMMON

Restrictions on usage:

     none.

Author:
        
     The XML Encryption Recommendation is a work product of the World Wide
     Web Consortium (W3C) and was edited by:

       Donald Eastlake <[email-masked]>
       Joseph Reagle <[email-masked]> 

Change controller:

     The World Wide Web Consortium (W3C) has change control over the 
     XML Encryption Recommendation and its related media types.

References:

[MEDIA-TYPE-REG]
  draft-freed-media-type-reg-05: Media Type Specifications and
  Registration Procedures.  N. Freed, J. Klensin. Internet-Draft, July
  26, 2005.
  http://www.ietf.org/internet-drafts/draft-freed-media-type-reg-05.txt

[MIME-REG]
  draft-freed-mime-p4-07: Multipurpose Internet Mail Extensions (MIME)
  Part Four: Registration Procedures. N. Freed,
  J. Klensin. Internet-Draft, August 5, 2005.
  http://www.ietf.org/internet-drafts/draft-freed-mime-p4-07.txt

[XML-Encryption]
  XML Encryption Syntax and Processing. D. Eastlake and J. Reagle
  (eds). W3C Recommendation, December 2002.
  http://www.w3.org/TR/2002/CR-xmlenc-core-20020802/

[XML-MT]
  RFC 3023: XML Media Types. M. Murata, S. St. Laurent, and D. Kohn.
  Informational, January 2001.  http://www.ietf.org/rfc/rfc2376.txt

[XML-schema]
  XML Schema Part 1: Structures D. Beech, M. Maloney, and N.
  Mendelsohn. W3C Recommendation, May 2001.
  http://www.w3.org/TR/2001/REC-xmlschema-1-20010502/ XML Schema Part
  2: Datatypes. P. Biron and A. Malhotra. W3C Recommendation, May
  2001.  http://www.w3.org/TR/2001/REC-xmlschema-2-20010502/

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
Url : http://eikenes.alvestrand.no/pipermail/ietf-types/attachments/20050816/ba86381e/attachment.bin
>From [email-masked]  Tue Aug 16 19:08:50 2005
From: jose.kahan at w3.org (Jose Kahan)
Date: Tue Aug 16 19:09:08 2005
Subject: Registration of media type application/xenc+xm
Message-ID: <[email-masked]>

(Resending as the previous post failed. Sorry for the duplicate
posting. -jk)

This is a media type registration as defined in Multipurpose Internet
Mail Extensions (MIME) Part Four: Registration Procedures [MIME-REG]
and Media Type Specifications and Registration Procedures
[MEDIA-TYPE-REG].

XML Encryption Syntax and Processing [XML-Encryption] specifies a
process for encrypting data and representing the result in XML. The
data may be arbitrary data (including an XML document), an XML
element, or XML element content. The result of encrypting data is an
XML Encryption element which contains or references the cipher data.

The application/xenc+xml media type allows XML Encryption applications
to identify encrypted documents. Additionally it allows applications
cognizant of this media-type (even if they are not XML Encryption
implementations) to note that the media type of the decrypted
(original) object might be a type other than XML.

---------------

Type name:

    application
     
Subtype name:

    xenc+xml

Required parameters: 

    none.
     
Optional parameters: 

    charset, as defined in section 3.1 of RFC 3023 [XML-MT].

Encoding considerations:

    The encoding considerations are identical to those given 
    for 'application/xml' in section 3.2 of RFC 3023 [XML-MT].

Security considerations:
     
     See section 6 of the [XML-Encryption].

Interoperability considerations: 

     none.

Published specification: 

     [XML-Encryption].

Applications which use this media type:

     XML Encryption is device-, platform-, and vendor-neutral 
     and is supported by a range of Web applications.
     See also section 4 of [XML-Encryption].

Additional information:

     Magic number(s): none

     Although no byte sequences can be counted on to consistently
     identify XML Encryption documents, they will be XML documents in
     which the root element's QName's LocalPart is 'EncryptedData' or
     'EncryptedKey' with an associated namespace name of
     'http://www.w3.org/2001/04/xmlenc#'.  The application/xenc+xml
     type name MUST only be used for data objects in which the root
     element is from the XML Encryption namespace. XML documents which
     contain these element types in places other than the root element
     can be described using facilities such as [XML-schema].

     File extension(s): .xml

     Macintosh file type code(s): "TEXT"

Person & email address to contact for further information:

     [email-masked]
     [email-masked] (public archived mailing 
     list for the XMLENC Recommendation)

Intended usage:

     COMMON

Restrictions on usage:

     none.

Author:
        
     The XML Encryption Recommendation is a work product of the World Wide
     Web Consortium (W3C) and was edited by:

       Donald Eastlake <[email-masked]>
       Joseph Reagle <[email-masked]> 

Change controller:

     The World Wide Web Consortium (W3C) has change control over the 
     XML Encryption Recommendation and its related media types.

References:

[MEDIA-TYPE-REG]
  draft-freed-media-type-reg-05: Media Type Specifications and
  Registration Procedures.  N. Freed, J. Klensin. Internet-Draft, July
  26, 2005.
  http://www.ietf.org/internet-drafts/draft-freed-media-type-reg-05.txt

[MIME-REG]
  draft-freed-mime-p4-07: Multipurpose Internet Mail Extensions (MIME)
  Part Four: Registration Procedures. N. Freed,
  J. Klensin. Internet-Draft, August 5, 2005.
  http://www.ietf.org/internet-drafts/draft-freed-mime-p4-07.txt

[XML-Encryption]
  XML Encryption Syntax and Processing. D. Eastlake and J. Reagle
  (eds). W3C Recommendation, December 2002.
  http://www.w3.org/TR/2002/CR-xmlenc-core-20020802/

[XML-MT]
  RFC 3023: XML Media Types. M. Murata, S. St. Laurent, and D. Kohn.
  Informational, January 2001.  http://www.ietf.org/rfc/rfc2376.txt

[XML-schema]
  XML Schema Part 1: Structures D. Beech, M. Maloney, and N.
  Mendelsohn. W3C Recommendation, May 2001.
  http://www.w3.org/TR/2001/REC-xmlschema-1-20010502/ XML Schema Part
  2: Datatypes. P. Biron and A. Malhotra. W3C Recommendation, May
  2001.  http://www.w3.org/TR/2001/REC-xmlschema-2-20010502/

From: mccobb at us.ibm.com (Gerald McCobb)
Date: Sat Aug 13 00:33:27 2005
Subject: Request for comments regarding draft-mccobb-xv-media-type-00
Message-ID: <[email-masked]>

This is a request for comments regarding the internet draft 
draft-mccobb-xv-media-type-00 for media type "application/xv+xml".
This media type is for XHTML+Voice documents.  The XHTML+Voice 
specification
is located at http://www.voicexml.org/specs/multimodal/x+v/12/ .

Network Working Group                                          G. McCobb
Internet-Draft                                           IBM Corporation
Expires: January 27, 2006                                  July 26, 2005

                    XHTML+Voice - application/xv+xml
                     draft-mccobb-xv-media-type-00

Status of this Memo

   By submitting this Internet-Draft, each author represents that any
   applicable patent or other IPR claims of which he or she is aware
   have been or will be disclosed, and any of which he or she becomes
   aware will be disclosed, in accordance with Section 6 of BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF), its areas, and its working groups.  Note that
   other groups may also distribute working documents as Internet-
   Drafts.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   The list of current Internet-Drafts can be accessed at
   http://www.ietf.org/ietf/1id-abstracts.txt.

   The list of Internet-Draft Shadow Directories can be accessed at
   http://www.ietf.org/shadow.html.

   This Internet-Draft will expire on January 27, 2006.

Copyright Notice

   Copyright (C) The Internet Society (2005).

Abstract

   This document describes the registration of the MIME sub-type
   application/xv+xml.  This sub-type is intended for use as a media
   descriptor for XHTML+Voice multimodal language documents.  The XHTML+
   Voice 1.2 language specification is maintained by the VoiceXML Forum
   at <http://www.voicexml.org/specs/multimodal/x+v/12/>.

McCobb                  Expires January 27, 2006                [Page 1]

Internet-Draft      XHTML+Voice - application/xv+xml           July 2005

1.  Conventions used in this document

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
   document are to be interpreted as described in BCP 14, RFC 2119 [1].

2.  Introduction

   XHTML+Voice is a member of the XHTML family of document types, as
   specified by XHTML Modularization [6].  XHTML+Voice extends XHTML 1.1
   [7] with a modularized subset of VoiceXML 2.0 [11], XML Events [9],
   and a few extensions to both XHTML and VoiceXML 2.0.  XHTML 1.1,
   VoiceXML 2.0 and XML Events are W3C Recommendations.

   The language integration defined by XHTML+Voice supports all modules
   defined by XHTML Modularization, and adds voice interaction to XHTML
   elements to enable multimodal applications.  The defined document
   type for XHTML+Voice is XHTML Host language document type conformant.

   XHTML+Voice 1.2 [10] is maintained by the VoiceXML Forum, at URI
   location <http://www.voicexml.org/specs/multimodal/x+v/12/>.

2.1  application/xv+xml Usage

   The application/xv+xml media type is intended to be a media
   descriptor for XHTML+Voice multimodal documents.  It is used to
   inform applications that additional markup for running a voice
   browser component and activating handlers for DOM Level 2 events via
   XML Events [9] can be processed.

   This media type registration is not intended for e-mail usage.

3.  IANA Registration

      To: [email-masked]
      Subject: Registration of MIME media type
               application/xv+xml

      MIME media type name: application

      MIME subtype name: xv+xml

      Required parameters: none

      Optional parameters:

      charset: has the same semantics as the charset parameter of the
      "application/xml" media type specified in [3].

McCobb                  Expires January 27, 2006                [Page 2]

Internet-Draft      XHTML+Voice - application/xv+xml           July 2005

   Encoding considerations:

      XHTML+Voice has the same media type encoding considerations
      specified in section 3.2 of [3].

   Security considerations:

      XHTML+Voice is an extension of XHTML and has the same security
      issues as XHTML.  These include interpreting anchors and forms in
      XHTML documents, and scripting languages and other dynamic
      interactive capabilities.  See section 7 of [4].

      In addition, the scripting language can be accessed by both the
      XHTML and the VoiceXML 2.0 markup embedded in the XHTML+Voice
      document.  See section 1.3.1.5 of [10].

      XML-Events [9] allows an author to attach a handler to any node in
      the document.  The handler that is activated in response to a
      specified event may be either a voice dialog or a script that can
      be either in the same or an external document.

   Interoperability considerations:

      Because XHTML+Voice is built upon W3C standard recommendations, it
      is designed to be interoperable across a wide range of platforms
      and client devices.  Because the extensions to XHTML are
      identified by their namespaces, all browsers that have namespace
      support can run an XHTML+Voice document as an XHTML document
      without voice interaction.

   Published specification:

      The latest published version of XHTML+Voice is [10].

   Applications which use this media type:

      XHTML+Voice documents are intended to be deployed on the World
      Wide Web and rendered by multimodal browsers that support the
      visual and voice modes of interaction.  Because XHTML+Voice is an
      application of XML, authors can expect XHTML+Voice user agents to
      be conformant XML 1.0 [5] processors.  See section 2 of [4].

   Additional information:

      Magic number(s):  There is no single string that is always
      present.

      File extension(s):  mxml, xhvml, xvml, xvm

      Macintosh File Type Code(s):  TEXT

McCobb                  Expires January 27, 2006                [Page 3]

Internet-Draft      XHTML+Voice - application/xv+xml           July 2005

   Person & e-mail address to contact for further information:

      Gerald McCobb
      [email-masked]

   Intended usage:  LIMITED USE

   Author/Change controller:  Gerald McCobb

   Further information:

4.  Fragment Identifiers

   See section 3 of [4].  Following [4], fragment identifiers for XHTML+
   Voice documents designate the element with the corresponding ID
   attribute value (see [5] section 3.3.1).

   While XHTML+Voice adds new ID attributes with fragment identifier
   namespaces that are not in the same namespace as XHTML, uniqueness of
   the ID attribute values is preserved within the document.  See
   sections 1.3.1 and 5.3 of [10].

5.  Recognizing XHTML+Voice files

   Because XHTML+Voice is XML, an XHTML+Voice document [optionally]
   starts with an XML declaration which begins with "<?xml" and has a
   DOCTYPE declaration "<!DOCTYPE html".  XHTML+Voice 1.2 has the
   following DOCTYPE declaration:

   <!DOCTYPE html PUBLIC "-//VoiceXML Forum//DTD XHTML+Voice 1.2//EN"
 "http://www.voicexml.org/specs/multimodal/x+v/12/dtd/xhtml+voice12.dtd">

   Because XHTML+Voice is in the XHTML family of languages, the root
   element of an XHTML+Voice document is 'html' and '<html' can be found
   near the top of the document.

6.  Security Considerations

   Security considerations for this media type are discussed in the MIME
   type registration that appears in section 3.

McCobb                  Expires January 27, 2006                [Page 4]

Internet-Draft      XHTML+Voice - application/xv+xml           July 2005

7.  IANA Considerations

   As described in Section 3, this document specifies the registration
   of a MIME type for XHTML+Voice documents according to [3].

8.  Normative References

   [1]   Bradner, S., "Key words for use in RFCs to Indicate Requirement
         Levels, BCP 14", RFC 2119, March 1997.

   [2]   Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform
         Resource Identifiers (URI): Generic Syntax", RFC 2396,
         August 1998.

   [3]   Murata, M., St. Laurent, S., and D. Kohn, "XML Media Types",
         RFC 3023, January 2001.

   [4]   Baker, M. and P. Stark, "The 'application/xhtml+xml' Media
         Type", RFC 3236, January 2002.

   [5]   Bray, T. and others, "Extensible Markup Language (XML) 1.0, W3C
         Recommendation, http://www.w3.org/TR/REC-xml", February 2004.

   [6]   Dooley, S. and others, "Modularization of XHTML, W3C
         Recommendation, http://www.w3.org/TR/xhtml-modularization",
         April 2001.

   [7]   Altheim, M. and S. McCarron, "XHTML 1.1 - Module-based XHTML,
         W3C Recommendation, http://www.w3.org/TR/xhtml11/", May 2001.

   [8]   Pixley, T., "Document Object Model Level 2 Events
         Specification, W3C Recommendation,
         http://www.w3.org/TR/DOM-Level-2-Events/", November 2000.

   [9]   Pemberton, S., Raman, T., and S. McCarron, "XML Events - An
         events syntax for XML, W3C Recommendation,
         http://www.w3.org/TR/xml-events/", January 2002.

   [10]  Axelsson, J. and others, "XHTML+Voice Profile 1.2,
         http://www.voicexml.org/specs/multimodal/x+v/12/", March 2004.

   [11]  McGlashan, S. and others, "Voice Extensible Markup Language
         (VoiceXML), W3C Recommendation,
         http://www.w3.org/TR/voicexml20/", March 2004.

McCobb                  Expires January 27, 2006                [Page 5]

Internet-Draft      XHTML+Voice - application/xv+xml           July 2005

Author's Address

   Gerald McCobb
   International Business Machines Corporation
   8051 Congress Ave.
   Boca Raton, FL  33487
   USA

   Phone: +1 561 862 2109
   Email: [email-masked]

Intellectual Property Statement

   The IETF takes no position regarding the validity or scope of any
   Intellectual Property Rights or other rights that might be claimed to
   pertain to the implementation or use of the technology described in
   this document or the extent to which any license under such rights
   might or might not be available; nor does it represent that it has
   made any independent effort to identify any such rights.  Information
   on the procedures with respect to rights in RFC documents can be
   found in BCP 78 and BCP 79.

   Copies of IPR disclosures made to the IETF Secretariat and any
   assurances of licenses to be made available, or the result of an
   attempt made to obtain a general license or permission for the use of
   such proprietary rights by implementers or users of this
   specification can be obtained from the IETF on-line IPR repository at
   http://www.ietf.org/ipr.

   The IETF invites any interested party to bring to its attention any
   copyrights, patents or patent applications, or other proprietary
   rights that may cover technology that may be required to implement
   this standard.  Please address the information to the IETF at
   [email-masked].

Disclaimer of Validity

   This document and the information contained herein are provided on an
   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
   ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
   INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
   INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
   WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

McCobb                  Expires January 27, 2006                [Page 6]

Internet-Draft      XHTML+Voice - application/xv+xml           July 2005

Copyright Statement

   Copyright (C) The Internet Society (2005).  This document is subject
   to the rights, licenses and restrictions contained in BCP 78, and
   except as set forth therein, the authors retain all their rights.

Acknowledgment

   Funding for the RFC Editor function is currently provided by the
   Internet Society.

McCobb                  Expires January 27, 2006                [Page 7]

Regards,
Gerald McCobb
IBM
8051 Congress Avenue
Boca Raton, FL 33487
Tel. # 561-862-2109 T/L 975-2109
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://eikenes.alvestrand.no/pipermail/ietf-types/attachments/20050812/527cfbd9/attachment-0001.html
>From [email-masked]  Mon Aug 15 13:23:59 2005
From: 210313041 at suda.edu.cn (DCY)
Date: Tue Aug 16 19:02:21 2005
Subject: Registration of MIME media type application/ocsp-response 
Message-ID: <[email-masked]>

aWV0Zi10eXBlc6OsxPq6w6OhDQoNCgkNCg0KoaGhoaGhoaGhoaGhoaGhodbCDQrA8aOhDQogCQkJ
CQ0KDQqhoaGhoaGhoaGhoaGhoaGhRENZDQqhoaGhoaGhoaGhoaGhoaGhMjEwMzEzMDQxQHN1ZGEu
ZWR1LmNuDQqhoaGhoaGhoaGhoaGhoaGhoaGhoTIwMDUtMDQtMTkNCg==

From: derhoermi at gmx.net (Bjoern Hoehrmann)
Date: Tue Aug  2 10:14:21 2005
Subject: Registration of media type application/xhtml-voice+xml
In-Reply-To: <[email-masked]>
References: <[email-masked]> <[email-masked]>
Message-ID: <[email-masked]>

* Gerald McCobb wrote:
>XHTML+Voice adds the voice mode of interaction to web applications.  This
>additional mode of interaction is not that important for desktop clients.
>Voice Interaction is useful for clients with limited processing, memory,
>and network resources, such as cell phones and wireless PDAs.  For clients
>that don't accept XHTML+Voice markup it matters whether it has to receive
>and ignore additional markup.  For these clients it is important that
>applications send markup dedicated to what they support.

Well, application/xhtml+xml has a profile parameter to indicate
specific profiles such as XHTML+Voice; why is a new XHTML+Voice
media type preferable here?
-- 
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 Aug  3 13:14:49 2005
From: jax at opera.com (Jonny Axelsson)
Date: Sat Aug  6 16:36:15 2005
Subject: Registration of media type application/xhtml-voice+xml
In-Reply-To: <[email-masked]>
References: <[email-masked]>
	<[email-masked]>
	<[email-masked]>
Message-ID: <[email-masked]>

On Tue, 02 Aug 2005 10:14:02 +0200, Bjoern Hoehrmann <[email-masked]>  
wrote:

> Well, application/xhtml+xml has a profile parameter to indicate
> specific profiles such as XHTML+Voice; why is a new XHTML+Voice
> media type preferable here?

This is only semi-related to this question, but profile parameters are  
unreliable. OMA did something similar with a Mobile Profile of XHTML (an  
almost pure subset of XHTML), using the XHTML content type. As a  
consequence we tested parameters and found them somewhat unreliable. I  
don't remember the details but clients didn't always lop the parameters  
off, servers didn't always serve them.

I guess this just goes to show that if a feature is unused long enough  
interoperability suffers (that it is unused may also indicate that this  
wasn't such a good idea but that is another debate).

-- 
Jonny Axelsson, Core Technology, Opera Software ASA
>From [email-masked]  Sun Aug  7 01:53:33 2005
From: mankin at psg.com (Allison Mankin)
Date: Sun Aug  7 01:59:32 2005
Subject: Transport Area requests Media Type review for
	application/poc-settings+xml
Message-ID: <[email-masked]>

The Transport Area requests a Media Type review for the proposed new
media type application/poc-settings+xml, intended for the standards tree,
and specified in 
http://www.ietf.org/internet-drafts/draft-garcia-sipping-poc-isb-am-03.txt

The document has completed an RFC 3427 review by the SIPPING WG.

Please provide any comments before August 22.

Thanks,

Allison

From: distobj at acm.org (Mark Baker)
Date: Tue Aug 16 19:28:44 2005
Subject: [admin] Missed spam (was Re: Registration of MIME media type application/ocsp-response
In-Reply-To: <[email-masked]>
References: <[email-masked]>
Message-ID: <[email-masked]>

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

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

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

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

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

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

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

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

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

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:[email-masked]
 Chair, W3C SVG Working Group
 W3C Graphics Activity Lead
 Co-Chair, W3C Hypertext CG

From: jose.kahan at w3.org (Jose Kahan)
Date: Tue Aug 16 19:02:22 2005
Subject: Registration of media type application/xenc+xml
Message-ID: <[email-masked]>

This is a media type registration as defined in Multipurpose Internet
Mail Extensions (MIME) Part Four: Registration Procedures [MIME-REG]
and Media Type Specifications and Registration Procedures
[MEDIA-TYPE-REG].

XML Encryption Syntax and Processing [XML-Encryption] specifies a
process for encrypting data and representing the result in XML. The
data may be arbitrary data (including an XML document), an XML
element, or XML element content. The result of encrypting data is an
XML Encryption element which contains or references the cipher data.

The application/xenc+xml media type allows XML Encryption applications
to identify encrypted documents. Additionally it allows applications
cognizant of this media-type (even if they are not XML Encryption
implementations) to note that the media type of the decrypted
(original) object might be a type other than XML.

---------------

Type name:

    application
     
Subtype name:

    xenc+xml

Required parameters: 

    none.
     
Optional parameters: 

    charset, as defined in section 3.1 of RFC 3023 [XML-MT].

Encoding considerations:

    The encoding considerations are identical to those given 
    for 'application/xml' in section 3.2 of RFC 3023 [XML-MT].

Security considerations:
     
     See section 6 of the [XML-Encryption].

Interoperability considerations: 

     none.

Published specification: 

     [XML-Encryption].

Applications which use this media type:

     XML Encryption is device-, platform-, and vendor-neutral 
     and is supported by a range of Web applications.
     See also section 4 of [XML-Encryption].

Additional information:

     Magic number(s): none

     Although no byte sequences can be counted on to consistently
     identify XML Encryption documents, they will be XML documents in
     which the root element's QName's LocalPart is 'EncryptedData' or
     'EncryptedKey' with an associated namespace name of
     'http://www.w3.org/2001/04/xmlenc#'.  The application/xenc+xml
     type name MUST only be used for data objects in which the root
     element is from the XML Encryption namespace. XML documents which
     contain these element types in places other than the root element
     can be described using facilities such as [XML-schema].

     File extension(s): .xml

     Macintosh file type code(s): "TEXT"

Person & email address to contact for further information:

     [email-masked]
     [email-masked] (public archived mailing 
     list for the XMLENC Recommendation)

Intended usage:

     COMMON

Restrictions on usage:

     none.

Author:
        
     The XML Encryption Recommendation is a work product of the World Wide
     Web Consortium (W3C) and was edited by:

       Donald Eastlake <[email-masked]>
       Joseph Reagle <[email-masked]> 

Change controller:

     The World Wide Web Consortium (W3C) has change control over the 
     XML Encryption Recommendation and its related media types.

References:

[MEDIA-TYPE-REG]
  draft-freed-media-type-reg-05: Media Type Specifications and
  Registration Procedures.  N. Freed, J. Klensin. Internet-Draft, July
  26, 2005.
  http://www.ietf.org/internet-drafts/draft-freed-media-type-reg-05.txt

[MIME-REG]
  draft-freed-mime-p4-07: Multipurpose Internet Mail Extensions (MIME)
  Part Four: Registration Procedures. N. Freed,
  J. Klensin. Internet-Draft, August 5, 2005.
  http://www.ietf.org/internet-drafts/draft-freed-mime-p4-07.txt

[XML-Encryption]
  XML Encryption Syntax and Processing. D. Eastlake and J. Reagle
  (eds). W3C Recommendation, December 2002.
  http://www.w3.org/TR/2002/CR-xmlenc-core-20020802/

[XML-MT]
  RFC 3023: XML Media Types. M. Murata, S. St. Laurent, and D. Kohn.
  Informational, January 2001.  http://www.ietf.org/rfc/rfc2376.txt

[XML-schema]
  XML Schema Part 1: Structures D. Beech, M. Maloney, and N.
  Mendelsohn. W3C Recommendation, May 2001.
  http://www.w3.org/TR/2001/REC-xmlschema-1-20010502/ XML Schema Part
  2: Datatypes. P. Biron and A. Malhotra. W3C Recommendation, May
  2001.  http://www.w3.org/TR/2001/REC-xmlschema-2-20010502/

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
Url : http://eikenes.alvestrand.no/pipermail/ietf-types/attachments/20050816/ba86381e/attachment.bin
>From [email-masked]  Tue Aug 16 19:08:50 2005
From: jose.kahan at w3.org (Jose Kahan)
Date: Tue Aug 16 19:09:08 2005
Subject: Registration of media type application/xenc+xm
Message-ID: <[email-masked]>

(Resending as the previous post failed. Sorry for the duplicate
posting. -jk)

This is a media type registration as defined in Multipurpose Internet
Mail Extensions (MIME) Part Four: Registration Procedures [MIME-REG]
and Media Type Specifications and Registration Procedures
[MEDIA-TYPE-REG].

XML Encryption Syntax and Processing [XML-Encryption] specifies a
process for encrypting data and representing the result in XML. The
data may be arbitrary data (including an XML document), an XML
element, or XML element content. The result of encrypting data is an
XML Encryption element which contains or references the cipher data.

The application/xenc+xml media type allows XML Encryption applications
to identify encrypted documents. Additionally it allows applications
cognizant of this media-type (even if they are not XML Encryption
implementations) to note that the media type of the decrypted
(original) object might be a type other than XML.

---------------

Type name:

    application
     
Subtype name:

    xenc+xml

Required parameters: 

    none.
     
Optional parameters: 

    charset, as defined in section 3.1 of RFC 3023 [XML-MT].

Encoding considerations:

    The encoding considerations are identical to those given 
    for 'application/xml' in section 3.2 of RFC 3023 [XML-MT].

Security considerations:
     
     See section 6 of the [XML-Encryption].

Interoperability considerations: 

     none.

Published specification: 

     [XML-Encryption].

Applications which use this media type:

     XML Encryption is device-, platform-, and vendor-neutral 
     and is supported by a range of Web applications.
     See also section 4 of [XML-Encryption].

Additional information:

     Magic number(s): none

     Although no byte sequences can be counted on to consistently
     identify XML Encryption documents, they will be XML documents in
     which the root element's QName's LocalPart is 'EncryptedData' or
     'EncryptedKey' with an associated namespace name of
     'http://www.w3.org/2001/04/xmlenc#'.  The application/xenc+xml
     type name MUST only be used for data objects in which the root
     element is from the XML Encryption namespace. XML documents which
     contain these element types in places other than the root element
     can be described using facilities such as [XML-schema].

     File extension(s): .xml

     Macintosh file type code(s): "TEXT"

Person & email address to contact for further information:

     [email-masked]
     [email-masked] (public archived mailing 
     list for the XMLENC Recommendation)

Intended usage:

     COMMON

Restrictions on usage:

     none.

Author:
        
     The XML Encryption Recommendation is a work product of the World Wide
     Web Consortium (W3C) and was edited by:

       Donald Eastlake <[email-masked]>
       Joseph Reagle <[email-masked]> 

Change controller:

     The World Wide Web Consortium (W3C) has change control over the 
     XML Encryption Recommendation and its related media types.

References:

[MEDIA-TYPE-REG]
  draft-freed-media-type-reg-05: Media Type Specifications and
  Registration Procedures.  N. Freed, J. Klensin. Internet-Draft, July
  26, 2005.
  http://www.ietf.org/internet-drafts/draft-freed-media-type-reg-05.txt

[MIME-REG]
  draft-freed-mime-p4-07: Multipurpose Internet Mail Extensions (MIME)
  Part Four: Registration Procedures. N. Freed,
  J. Klensin. Internet-Draft, August 5, 2005.
  http://www.ietf.org/internet-drafts/draft-freed-mime-p4-07.txt

[XML-Encryption]
  XML Encryption Syntax and Processing. D. Eastlake and J. Reagle
  (eds). W3C Recommendation, December 2002.
  http://www.w3.org/TR/2002/CR-xmlenc-core-20020802/

[XML-MT]
  RFC 3023: XML Media Types. M. Murata, S. St. Laurent, and D. Kohn.
  Informational, January 2001.  http://www.ietf.org/rfc/rfc2376.txt

[XML-schema]
  XML Schema Part 1: Structures D. Beech, M. Maloney, and N.
  Mendelsohn. W3C Recommendation, May 2001.
  http://www.w3.org/TR/2001/REC-xmlschema-1-20010502/ XML Schema Part
  2: Datatypes. P. Biron and A. Malhotra. W3C Recommendation, May
  2001.  http://www.w3.org/TR/2001/REC-xmlschema-2-20010502/

From: mccobb at us.ibm.com (Gerald McCobb)
Date: Sat Aug 13 00:33:27 2005
Subject: Request for comments regarding draft-mccobb-xv-media-type-00
Message-ID: <[email-masked]>

This is a request for comments regarding the internet draft 
draft-mccobb-xv-media-type-00 for media type "application/xv+xml".
This media type is for XHTML+Voice documents.  The XHTML+Voice 
specification
is located at http://www.voicexml.org/specs/multimodal/x+v/12/ .

Network Working Group                                          G. McCobb
Internet-Draft                                           IBM Corporation
Expires: January 27, 2006                                  July 26, 2005

                    XHTML+Voice - application/xv+xml
                     draft-mccobb-xv-media-type-00

Status of this Memo

   By submitting this Internet-Draft, each author represents that any
   applicable patent or other IPR claims of which he or she is aware
   have been or will be disclosed, and any of which he or she becomes
   aware will be disclosed, in accordance with Section 6 of BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF), its areas, and its working groups.  Note that
   other groups may also distribute working documents as Internet-
   Drafts.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   The list of current Internet-Drafts can be accessed at
   http://www.ietf.org/ietf/1id-abstracts.txt.

   The list of Internet-Draft Shadow Directories can be accessed at
   http://www.ietf.org/shadow.html.

   This Internet-Draft will expire on January 27, 2006.

Copyright Notice

   Copyright (C) The Internet Society (2005).

Abstract

   This document describes the registration of the MIME sub-type
   application/xv+xml.  This sub-type is intended for use as a media
   descriptor for XHTML+Voice multimodal language documents.  The XHTML+
   Voice 1.2 language specification is maintained by the VoiceXML Forum
   at <http://www.voicexml.org/specs/multimodal/x+v/12/>.

McCobb                  Expires January 27, 2006                [Page 1]

Internet-Draft      XHTML+Voice - application/xv+xml           July 2005

1.  Conventions used in this document

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
   document are to be interpreted as described in BCP 14, RFC 2119 [1].

2.  Introduction

   XHTML+Voice is a member of the XHTML family of document types, as
   specified by XHTML Modularization [6].  XHTML+Voice extends XHTML 1.1
   [7] with a modularized subset of VoiceXML 2.0 [11], XML Events [9],
   and a few extensions to both XHTML and VoiceXML 2.0.  XHTML 1.1,
   VoiceXML 2.0 and XML Events are W3C Recommendations.

   The language integration defined by XHTML+Voice supports all modules
   defined by XHTML Modularization, and adds voice interaction to XHTML
   elements to enable multimodal applications.  The defined document
   type for XHTML+Voice is XHTML Host language document type conformant.

   XHTML+Voice 1.2 [10] is maintained by the VoiceXML Forum, at URI
   location <http://www.voicexml.org/specs/multimodal/x+v/12/>.

2.1  application/xv+xml Usage

   The application/xv+xml media type is intended to be a media
   descriptor for XHTML+Voice multimodal documents.  It is used to
   inform applications that additional markup for running a voice
   browser component and activating handlers for DOM Level 2 events via
   XML Events [9] can be processed.

   This media type registration is not intended for e-mail usage.

3.  IANA Registration

      To: [email-masked]
      Subject: Registration of MIME media type
               application/xv+xml

      MIME media type name: application

      MIME subtype name: xv+xml

      Required parameters: none

      Optional parameters:

      charset: has the same semantics as the charset parameter of the
      "application/xml" media type specified in [3].

McCobb                  Expires January 27, 2006                [Page 2]

Internet-Draft      XHTML+Voice - application/xv+xml           July 2005

   Encoding considerations:

      XHTML+Voice has the same media type encoding considerations
      specified in section 3.2 of [3].

   Security considerations:

      XHTML+Voice is an extension of XHTML and has the same security
      issues as XHTML.  These include interpreting anchors and forms in
      XHTML documents, and scripting languages and other dynamic
      interactive capabilities.  See section 7 of [4].

      In addition, the scripting language can be accessed by both the
      XHTML and the VoiceXML 2.0 markup embedded in the XHTML+Voice
      document.  See section 1.3.1.5 of [10].

      XML-Events [9] allows an author to attach a handler to any node in
      the document.  The handler that is activated in response to a
      specified event may be either a voice dialog or a script that can
      be either in the same or an external document.

   Interoperability considerations:

      Because XHTML+Voice is built upon W3C standard recommendations, it
      is designed to be interoperable across a wide range of platforms
      and client devices.  Because the extensions to XHTML are
      identified by their namespaces, all browsers that have namespace
      support can run an XHTML+Voice document as an XHTML document
      without voice interaction.

   Published specification:

      The latest published version of XHTML+Voice is [10].

   Applications which use this media type:

      XHTML+Voice documents are intended to be deployed on the World
      Wide Web and rendered by multimodal browsers that support the
      visual and voice modes of interaction.  Because XHTML+Voice is an
      application of XML, authors can expect XHTML+Voice user agents to
      be conformant XML 1.0 [5] processors.  See section 2 of [4].

   Additional information:

      Magic number(s):  There is no single string that is always
      present.

      File extension(s):  mxml, xhvml, xvml, xvm

      Macintosh File Type Code(s):  TEXT

McCobb                  Expires January 27, 2006                [Page 3]

Internet-Draft      XHTML+Voice - application/xv+xml           July 2005

   Person & e-mail address to contact for further information:

      Gerald McCobb
      [email-masked]

   Intended usage:  LIMITED USE

   Author/Change controller:  Gerald McCobb

   Further information:

4.  Fragment Identifiers

   See section 3 of [4].  Following [4], fragment identifiers for XHTML+
   Voice documents designate the element with the corresponding ID
   attribute value (see [5] section 3.3.1).

   While XHTML+Voice adds new ID attributes with fragment identifier
   namespaces that are not in the same namespace as XHTML, uniqueness of
   the ID attribute values is preserved within the document.  See
   sections 1.3.1 and 5.3 of [10].

5.  Recognizing XHTML+Voice files

   Because XHTML+Voice is XML, an XHTML+Voice document [optionally]
   starts with an XML declaration which begins with "<?xml" and has a
   DOCTYPE declaration "<!DOCTYPE html".  XHTML+Voice 1.2 has the
   following DOCTYPE declaration:

   <!DOCTYPE html PUBLIC "-//VoiceXML Forum//DTD XHTML+Voice 1.2//EN"
 "http://www.voicexml.org/specs/multimodal/x+v/12/dtd/xhtml+voice12.dtd">

   Because XHTML+Voice is in the XHTML family of languages, the root
   element of an XHTML+Voice document is 'html' and '<html' can be found
   near the top of the document.

6.  Security Considerations

   Security considerations for this media type are discussed in the MIME
   type registration that appears in section 3.

McCobb                  Expires January 27, 2006                [Page 4]

Internet-Draft      XHTML+Voice - application/xv+xml           July 2005

7.  IANA Considerations

   As described in Section 3, this document specifies the registration
   of a MIME type for XHTML+Voice documents according to [3].

8.  Normative References

   [1]   Bradner, S., "Key words for use in RFCs to Indicate Requirement
         Levels, BCP 14", RFC 2119, March 1997.

   [2]   Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform
         Resource Identifiers (URI): Generic Syntax", RFC 2396,
         August 1998.

   [3]   Murata, M., St. Laurent, S., and D. Kohn, "XML Media Types",
         RFC 3023, January 2001.

   [4]   Baker, M. and P. Stark, "The 'application/xhtml+xml' Media
         Type", RFC 3236, January 2002.

   [5]   Bray, T. and others, "Extensible Markup Language (XML) 1.0, W3C
         Recommendation, http://www.w3.org/TR/REC-xml", February 2004.

   [6]   Dooley, S. and others, "Modularization of XHTML, W3C
         Recommendation, http://www.w3.org/TR/xhtml-modularization",
         April 2001.

   [7]   Altheim, M. and S. McCarron, "XHTML 1.1 - Module-based XHTML,
         W3C Recommendation, http://www.w3.org/TR/xhtml11/", May 2001.

   [8]   Pixley, T., "Document Object Model Level 2 Events
         Specification, W3C Recommendation,
         http://www.w3.org/TR/DOM-Level-2-Events/", November 2000.

   [9]   Pemberton, S., Raman, T., and S. McCarron, "XML Events - An
         events syntax for XML, W3C Recommendation,
         http://www.w3.org/TR/xml-events/", January 2002.

   [10]  Axelsson, J. and others, "XHTML+Voice Profile 1.2,
         http://www.voicexml.org/specs/multimodal/x+v/12/", March 2004.

   [11]  McGlashan, S. and others, "Voice Extensible Markup Language
         (VoiceXML), W3C Recommendation,
         http://www.w3.org/TR/voicexml20/", March 2004.

McCobb                  Expires January 27, 2006                [Page 5]

Internet-Draft      XHTML+Voice - application/xv+xml           July 2005

Author's Address

   Gerald McCobb
   International Business Machines Corporation
   8051 Congress Ave.
   Boca Raton, FL  33487
   USA

   Phone: +1 561 862 2109
   Email: [email-masked]

Intellectual Property Statement

   The IETF takes no position regarding the validity or scope of any
   Intellectual Property Rights or other rights that might be claimed to
   pertain to the implementation or use of the technology described in
   this document or the extent to which any license under such rights
   might or might not be available; nor does it represent that it has
   made any independent effort to identify any such rights.  Information
   on the procedures with respect to rights in RFC documents can be
   found in BCP 78 and BCP 79.

   Copies of IPR disclosures made to the IETF Secretariat and any
   assurances of licenses to be made available, or the result of an
   attempt made to obtain a general license or permission for the use of
   such proprietary rights by implementers or users of this
   specification can be obtained from the IETF on-line IPR repository at
   http://www.ietf.org/ipr.

   The IETF invites any interested party to bring to its attention any
   copyrights, patents or patent applications, or other proprietary
   rights that may cover technology that may be required to implement
   this standard.  Please address the information to the IETF at
   [email-masked].

Disclaimer of Validity

   This document and the information contained herein are provided on an
   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
   ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
   INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
   INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
   WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

McCobb                  Expires January 27, 2006                [Page 6]

Internet-Draft      XHTML+Voice - application/xv+xml           July 2005

Copyright Statement

   Copyright (C) The Internet Society (2005).  This document is subject
   to the rights, licenses and restrictions contained in BCP 78, and
   except as set forth therein, the authors retain all their rights.

Acknowledgment

   Funding for the RFC Editor function is currently provided by the
   Internet Society.

McCobb                  Expires January 27, 2006                [Page 7]

Regards,
Gerald McCobb
IBM
8051 Congress Avenue
Boca Raton, FL 33487
Tel. # 561-862-2109 T/L 975-2109
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://eikenes.alvestrand.no/pipermail/ietf-types/attachments/20050812/527cfbd9/attachment-0001.html
>From [email-masked]  Mon Aug 15 13:23:59 2005
From: 210313041 at suda.edu.cn (DCY)
Date: Tue Aug 16 19:02:21 2005
Subject: Registration of MIME media type application/ocsp-response 
Message-ID: <[email-masked]>

aWV0Zi10eXBlc6OsxPq6w6OhDQoNCgkNCg0KoaGhoaGhoaGhoaGhoaGhodbCDQrA8aOhDQogCQkJ
CQ0KDQqhoaGhoaGhoaGhoaGhoaGhRENZDQqhoaGhoaGhoaGhoaGhoaGhMjEwMzEzMDQxQHN1ZGEu
ZWR1LmNuDQqhoaGhoaGhoaGhoaGhoaGhoaGhoTIwMDUtMDQtMTkNCg==

From: derhoermi at gmx.net (Bjoern Hoehrmann)
Date: Tue Aug  2 10:14:21 2005
Subject: Registration of media type application/xhtml-voice+xml
In-Reply-To: <[email-masked]>
References: <[email-masked]> <[email-masked]>
Message-ID: <[email-masked]>

* Gerald McCobb wrote:
>XHTML+Voice adds the voice mode of interaction to web applications.  This
>additional mode of interaction is not that important for desktop clients.
>Voice Interaction is useful for clients with limited processing, memory,
>and network resources, such as cell phones and wireless PDAs.  For clients
>that don't accept XHTML+Voice markup it matters whether it has to receive
>and ignore additional markup.  For these clients it is important that
>applications send markup dedicated to what they support.

Well, application/xhtml+xml has a profile parameter to indicate
specific profiles such as XHTML+Voice; why is a new XHTML+Voice
media type preferable here?
-- 
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 Aug  3 13:14:49 2005
From: jax at opera.com (Jonny Axelsson)
Date: Sat Aug  6 16:36:15 2005
Subject: Registration of media type application/xhtml-voice+xml
In-Reply-To: <[email-masked]>
References: <[email-masked]>
	<[email-masked]>
	<[email-masked]>
Message-ID: <[email-masked]>

On Tue, 02 Aug 2005 10:14:02 +0200, Bjoern Hoehrmann <[email-masked]>  
wrote:

> Well, application/xhtml+xml has a profile parameter to indicate
> specific profiles such as XHTML+Voice; why is a new XHTML+Voice
> media type preferable here?

This is only semi-related to this question, but profile parameters are  
unreliable. OMA did something similar with a Mobile Profile of XHTML (an  
almost pure subset of XHTML), using the XHTML content type. As a  
consequence we tested parameters and found them somewhat unreliable. I  
don't remember the details but clients didn't always lop the parameters  
off, servers didn't always serve them.

I guess this just goes to show that if a feature is unused long enough  
interoperability suffers (that it is unused may also indicate that this  
wasn't such a good idea but that is another debate).

-- 
Jonny Axelsson, Core Technology, Opera Software ASA
>From [email-masked]  Sun Aug  7 01:53:33 2005
From: mankin at psg.com (Allison Mankin)
Date: Sun Aug  7 01:59:32 2005
Subject: Transport Area requests Media Type review for
	application/poc-settings+xml
Message-ID: <[email-masked]>

The Transport Area requests a Media Type review for the proposed new
media type application/poc-settings+xml, intended for the standards tree,
and specified in 
http://www.ietf.org/internet-drafts/draft-garcia-sipping-poc-isb-am-03.txt

The document has completed an RFC 3427 review by the SIPPING WG.

Please provide any comments before August 22.

Thanks,

Allison

From: distobj at acm.org (Mark Baker)
Date: Tue Aug 16 19:28:44 2005
Subject: [admin] Missed spam (was Re: Registration of MIME media type application/ocsp-response
In-Reply-To: <[email-masked]>
References: <[email-masked]>
Message-ID: <[email-masked]>

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

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

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

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

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

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

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

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

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

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:[email-masked]
 Chair, W3C SVG Working Group
 W3C Graphics Activity Lead
 Co-Chair, W3C Hypertext CG

From: jose.kahan at w3.org (Jose Kahan)
Date: Tue Aug 16 19:02:22 2005
Subject: Registration of media type application/xenc+xml
Message-ID: <[email-masked]>

This is a media type registration as defined in Multipurpose Internet
Mail Extensions (MIME) Part Four: Registration Procedures [MIME-REG]
and Media Type Specifications and Registration Procedures
[MEDIA-TYPE-REG].

XML Encryption Syntax and Processing [XML-Encryption] specifies a
process for encrypting data and representing the result in XML. The
data may be arbitrary data (including an XML document), an XML
element, or XML element content. The result of encrypting data is an
XML Encryption element which contains or references the cipher data.

The application/xenc+xml media type allows XML Encryption applications
to identify encrypted documents. Additionally it allows applications
cognizant of this media-type (even if they are not XML Encryption
implementations) to note that the media type of the decrypted
(original) object might be a type other than XML.

---------------

Type name:

    application
     
Subtype name:

    xenc+xml

Required parameters: 

    none.
     
Optional parameters: 

    charset, as defined in section 3.1 of RFC 3023 [XML-MT].

Encoding considerations:

    The encoding considerations are identical to those given 
    for 'application/xml' in section 3.2 of RFC 3023 [XML-MT].

Security considerations:
     
     See section 6 of the [XML-Encryption].

Interoperability considerations: 

     none.

Published specification: 

     [XML-Encryption].

Applications which use this media type:

     XML Encryption is device-, platform-, and vendor-neutral 
     and is supported by a range of Web applications.
     See also section 4 of [XML-Encryption].

Additional information:

     Magic number(s): none

     Although no byte sequences can be counted on to consistently
     identify XML Encryption documents, they will be XML documents in
     which the root element's QName's LocalPart is 'EncryptedData' or
     'EncryptedKey' with an associated namespace name of
     'http://www.w3.org/2001/04/xmlenc#'.  The application/xenc+xml
     type name MUST only be used for data objects in which the root
     element is from the XML Encryption namespace. XML documents which
     contain these element types in places other than the root element
     can be described using facilities such as [XML-schema].

     File extension(s): .xml

     Macintosh file type code(s): "TEXT"

Person & email address to contact for further information:

     [email-masked]
     [email-masked] (public archived mailing 
     list for the XMLENC Recommendation)

Intended usage:

     COMMON

Restrictions on usage:

     none.

Author:
        
     The XML Encryption Recommendation is a work product of the World Wide
     Web Consortium (W3C) and was edited by:

       Donald Eastlake <[email-masked]>
       Joseph Reagle <[email-masked]> 

Change controller:

     The World Wide Web Consortium (W3C) has change control over the 
     XML Encryption Recommendation and its related media types.

References:

[MEDIA-TYPE-REG]
  draft-freed-media-type-reg-05: Media Type Specifications and
  Registration Procedures.  N. Freed, J. Klensin. Internet-Draft, July
  26, 2005.
  http://www.ietf.org/internet-drafts/draft-freed-media-type-reg-05.txt

[MIME-REG]
  draft-freed-mime-p4-07: Multipurpose Internet Mail Extensions (MIME)
  Part Four: Registration Procedures. N. Freed,
  J. Klensin. Internet-Draft, August 5, 2005.
  http://www.ietf.org/internet-drafts/draft-freed-mime-p4-07.txt

[XML-Encryption]
  XML Encryption Syntax and Processing. D. Eastlake and J. Reagle
  (eds). W3C Recommendation, December 2002.
  http://www.w3.org/TR/2002/CR-xmlenc-core-20020802/

[XML-MT]
  RFC 3023: XML Media Types. M. Murata, S. St. Laurent, and D. Kohn.
  Informational, January 2001.  http://www.ietf.org/rfc/rfc2376.txt

[XML-schema]
  XML Schema Part 1: Structures D. Beech, M. Maloney, and N.
  Mendelsohn. W3C Recommendation, May 2001.
  http://www.w3.org/TR/2001/REC-xmlschema-1-20010502/ XML Schema Part
  2: Datatypes. P. Biron and A. Malhotra. W3C Recommendation, May
  2001.  http://www.w3.org/TR/2001/REC-xmlschema-2-20010502/

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
Url : http://eikenes.alvestrand.no/pipermail/ietf-types/attachments/20050816/ba86381e/attachment.bin
>From [email-masked]  Tue Aug 16 19:08:50 2005
From: jose.kahan at w3.org (Jose Kahan)
Date: Tue Aug 16 19:09:08 2005
Subject: Registration of media type application/xenc+xm
Message-ID: <[email-masked]>

(Resending as the previous post failed. Sorry for the duplicate
posting. -jk)

This is a media type registration as defined in Multipurpose Internet
Mail Extensions (MIME) Part Four: Registration Procedures [MIME-REG]
and Media Type Specifications and Registration Procedures
[MEDIA-TYPE-REG].

XML Encryption Syntax and Processing [XML-Encryption] specifies a
process for encrypting data and representing the result in XML. The
data may be arbitrary data (including an XML document), an XML
element, or XML element content. The result of encrypting data is an
XML Encryption element which contains or references the cipher data.

The application/xenc+xml media type allows XML Encryption applications
to identify encrypted documents. Additionally it allows applications
cognizant of this media-type (even if they are not XML Encryption
implementations) to note that the media type of the decrypted
(original) object might be a type other than XML.

---------------

Type name:

    application
     
Subtype name:

    xenc+xml

Required parameters: 

    none.
     
Optional parameters: 

    charset, as defined in section 3.1 of RFC 3023 [XML-MT].

Encoding considerations:

    The encoding considerations are identical to those given 
    for 'application/xml' in section 3.2 of RFC 3023 [XML-MT].

Security considerations:
     
     See section 6 of the [XML-Encryption].

Interoperability considerations: 

     none.

Published specification: 

     [XML-Encryption].

Applications which use this media type:

     XML Encryption is device-, platform-, and vendor-neutral 
     and is supported by a range of Web applications.
     See also section 4 of [XML-Encryption].

Additional information:

     Magic number(s): none

     Although no byte sequences can be counted on to consistently
     identify XML Encryption documents, they will be XML documents in
     which the root element's QName's LocalPart is 'EncryptedData' or
     'EncryptedKey' with an associated namespace name of
     'http://www.w3.org/2001/04/xmlenc#'.  The application/xenc+xml
     type name MUST only be used for data objects in which the root
     element is from the XML Encryption namespace. XML documents which
     contain these element types in places other than the root element
     can be described using facilities such as [XML-schema].

     File extension(s): .xml

     Macintosh file type code(s): "TEXT"

Person & email address to contact for further information:

     [email-masked]
     [email-masked] (public archived mailing 
     list for the XMLENC Recommendation)

Intended usage:

     COMMON

Restrictions on usage:

     none.

Author:
        
     The XML Encryption Recommendation is a work product of the World Wide
     Web Consortium (W3C) and was edited by:

       Donald Eastlake <[email-masked]>
       Joseph Reagle <[email-masked]> 

Change controller:

     The World Wide Web Consortium (W3C) has change control over the 
     XML Encryption Recommendation and its related media types.

References:

[MEDIA-TYPE-REG]
  draft-freed-media-type-reg-05: Media Type Specifications and
  Registration Procedures.  N. Freed, J. Klensin. Internet-Draft, July
  26, 2005.
  http://www.ietf.org/internet-drafts/draft-freed-media-type-reg-05.txt

[MIME-REG]
  draft-freed-mime-p4-07: Multipurpose Internet Mail Extensions (MIME)
  Part Four: Registration Procedures. N. Freed,
  J. Klensin. Internet-Draft, August 5, 2005.
  http://www.ietf.org/internet-drafts/draft-freed-mime-p4-07.txt

[XML-Encryption]
  XML Encryption Syntax and Processing. D. Eastlake and J. Reagle
  (eds). W3C Recommendation, December 2002.
  http://www.w3.org/TR/2002/CR-xmlenc-core-20020802/

[XML-MT]
  RFC 3023: XML Media Types. M. Murata, S. St. Laurent, and D. Kohn.
  Informational, January 2001.  http://www.ietf.org/rfc/rfc2376.txt

[XML-schema]
  XML Schema Part 1: Structures D. Beech, M. Maloney, and N.
  Mendelsohn. W3C Recommendation, May 2001.
  http://www.w3.org/TR/2001/REC-xmlschema-1-20010502/ XML Schema Part
  2: Datatypes. P. Biron and A. Malhotra. W3C Recommendation, May
  2001.  http://www.w3.org/TR/2001/REC-xmlschema-2-20010502/

From: mccobb at us.ibm.com (Gerald McCobb)
Date: Sat Aug 13 00:33:27 2005
Subject: Request for comments regarding draft-mccobb-xv-media-type-00
Message-ID: <[email-masked]>

This is a request for comments regarding the internet draft 
draft-mccobb-xv-media-type-00 for media type "application/xv+xml".
This media type is for XHTML+Voice documents.  The XHTML+Voice 
specification
is located at http://www.voicexml.org/specs/multimodal/x+v/12/ .

Network Working Group                                          G. McCobb
Internet-Draft                                           IBM Corporation
Expires: January 27, 2006                                  July 26, 2005

                    XHTML+Voice - application/xv+xml
                     draft-mccobb-xv-media-type-00

Status of this Memo

   By submitting this Internet-Draft, each author represents that any
   applicable patent or other IPR claims of which he or she is aware
   have been or will be disclosed, and any of which he or she becomes
   aware will be disclosed, in accordance with Section 6 of BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF), its areas, and its working groups.  Note that
   other groups may also distribute working documents as Internet-
   Drafts.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   The list of current Internet-Drafts can be accessed at
   http://www.ietf.org/ietf/1id-abstracts.txt.

   The list of Internet-Draft Shadow Directories can be accessed at
   http://www.ietf.org/shadow.html.

   This Internet-Draft will expire on January 27, 2006.

Copyright Notice

   Copyright (C) The Internet Society (2005).

Abstract

   This document describes the registration of the MIME sub-type
   application/xv+xml.  This sub-type is intended for use as a media
   descriptor for XHTML+Voice multimodal language documents.  The XHTML+
   Voice 1.2 language specification is maintained by the VoiceXML Forum
   at <http://www.voicexml.org/specs/multimodal/x+v/12/>.

McCobb                  Expires January 27, 2006                [Page 1]

Internet-Draft      XHTML+Voice - application/xv+xml           July 2005

1.  Conventions used in this document

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
   document are to be interpreted as described in BCP 14, RFC 2119 [1].

2.  Introduction

   XHTML+Voice is a member of the XHTML family of document types, as
   specified by XHTML Modularization [6].  XHTML+Voice extends XHTML 1.1
   [7] with a modularized subset of VoiceXML 2.0 [11], XML Events [9],
   and a few extensions to both XHTML and VoiceXML 2.0.  XHTML 1.1,
   VoiceXML 2.0 and XML Events are W3C Recommendations.

   The language integration defined by XHTML+Voice supports all modules
   defined by XHTML Modularization, and adds voice interaction to XHTML
   elements to enable multimodal applications.  The defined document
   type for XHTML+Voice is XHTML Host language document type conformant.

   XHTML+Voice 1.2 [10] is maintained by the VoiceXML Forum, at URI
   location <http://www.voicexml.org/specs/multimodal/x+v/12/>.

2.1  application/xv+xml Usage

   The application/xv+xml media type is intended to be a media
   descriptor for XHTML+Voice multimodal documents.  It is used to
   inform applications that additional markup for running a voice
   browser component and activating handlers for DOM Level 2 events via
   XML Events [9] can be processed.

   This media type registration is not intended for e-mail usage.

3.  IANA Registration

      To: [email-masked]
      Subject: Registration of MIME media type
               application/xv+xml

      MIME media type name: application

      MIME subtype name: xv+xml

      Required parameters: none

      Optional parameters:

      charset: has the same semantics as the charset parameter of the
      "application/xml" media type specified in [3].

McCobb                  Expires January 27, 2006                [Page 2]

Internet-Draft      XHTML+Voice - application/xv+xml           July 2005

   Encoding considerations:

      XHTML+Voice has the same media type encoding considerations
      specified in section 3.2 of [3].

   Security considerations:

      XHTML+Voice is an extension of XHTML and has the same security
      issues as XHTML.  These include interpreting anchors and forms in
      XHTML documents, and scripting languages and other dynamic
      interactive capabilities.  See section 7 of [4].

      In addition, the scripting language can be accessed by both the
      XHTML and the VoiceXML 2.0 markup embedded in the XHTML+Voice
      document.  See section 1.3.1.5 of [10].

      XML-Events [9] allows an author to attach a handler to any node in
      the document.  The handler that is activated in response to a
      specified event may be either a voice dialog or a script that can
      be either in the same or an external document.

   Interoperability considerations:

      Because XHTML+Voice is built upon W3C standard recommendations, it
      is designed to be interoperable across a wide range of platforms
      and client devices.  Because the extensions to XHTML are
      identified by their namespaces, all browsers that have namespace
      support can run an XHTML+Voice document as an XHTML document
      without voice interaction.

   Published specification:

      The latest published version of XHTML+Voice is [10].

   Applications which use this media type:

      XHTML+Voice documents are intended to be deployed on the World
      Wide Web and rendered by multimodal browsers that support the
      visual and voice modes of interaction.  Because XHTML+Voice is an
      application of XML, authors can expect XHTML+Voice user agents to
      be conformant XML 1.0 [5] processors.  See section 2 of [4].

   Additional information:

      Magic number(s):  There is no single string that is always
      present.

      File extension(s):  mxml, xhvml, xvml, xvm

      Macintosh File Type Code(s):  TEXT

McCobb                  Expires January 27, 2006                [Page 3]

Internet-Draft      XHTML+Voice - application/xv+xml           July 2005

   Person & e-mail address to contact for further information:

      Gerald McCobb
      [email-masked]

   Intended usage:  LIMITED USE

   Author/Change controller:  Gerald McCobb

   Further information:

4.  Fragment Identifiers

   See section 3 of [4].  Following [4], fragment identifiers for XHTML+
   Voice documents designate the element with the corresponding ID
   attribute value (see [5] section 3.3.1).

   While XHTML+Voice adds new ID attributes with fragment identifier
   namespaces that are not in the same namespace as XHTML, uniqueness of
   the ID attribute values is preserved within the document.  See
   sections 1.3.1 and 5.3 of [10].

5.  Recognizing XHTML+Voice files

   Because XHTML+Voice is XML, an XHTML+Voice document [optionally]
   starts with an XML declaration which begins with "<?xml" and has a
   DOCTYPE declaration "<!DOCTYPE html".  XHTML+Voice 1.2 has the
   following DOCTYPE declaration:

   <!DOCTYPE html PUBLIC "-//VoiceXML Forum//DTD XHTML+Voice 1.2//EN"
 "http://www.voicexml.org/specs/multimodal/x+v/12/dtd/xhtml+voice12.dtd">

   Because XHTML+Voice is in the XHTML family of languages, the root
   element of an XHTML+Voice document is 'html' and '<html' can be found
   near the top of the document.

6.  Security Considerations

   Security considerations for this media type are discussed in the MIME
   type registration that appears in section 3.

McCobb                  Expires January 27, 2006                [Page 4]

Internet-Draft      XHTML+Voice - application/xv+xml           July 2005

7.  IANA Considerations

   As described in Section 3, this document specifies the registration
   of a MIME type for XHTML+Voice documents according to [3].

8.  Normative References

   [1]   Bradner, S., "Key words for use in RFCs to Indicate Requirement
         Levels, BCP 14", RFC 2119, March 1997.

   [2]   Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform
         Resource Identifiers (URI): Generic Syntax", RFC 2396,
         August 1998.

   [3]   Murata, M., St. Laurent, S., and D. Kohn, "XML Media Types",
         RFC 3023, January 2001.

   [4]   Baker, M. and P. Stark, "The 'application/xhtml+xml' Media
         Type", RFC 3236, January 2002.

   [5]   Bray, T. and others, "Extensible Markup Language (XML) 1.0, W3C
         Recommendation, http://www.w3.org/TR/REC-xml", February 2004.

   [6]   Dooley, S. and others, "Modularization of XHTML, W3C
         Recommendation, http://www.w3.org/TR/xhtml-modularization",
         April 2001.

   [7]   Altheim, M. and S. McCarron, "XHTML 1.1 - Module-based XHTML,
         W3C Recommendation, http://www.w3.org/TR/xhtml11/", May 2001.

   [8]   Pixley, T., "Document Object Model Level 2 Events
         Specification, W3C Recommendation,
         http://www.w3.org/TR/DOM-Level-2-Events/", November 2000.

   [9]   Pemberton, S., Raman, T., and S. McCarron, "XML Events - An
         events syntax for XML, W3C Recommendation,
         http://www.w3.org/TR/xml-events/", January 2002.

   [10]  Axelsson, J. and others, "XHTML+Voice Profile 1.2,
         http://www.voicexml.org/specs/multimodal/x+v/12/", March 2004.

   [11]  McGlashan, S. and others, "Voice Extensible Markup Language
         (VoiceXML), W3C Recommendation,
         http://www.w3.org/TR/voicexml20/", March 2004.

McCobb                  Expires January 27, 2006                [Page 5]

Internet-Draft      XHTML+Voice - application/xv+xml           July 2005

Author's Address

   Gerald McCobb
   International Business Machines Corporation
   8051 Congress Ave.
   Boca Raton, FL  33487
   USA

   Phone: +1 561 862 2109
   Email: [email-masked]

Intellectual Property Statement

   The IETF takes no position regarding the validity or scope of any
   Intellectual Property Rights or other rights that might be claimed to
   pertain to the implementation or use of the technology described in
   this document or the extent to which any license under such rights
   might or might not be available; nor does it represent that it has
   made any independent effort to identify any such rights.  Information
   on the procedures with respect to rights in RFC documents can be
   found in BCP 78 and BCP 79.

   Copies of IPR disclosures made to the IETF Secretariat and any
   assurances of licenses to be made available, or the result of an
   attempt made to obtain a general license or permission for the use of
   such proprietary rights by implementers or users of this
   specification can be obtained from the IETF on-line IPR repository at
   http://www.ietf.org/ipr.

   The IETF invites any interested party to bring to its attention any
   copyrights, patents or patent applications, or other proprietary
   rights that may cover technology that may be required to implement
   this standard.  Please address the information to the IETF at
   [email-masked].

Disclaimer of Validity

   This document and the information contained herein are provided on an
   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
   ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
   INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
   INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
   WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

McCobb                  Expires January 27, 2006                [Page 6]

Internet-Draft      XHTML+Voice - application/xv+xml           July 2005

Copyright Statement

   Copyright (C) The Internet Society (2005).  This document is subject
   to the rights, licenses and restrictions contained in BCP 78, and
   except as set forth therein, the authors retain all their rights.

Acknowledgment

   Funding for the RFC Editor function is currently provided by the
   Internet Society.

McCobb                  Expires January 27, 2006                [Page 7]

Regards,
Gerald McCobb
IBM
8051 Congress Avenue
Boca Raton, FL 33487
Tel. # 561-862-2109 T/L 975-2109
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://eikenes.alvestrand.no/pipermail/ietf-types/attachments/20050812/527cfbd9/attachment-0001.html
>From [email-masked]  Mon Aug 15 13:23:59 2005
From: 210313041 at suda.edu.cn (DCY)
Date: Tue Aug 16 19:02:21 2005
Subject: Registration of MIME media type application/ocsp-response 
Message-ID: <[email-masked]>

aWV0Zi10eXBlc6OsxPq6w6OhDQoNCgkNCg0KoaGhoaGhoaGhoaGhoaGhodbCDQrA8aOhDQogCQkJ
CQ0KDQqhoaGhoaGhoaGhoaGhoaGhRENZDQqhoaGhoaGhoaGhoaGhoaGhMjEwMzEzMDQxQHN1ZGEu
ZWR1LmNuDQqhoaGhoaGhoaGhoaGhoaGhoaGhoTIwMDUtMDQtMTkNCg==

From: derhoermi at gmx.net (Bjoern Hoehrmann)
Date: Tue Aug  2 10:14:21 2005
Subject: Registration of media type application/xhtml-voice+xml
In-Reply-To: <[email-masked]>
References: <[email-masked]> <[email-masked]>
Message-ID: <[email-masked]>

* Gerald McCobb wrote:
>XHTML+Voice adds the voice mode of interaction to web applications.  This
>additional mode of interaction is not that important for desktop clients.
>Voice Interaction is useful for clients with limited processing, memory,
>and network resources, such as cell phones and wireless PDAs.  For clients
>that don't accept XHTML+Voice markup it matters whether it has to receive
>and ignore additional markup.  For these clients it is important that
>applications send markup dedicated to what they support.

Well, application/xhtml+xml has a profile parameter to indicate
specific profiles such as XHTML+Voice; why is a new XHTML+Voice
media type preferable here?
-- 
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 Aug  3 13:14:49 2005
From: jax at opera.com (Jonny Axelsson)
Date: Sat Aug  6 16:36:15 2005
Subject: Registration of media type application/xhtml-voice+xml
In-Reply-To: <[email-masked]>
References: <[email-masked]>
	<[email-masked]>
	<[email-masked]>
Message-ID: <[email-masked]>

On Tue, 02 Aug 2005 10:14:02 +0200, Bjoern Hoehrmann <[email-masked]>  
wrote:

> Well, application/xhtml+xml has a profile parameter to indicate
> specific profiles such as XHTML+Voice; why is a new XHTML+Voice
> media type preferable here?

This is only semi-related to this question, but profile parameters are  
unreliable. OMA did something similar with a Mobile Profile of XHTML (an  
almost pure subset of XHTML), using the XHTML content type. As a  
consequence we tested parameters and found them somewhat unreliable. I  
don't remember the details but clients didn't always lop the parameters  
off, servers didn't always serve them.

I guess this just goes to show that if a feature is unused long enough  
interoperability suffers (that it is unused may also indicate that this  
wasn't such a good idea but that is another debate).

-- 
Jonny Axelsson, Core Technology, Opera Software ASA
>From [email-masked]  Sun Aug  7 01:53:33 2005
From: mankin at psg.com (Allison Mankin)
Date: Sun Aug  7 01:59:32 2005
Subject: Transport Area requests Media Type review for
	application/poc-settings+xml
Message-ID: <[email-masked]>

The Transport Area requests a Media Type review for the proposed new
media type application/poc-settings+xml, intended for the standards tree,
and specified in 
http://www.ietf.org/internet-drafts/draft-garcia-sipping-poc-isb-am-03.txt

The document has completed an RFC 3427 review by the SIPPING WG.

Please provide any comments before August 22.

Thanks,

Allison