Subject: Request for media type review of video/h263-1998 and video/h263-2000
From: magnus.westerlund at ericsson.com (Magnus Westerlund)
Date: Wed Nov 30 09:27:53 2005

A Correction:

The request for review is for the latest version of the document:
http://www.ietf.org/internet-drafts/draft-ietf-avt-rfc2429-bis-07.txt

/Magnus

Magnus Westerlund wrote:
> The AVT WG requests Media Type review for two proposals to update media 
> types video/h263-1998 and video/h263-2000, intended for the standards 
> tree, and specified in 
> http://www.ietf.org/internet-drafts/draft-ietf-avt-rfc2429-bis-06.txt
> 
> The above document is currently in WG last call. Please provide any 
> comments to this list before 14th of December.
> 
> Thanks
> 
> Magnus Westerlund
> AVT WG Chair
> 
> 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]
> 

-- 

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 Nov 30 10:05:04 2005
From: magnus.westerlund at ericsson.com (Magnus Westerlund)
Date: Wed Nov 30 10:39:58 2005
Subject: Request for media type review of video/h263-1998 and
	video/h263-2000
In-Reply-To: <6.0.0.20.2.20051130101654.03a10060@localhost>
References: <[email-masked]>
	<6.0.0.20.2.20051130101654.03a10060@localhost>
Message-ID: <[email-masked]>

Thanks,

Martin for the review. Sorry about the version mix up. For a diff 
between the version 6 and 7:
http://tools.ietf.org/wg/avt/draft-ietf-avt-rfc2429-bis/draft-ietf-avt-rfc2429-bis-07-from-06.diff.html

Please see comments inline.

Martin Duerst wrote:
> Both types say:
> 
>   Encoding considerations:
> 
>       This type is only defined for transfer via RTP [RFC3550]
> 
> 'Encoding considerations' should mention how characters are encoded.
> If these types don't contain character data, just say so. If they
> do, say how that character data is encoded, or point to where this
> is described.

In the correct version -07 this is now changed to:

    Encoding considerations:

       This media type is framed and binary, see section 4.8 in[I-
       D.freed-media-type-reg]

> 
> Also, it says:
> 
>    Security considerations: See Section 10
> 
> This should be changed to "Section 10 of RFC????", to make the
> registration template self-contained at least in form. Ideally,
> that stuff would be in the template, at least in a shortened form,
> because people often do not follow references.

Okay, we can fix this. I haven't been that hard on this due to how the 
registry is currently structured. If one goes to IANA the reference 
points to the whole RFC. Thus one get both the template and the complete 
document in which it is included. But I will ask the author to fix this 
when the WGLC is over.

> 
> Also, in the first type, the parameter section is really long.
> It may be better to take out some of that material and put it
> in the actual spec, because it looks more like spec stuff than
> like registration stuff.

As the media type template is part of the actual specification, we 
define the parameters fully within the template. I don't see any gain by 
moving them outside of the template, simply more hassle for the authors.

Cheers

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 Nov 30 14:42:49 2005
From: timo.kosonen at nokia.com ([email-masked])
Date: Wed Nov 30 14:42:52 2005
Subject: Request for media type review of audio/sp-midi
Message-ID: <[email-masked]>

Nokia requests Media Type review for a proposal to add media type audio/sp-midi, intended for the standards tree, and specified in 
http://www.ietf.org/internet-drafts/draft-kosonen-sp-midi-mediatype-00.txt
 
Best Regards, 
 
Timo Kosonen
---------------------------
Nokia Research Center
phone: +358 504835206
email: [email-masked]
address: P.O. Box 100, 33721 Tampere, Finland
visiting: Visiokatu 1, Tampere, Finland
>From [email-masked]  Wed Nov 30 14:46:41 2005
From: timo.kosonen at nokia.com ([email-masked])
Date: Wed Nov 30 14:47:24 2005
Subject: Request for media type review of audio/mobile-xmf
Message-ID: <[email-masked]>

Nokia requests Media Type review for a proposal to add media 
type audio/mobile-xmf, intended for the standards tree, and specified in 
http://www.ietf.org/internet-drafts/draft-kosonen-mobile-xmf-mediatype-00.txt
  
Best Regards, 
 
Timo Kosonen
---------------------------
Nokia Research Center
phone: +358 504835206
email: [email-masked]
address: P.O. Box 100, 33721 Tampere, Finland
visiting: Visiokatu 1, Tampere, Finland 

From: eric at w3.org (Eric Prud'hommeaux)
Date: Thu Nov 24 22:16:52 2005
Subject: Registration of media type application/sparql-query
Message-ID: <[email-masked]>

see also http://www.w3.org/TR/2005/WD-rdf-sparql-query-20051123/mime.txt

Type name:
  application

Subtype name:
  sparql-query

Required parameters:
  None

Optional parameters:
  None

Encoding considerations:
  The syntax of the SPARQL Query Language is expressed over
  code points in Unicode[UNICODE 3.0].  The encoding is always
  UTF-8 [RFC3629].

  Unicode code points may also be expressed using an \uXXXX (U+0 to
  U+FFFF) or \UXXXXXXXX syntax (for U+10000 onwards) where X is a
  hexadecimal digit [0-9A-F]

Security considerations:
  SPARQL queries using FROM, FROM NAMED, or GRAPH may cause the
  specified URI to be dereferenced. This may cause additional use of
  network, disk or CPU resources along with associated secondary issues
  such as denial of service. The security issues of Uniform Resource
  Identifier (URI): Generic Syntax [RFC3986] Section 7 should be
  considered. In addition, the contents of file: URIs can in some cases
  be accessed, processed and returned as results, providing unintended
  access to local resources.

  The SPARQL language permits extensions, which will have their own
  security implications.

  Multiple IRIs may have the same appearance. Characters in different
  scripts may look similar (a Cyrillic "o" may appear similar to a Latin
  "o"). A character followed by combining characters may have the same
  visual representation as another character (LATIN SMALL LETTER E
  followed by COMBINING ACUTE ACCENT has the same visual representation
  as LATIN SMALL LETTER E WITH ACUTE). Users of SPARQL must take care to
  construct queries with IRIs that match the IRIs in the data. Further
  information about matching of similar characters can be found in
  Unicode Security Considerations [UNISEC] and Internationalized
  Resource Identifiers (IRIs) [RFC3987] Section 8.
Interoperability considerations:
  There are no known interoperability issues.

Published specification:
  This specification.

Applications which use this media type:
  No known applications currently use this media type.

Additional information:

Magic number(s):
  A SPARQL query may have the string 'PREFIX' (case independent) near
  the beginning of the document.

File extension(s): 
  ".rq"

Base URI:
  The SPARQL 'BASE <IRIref>' term can change the current base URI for
  relative IRIrefs in the query language that are used sequentially
  later in the document.

Macintosh file type code(s):
  "TEXT"

Person & email address to contact for further information:
  [email-masked]

Intended usage:
  COMMON

Restrictions on usage:
  None

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

Normative References

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

[RFC3629] F. Yergeau, "UTF-8, a transformation format of ISO 10646",
          RFC 3629, November 2003.

[RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform
          Resource Identifier (URI): Generic Syntax", STD 66, RFC
          3986, January 2005.

[RFC3987] Duerst, M. and M. Suignard, "Internationalized Resource
          Identifiers (IRIs)", RFC 3987, January 2005.

[UNICODE3.0] "The Unicode Standard Version 3.0", Addison Wesley,
          Reading, MA, ISBN 0-201-61633-5, August 2000.
          http://www.unicode.org/unicode/standard/standard.html. 

[UNISEC]  Mark Davis, Michel Suignard, "Unicode Security
          Considerations.
          http://www.unicode.org/reports/tr36/
-- 
-eric

office: +81.466.49.1170 W3C, Keio Research Institute at SFC,
                        Shonan Fujisawa Campus, Keio University,
                        5322 Endo, Fujisawa, Kanagawa 252-8520
                        JAPAN
        +1.617.258.5741 NE43-344, MIT, Cambridge, MA 02144 USA
cell:   +81.90.6533.3882

([email-masked])
Feel free to forward this message to any list for any purpose other than
email address distribution.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 481 bytes
Desc: Digital signature
Url : http://www.alvestrand.no/pipermail/ietf-types/attachments/20051124/e0df4deb/attachment.bin
>From [email-masked]  Thu Nov 24 22:07:19 2005
From: eric at w3.org (Eric Prud'hommeaux)
Date: Thu Nov 24 22:26:55 2005
Subject: Registration of media type application/sparql-results+xml
Message-ID: <[email-masked]>

see also http://www.w3.org/2005/11/sparql-results%2Bxml.txt

Type name:
  application

Subtype name:
  sparql-results+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 [RFC3023], section 3.2.

Encoding considerations:
  Identical to those of "application/xml" as specified in [RFC3023],
  section 3.2.

Security considerations:
  SPARQL query results uses URIs.  See Section 7 of [RFC3986].

  SPARQL query results uses IRIs.  See Section 8 of [RFC3987].

  As this media type uses the "+xml" convention, it shares the same
  security considerations as described in [RFC3023], section 10.

Interoperability considerations:
  There are no known interoperability issues.

Published specification:
  This specification.

Applications which use this media type:
  No known applications currently use this media type.

Additional information:

Magic number(s):
  As specified for "application/xml" in [RFC3023], section 3.2.

File extension(s):
  ".srx"

Fragment identifiers:
  Identical to that of "application/xml" as described in RFC 3023
  [RFC3023], section 5.

Base URI:
  As specified in [RFC3023], section 6.

Macintosh file type code(s):
  "TEXT"

Person & email address to contact for further information:
  Eric Prud'hommeaux <[email-masked]>

Intended usage:
  COMMON

Restrictions on usage:
  None

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

References

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

[RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform
          Resource Identifier (URI): Generic Syntax", STD 66, RFC
          3986, January 2005.

[RFC3987] Duerst, M. and M. Suignard, "Internationalized Resource
          Identifiers (IRIs)", RFC 3987, January 2005.
-- 
-eric

office: +81.466.49.1170 W3C, Keio Research Institute at SFC,
                        Shonan Fujisawa Campus, Keio University,
                        5322 Endo, Fujisawa, Kanagawa 252-8520
                        JAPAN
        +1.617.258.5741 NE43-344, MIT, Cambridge, MA 02144 USA
cell:   +81.90.6533.3882

([email-masked])
Feel free to forward this message to any list for any purpose other than
email address distribution.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 481 bytes
Desc: Digital signature
Url : http://www.alvestrand.no/pipermail/ietf-types/attachments/20051124/3a9f1d04/attachment-0001.bin
>From [email-masked]  Tue Nov 29 16:02:04 2005
From: magnus.westerlund at ericsson.com (Magnus Westerlund)
Date: Tue Nov 29 19:20:29 2005
Subject: Request for media type review of video/h263-1998 and video/h263-2000
Message-ID: <[email-masked]>

The AVT WG requests Media Type review for two proposals to update media 
types video/h263-1998 and video/h263-2000, intended for the standards 
tree, and specified in 
http://www.ietf.org/internet-drafts/draft-ietf-avt-rfc2429-bis-06.txt

The above document is currently in WG last call. Please provide any 
comments to this list before 14th of December.

Thanks

Magnus Westerlund
AVT WG Chair

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 Nov 30 02:23:14 2005
From: duerst at it.aoyama.ac.jp (Martin Duerst)
Date: Wed Nov 30 06:32:26 2005
Subject: Request for media type review of video/h263-1998 and
 video/h263-2000
In-Reply-To: <[email-masked]>
References: <[email-masked]>
Message-ID: <6.0.0.20.2.20051130101654.03a10060@localhost>

Both types say:

   Encoding considerations:

       This type is only defined for transfer via RTP [RFC3550]

'Encoding considerations' should mention how characters are encoded.
If these types don't contain character data, just say so. If they
do, say how that character data is encoded, or point to where this
is described.

Also, it says:

    Security considerations: See Section 10

This should be changed to "Section 10 of RFC????", to make the
registration template self-contained at least in form. Ideally,
that stuff would be in the template, at least in a shortened form,
because people often do not follow references.

Also, in the first type, the parameter section is really long.
It may be better to take out some of that material and put it
in the actual spec, because it looks more like spec stuff than
like registration stuff.

Regards,   Martin.

At 00:02 05/11/30, Magnus Westerlund wrote:
 >The AVT WG requests Media Type review for two proposals to update media 
types video/h263-1998 and video/h263-2000, intended for the standards tree, 
and specified in 
http://www.ietf.org/internet-drafts/draft-ietf-avt-rfc2429-bis-06.txt
 >
 >The above document is currently in WG last call. Please provide any 
comments to this list before 14th of December.
 >
 >Thanks
 >
 >Magnus Westerlund
 >AVT WG Chair
 >
 >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: tedwards at pbs.org (Thomas Edwards)
Date: Fri Nov  4 17:14:39 2005
Subject: Registration of MIME media type application/mxf
Message-ID: <[email-masked]>

This is a MIME media type registration for the Material Exchange Format
(MXF) standard of the Society of Motion Picture and Television Engineers
(SMPTE - http://www.smpte.org)

MXF is a standard wrapper format developed for the interchange of
audiovisual material, including both audiovisual essence and rich
metadata.  

MXF and the .mxf file extension are used by many broadcast and digital
cinema vendors today.  The standard definition can be found in SMPTE
377M.

Thomas Edwards
Senior Manager, Interconnection Engineering
Interconnection Replacement Office
PBS
1320 Braddock Place
Alexandria, VA  22314
Phone:(703) 739-5270
Fax: (703) 739-5770      
Email: [email-masked]

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

MIME media type name: application

MIME subtype name: mxf

Required parameters: none

Optional parameters: none

Encoding considerations: binary

Security considerations:

Application/mxf objects are not signed but may be partially encrypted
internally.  External security mechanisms must be employed to ensure
content confidentiality. MXF, through metadata extensions, may allow
executable code to be transferred in the file.  It is suggested that no
unauthenticated executables decoded from an MXF file be executed.  Some
compressed essence types carried in MXF may carry a risk that certain
pathological bitstreams could lead to potential denial-of-service
attacks against these essence decoders.

Interoperability considerations: 

        MXF provides a standard wrapping for a number of audio and video
essence types according to a number of different Operational Patterns
(OP).  Thus interoperability depends upon the MXF file decoder having
the capability to match the features of the MXF file encoder.  An
Application Specification (AS) can ensure that MXF encoders and decoders
can effectively interoperate.

Published specification: SMPTE 377M

Applications which use this media type:

       MXF is a wrapper for many types of audio and video essence types
in use by many applications in the broadcast and digital cinema
industries.

Additional information:

Magic number(s): none
File extension(s): .mxf
      Macintosh File Type Code(s): MXFF
      Object Identifier(s) or OID(s): none

Person & email address to contact for further information:

Thomas Edwards
email: [email-masked]

Intended usage: COMMON

Author/Change controller:
Thomas Edwards      
e-mail: [email-masked]

___________________________________________________________________

Big Big Friends are coming your way for Big Big Friend Day on PBS KIDS!
On November 25th, join pals from CLIFFORD and DRAGON TALES
For fun, surprises, and a peek at some brand new friends!
pbskids.org

___________________________________________________________________

This email may contain material that is confidential or proprietary to PBS and is intended solely for use by the intended recipient.  Any review, reliance or distribution of such material by others, or forwarding of such material without express permission, is strictly prohibited.  If you are not the intended recipient, please notify the sender and destroy all copies.
__________________________________________________________________
>From [email-masked]  Tue Nov 15 16:35:13 2005
From: ylafon at w3.org (Yves Lafon)
Date: Wed Nov 16 00:17:08 2005
Subject: Media Type Request for comments: WS-CDL 1.0
Message-ID: <[email-masked]>

[
     Notes:

     We slipped up in not sending this along with the Last Call
     announcement; please accept our apologies.

     Comments on the MIME-related part of the document may be made
     on the ietf-types mailing list or in the
     [email-masked] mailing list..  See the
     "Status of this Document" section for further information.

     We are following
     http://www.ietf.org/internet-drafts/draft-freed-media-type-reg-05.txt
     here, and the text is written to be part of a larger document.

     Finally, as WS-CDL is a description format and not something directly
     executable, the Working Group didn't identify any need for a
     specific security section.

]
The current specification is at:
     http://www.w3.org/TR/2005/CR-ws-cdl-10-20051109/

The MIME Type template at
     http://www.w3.org/TR/ws-cdl-10/#Mime-Type-definition

One typo already spotted, in the Author/Change controller, 
http://www.w3.org/2002/ws/chor/ should be a link with a text value of "Web 
Services Choreography Working Group".
Thanks,

Registration of MIME Media Type application/cdl+xml
---------------------------------------------------
MIME media type name:

     application
MIME subtype name:

     cdl+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 [RFC 3023].

Encoding considerations:

     Identical to those of "application/xml" as described in RFC 3023 [RFC 
3023], section 3.2.
Security considerations:

     WS-CDL has the same security considerations described in RFC3023 [RFC 
3023], section 10.
Interoperability considerations:

     There are no known interoperability issues.
Published specification:

     This document
Applications which use this media type:

     No known applications currently use this media type.
Additional information:

     File extension:

         CDL
     Fragment identifiers:

         Identical to that of "application/xml" as described in RFC 3023 
[RFC 3023], section 5.
     Base URI:

         As specified in RFC 3023 [RFC 3023], section 6.
     Macintosh File Type code:

         TEXT

Person and email address to contact for further information:

     Yves Lafon <[email-masked]>
Intended usage:

     COMMON
Author/Change controller:

     The WS-CDL 1.0 specification is a work product of the World Wide Web 
Consortium's http://www.w3.org/2002/ws/chor/. The W3C has change control 
over this specification.

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

-- 
Yves Lafon - W3C
"Baroula que barouleras, au ti?u toujou t'entourneras."
>From [email-masked]  Tue Nov 15 15:29:14 2005
From: magnus.westerlund at ericsson.com (Magnus Westerlund)
Date: Wed Nov 16 00:41:29 2005
Subject: Request for media type review of audio/tone and
	audio/telephone-event
Message-ID: <[email-masked]>

This is the request of media type review of audio/telephone-event and 
audio/tone media types documented in section 7.1 of
http://www.ietf.org/internet-drafts/draft-ietf-avt-rfc2833bis-12.txt

The document is currently in WG last call in AVT WG. Please send any 
comments on these media types before Tuesday 29th of November to this 
list and to us AVT WG chairs (me and Colin Perkins).

Thanks

Magnus Westerlund
AVT WG chair

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]  Fri Nov 18 09:54:52 2005
From: duerst at it.aoyama.ac.jp (Martin Duerst)
Date: Fri Nov 18 11:33:50 2005
Subject: Media Type Request for comments: WS-CDL 1.0
In-Reply-To: <[email-masked]>
References: <[email-masked]>
Message-ID: <6.0.0.20.2.20051118174702.07983df0@localhost>

Hello Yves,

Some comments below.

At 00:35 05/11/16, Yves Lafon wrote:
 >[
 >     Notes:
 >
 >     We slipped up in not sending this along with the Last Call
 >     announcement; please accept our apologies.
 >
 >     Comments on the MIME-related part of the document may be made
 >     on the ietf-types mailing list or in the
 >     [email-masked] mailing list..  See the
 >     "Status of this Document" section for further information.
 >
 >     We are following
 >     http://www.ietf.org/internet-drafts/draft-freed-media-type-reg-05.txt
 >     here, and the text is written to be part of a larger document.
 >
 >     Finally, as WS-CDL is a description format and not something directly
 >     executable, the Working Group didn't identify any need for a
 >     specific security section.

You need a security section, even just to describe why you think
there are no security issues, and to document that you actually
thought this through.

 >]
 >The current specification is at:
 >     http://www.w3.org/TR/2005/CR-ws-cdl-10-20051109/
 >
 >The MIME Type template at
 >     http://www.w3.org/TR/ws-cdl-10/#Mime-Type-definition

That's good info, but it needs to be *inside* the registration
template. That may make the registration template in the spec
look a bit weird (explicitly referring to the document
itself in textual form inside the document), but is
absolutely necessary to allow the template to be taken
out and stand on its own.

 >One typo already spotted, in the Author/Change controller, 
http://www.w3.org/2002/ws/chor/ should be a link with a text value of "Web 
Services Choreography Working Group".
 >Thanks,
 >
 >Registration of MIME Media Type application/cdl+xml
 >---------------------------------------------------
 >MIME media type name:
 >
 >     application

Whatever kind of formatting you use, please make sure
that the empty line comes between the field value and
the next field name, not between the field name and
the associated value.

 >MIME subtype name:
 >
 >     cdl+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 [RFC 3023].
 >
 >Encoding considerations:
 >
 >     Identical to those of "application/xml" as described in RFC 3023 
[RFC 3023], section 3.2.
 >Security considerations:
 >
 >     WS-CDL has the same security considerations described in RFC3023 
[RFC 3023], section 10.
 >Interoperability considerations:
 >
 >     There are no known interoperability issues.
 >Published specification:
 >
 >     This document

This is where you have to provide full and explicit information,
both the title and the URI of the document. Providing the title

Providing the title of the document will also help people
understand what CDL stands for.

Regards,    Martin.

 >Applications which use this media type:
 >
 >     No known applications currently use this media type.
 >Additional information:
 >
 >     File extension:
 >
 >         CDL
 >     Fragment identifiers:
 >
 >         Identical to that of "application/xml" as described in RFC 3023 
[RFC 3023], section 5.
 >     Base URI:
 >
 >         As specified in RFC 3023 [RFC 3023], section 6.
 >     Macintosh File Type code:
 >
 >         TEXT
 >
 >Person and email address to contact for further information:
 >
 >     Yves Lafon <[email-masked]>
 >Intended usage:
 >
 >     COMMON
 >Author/Change controller:
 >
 >     The WS-CDL 1.0 specification is a work product of the World Wide Web 
Consortium's http://www.w3.org/2002/ws/chor/. The W3C has change control 
over this specification.
 >
 >--------------------------------------------------------------
 >
 >
 >
 >--
 >Yves Lafon - W3C
 >"Baroula que barouleras, au ti? toujou t'entourneras."