- Ietf-types - alvestrand.no

Re: Proposed media type registration: application/wsdl+xml
by David Booth 04 Feb '05

04 Feb '05

This proposed media type registration was previously sent to ietf-types(a)iana.org on 04-Oct-2004: http://eikenes.alvestrand.no/pipermail/ietf-types/2004-October/000438.html The only comment received (which was sent privately) was a suggested change to the contact information to read: [[ Person & email address to contact for further information: World Wide Web Consortium <web-human(a)w3.org> ]] The version below reflects the above-mentioned change. ---------------------------------------------------------- The proposed registration below is for a media type "application/wsdl+xml" for use with WSDL 2.0 documents. The registration will be requested on behalf of the W3C Web Services Description Working Group. WSDL 2.0 documents are used to describe Web services. The specification of the WSDL 2.0 language itself is available at http://www.w3.org/TR/wsdl20 . This media type definition appears in http://www.w3.org/TR/wsdl20#ietf-draft , which will be updated as necessary. (The version below is the most recent.) This proposed registration is for community review and will be submitted to the IESG for review, approval, and registration with IANA at a later stage. The Last Call period for WSDL 2.0 ends 4 October 2004. However, because of this late notification, the deadline for comments on the media type registration has been extended to 18 October 2004. ======================================================= To: ietf-types(a)iana.org Subject: Registration of media type application/wsdl+xml Type name: application 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] ( http://www.ietf.org/rfc/rfc3023.txt ). Encoding considerations: Identical to those of "application/xml" as described in [RFC 3023] ( http://www.ietf.org/rfc/rfc3023.txt ) section 3.2, as applied to the WSDL document infoset. Restrictions on usage: none Security considerations: This media type uses the "+xml" convention. It shares the same security considerations as described in [RFC 3023] ( http://www.ietf.org/rfc/rfc3023.txt ) section 10. Interoperability considerations: There are no known interoperability issues. Published specification: [WSDL 2.0 Core Language] ( http://www.w3.org/TR/wsdl20 ), [WSDL 2.0 Predefined Extensions] ( http://www.w3.org/TR/wsdl20-extensions ), and [WSDL 2.0 Bindings] ( http://www.w3.org/TR/wsdl20-bindings ). Applications which use this media type: No known applications currently use this media type. Additional information: Magic number(s): In general, the same as for application/xml [RFC 3023] ( http://www.ietf.org/rfc/rfc3023.txt ). In particular, the XML root element of the returned object will be <wsdl:description>, where "wsdl" as any namespace prefix that maps to a WSDL 2.0 namespace URI, as defined in [WSDL 2.0 Core Language] ( http://www.w3.org/TR/wsdl20 ). File extension(s): wsdl Macintosh File Type Code(s): WSDL Base URI: As specified in [RFC 3023] ( http://www.ietf.org/rfc/rfc3023.txt ) section 6. Fragment identifiers: As specified in [WSDL 2.0 FragIDs]. Person & email address to contact for further information: World Wide Web Consortium <web-human(a)w3.org> Intended usage: COMMON Author/Change controller: The WSDL 2.0 specification set is a work product of the World Wide Web Consortium's Web Service Description Working Group [WSDL 2.0 WG]. The W3C has change control over these specifications. References: [RFC 3023] IETF "RFC 3023: XML Media Types", M. Murata, S. St. Laurent, D. Kohn, July 1998. (See http://www.ietf.org/rfc/rfc3023.txt .) [WSDL 2.0 Core Language] Web Services Description Language (WSDL) Version 2.0 Part 1: Core Language, R. Chinnici, M. Gudgin, J-J. Moreau, S. Weerawarana, Editors. World Wide Web Consortium, 3 August 2004. This version of the "Web Services Description Language (WSDL) Version 2.0 Part 1: Core Language" Specification is available is available at http://www.w3.org/TR/2004/WD-wsdl20-20040803 . The latest version of "Web Services Description Language (WSDL) Version 2.0 Part 1: Core Language" is available at http://www.w3.org/TR/wsdl20 . [WSDL 2.0 FragIDs] WSDL 2.0 Fragment Identifiers. This is a subsection of [WSDL 2.0 Core Language] above. The latest version is available at http://www.w3.org/TR/wsdl20/#frag-ids [WSDL 2.0 Predefined Extensions] Web Services Description Language (WSDL) Version 2.0 Part 2: Predefined Extensions, M. Gudgin, A. Lewis, and J. Schlimmer, Editors. World Wide Web Consortium, 3 August 2004. This version of the "Web Services Description Language (WSDL) Version 2.0 Part 2: Predefined Extensions" Specification is available at http://www.w3.org/TR/2004/WD-wsdl20-extensions-20040803 . The latest version of "Web Services Description Language (WSDL) Version 2.0 Part 2: Predefined Extensions" is available at http://www.w3.org/TR/wsdl20-extensions . [WSDL 2.0 Bindings] Web Services Description Language (WSDL) Version 2.0 Part 3: Bindings, H. Haas, P. Le Hégaret, J-J. Moreau, D. Orchard, J. Schlimmer, Editors. World Wide Web Consortium, 3 August 2004. This version of the "Web Services Description Language (WSDL) Version 2.0 Part 3: Bindings" Specification is available at http://www.w3.org/TR/2004/WD-wsdl20-bindings-20040803 . The latest version of "Web Services Description Language (WSDL) Version 2.0 Part 3: Bindings" is available at http://www.w3.org/TR/wsdl20-bindings . [WSDL 2.0 WG] The W3C Web Services Description Working Group. Information about this Working Group is available at http://www.w3.org/2002/ws/desc/ [XML 1.0] Extensible Markup Language (XML) 1.0 (Second Edition), T. Bray, J. Paoli, C. M. Sperberg-McQueen, and E. Maler, Editors. World Wide Web Consortium, 10 February 1998, revised 6 October 2000. This version of the XML 1.0 Recommendation is http://www.w3.org/TR/2000/REC-xml-20001006 . The latest version of XML 1.0 is available at http://www.w3.org/TR/REC-xml . -------------------- The proposal above was prepared following instructions at http://www.ietf.org/internet-drafts/draft-freed-media-type-reg-01.txt , and further instructions at http://www.w3.org/2002/06/registering-mediatype.html , since this is a media type from W3C. -- David Booth W3C Fellow / Hewlett-Packard

1 0

[Fwd: I-D ACTION:draft-hall-mime-app-mbox-03.txt]
by Eric A. Hall 30 Jan '05

30 Jan '05

The ADs for the applications area are going to move this into last-call again, but we all want to run it back up the flagpole one more time. This version departs from earlier releases by specifying a "format" parameter to the application/mbox media-type, by defining a "default" value for the parameter, and by defining a default mbox database format that must be supported. The use of a format parameter allows different implementations to be documented, and for them to be specified in the transfer (eg, a "SunOS" format might specify the use of content-length and other things). Unrecognized formats are to be treated as application/octet-stream. The "default" format uses a sequence of 822 messages, with the exception that line-endings are LF instead of CR/LF (this only applies to the canonical database, and doesn't affect the transfer protocol or anything else). Inheriting 822 rules means that email addresses must be qualified, encodings must be specified, etc. All implementations have to support this default format, and unspecified formats must be treated as "default" (this is mostly for the benefit of protocols like HTTP, where parameters are not always (or even usually) defined. Another thing that is specified here is that separator lines (at the least) must be encoded to prevent local collisions, when an mbox attachment is saved into an existing local folder (messages can become irreversible mingled if some kind of escaping is not performed). There's one problem in this that I caught after submission, which is that ">From" escaping is specified, but shouldn't be. ">From" escaping is not needed for transfers, and it's mostly a local matter anyway (having to do with local parsing), and it's damn near impossible to deal with all the potential exceptions (such as doubled escapes against quoted text, for example), so it's really best not to specify anything. I'll roll this change into any other comments that I get for the -04 version. Anyway, any other comments are appreciated, as usual. -- Eric A. Hall http://www.ehsco.com/ Internet Core Protocols http://www.oreilly.com/catalog/coreprot/

2 2

ConfirmSystem: iana@icann.org [[60b84673d8300f72]]
by iana＠iana.org 29 Jan '05

29 Jan '05

Thank you for your message. The iana(a)iana.org address collects a tremendous amount of spam, and we have been forced to implement protective measures. In order to process your message we need to confirm that it came from a real email address. To confirm your message, you can either: 1) Reply to this message, without altering the subject line The "Re: " added by many mail clients is OK, but please note that this method is *not* foolproof. or 2) Visit the URL <http://confirm.icann.org/?s=60b84673d8300f72&l=iana@icann.org> If you want to be very sure that your message gets through, do both steps above -- it does no harm to confirm more than once. For your reference, the subject of the message you sent was: "{Filename?} Delivery service mail" and it arrived at IANA approximately at Fri Jan 28 20:51:00 2005. --------------------------------------------------------------- ConfirmSystem: iana(a)icann.org [[60b84673d8300f72]] 1

1 0

ConfirmSystem: iana@icann.org [[1f8c0c2f29dfa1c5]]
by iana＠iana.org 27 Jan '05

27 Jan '05

Thank you for your message. The iana(a)iana.org address collects a tremendous amount of spam, and we have been forced to implement protective measures. In order to process your message we need to confirm that it came from a real email address. To confirm your message, you can either: 1) Reply to this message, without altering the subject line The "Re: " added by many mail clients is OK, but please note that this method is *not* foolproof. or 2) Visit the URL <http://confirm.icann.org/?s=1f8c0c2f29dfa1c5&l=iana@icann.org> If you want to be very sure that your message gets through, do both steps above -- it does no harm to confirm more than once. For your reference, the subject of the message you sent was: "{Filename?} Delivery by mail" and it arrived at IANA approximately at Thu Jan 27 09:00:57 2005. --------------------------------------------------------------- ConfirmSystem: iana(a)icann.org [[1f8c0c2f29dfa1c5]] 1

1 0

Media Types review for application/simple-filter+xml
by Hisham Khartabil 27 Jan '05

27 Jan '05

The SIMPLE Working Group requests a Media Type review for the following new type: - application/simple-filter+xml This is intended for the IETF tree, and specified in section 8.1 of http://www.ietf.org/internet-drafts/draft-ietf-simple-filter-format -04.txt Thanks, Hisham Khartabil SIMPLE WG Co-chair

2 3

Media Type review request for application/dialog-info+xml
by Allison Mankin 25 Jan '05

25 Jan '05

The Transport Area requests a Media Type review for the proposed new type application/dialog-info+xml, intended for the IETF tree, and specified http://www.ietf.org/internet-drafts/draft-ietf-sipping-dialog-package-05.txt (Section 8.1). We know of the following needed changes: 1. Author/Change Controller will be modified to "SIPPING Working Group delegated from the IESG" Please provide any comments as soon as possible. Thanks, Allison

5 7

RE: MIME Type Review for KPML MIME Types
by Eric Burger 24 Jan '05

24 Jan '05

We did not, as message/* is for encapsulating user messages. KPML is an application PDU (application message). > -----Original Message----- > From: Bjoern Hoehrmann [mailto:derhoermi@gmx.net] > Sent: Thursday, January 20, 2005 5:43 PM > To: Eric Burger > Cc: ietf-types(a)iana.org > Subject: Re: MIME Type Review for KPML MIME Types > > > * Eric Burger wrote: > >KPML is in the process of WGLC in the SIPPING work group. > > > >KPML defines two new MIME types, application/kpml-request+xml and > >application/kpml-response+xml . > > > >We would greatly appreciate expert review of the definition > and usage of > >these new types. > > > >The draft lives at: > >http://www.ietf.org/internet-drafts/draft-ietf-sipping-kpml-06.txt > > Did the Working Group consider using the message/* top-level type?

1 0

RE: Media Type review request for application/dialog-info+xml
by Scott Hollenbeck 24 Jan '05

24 Jan '05

Allison, I found a few small schema errors when running the schema from section 4.4 through the IBM Schema Quality Checker. They should be looked at (sorry if the diagnostic lines below get broken in strange ways): Initializing Schema Quality Checker. Please wait ... SchemaQualityChecker has been initialized PROCESSING test.xsd time : 2005-01-24T14:28:21 ... test.xsd (file 1 of 1) now being read ... ERROR file = file:test.xsd line 100 column 70 SEVERITY: 1 ERROR TYPE: 1 MESSAGE cvc-complex-type.2.4.a: Invalid content starting with element 'xs:attribute'. One of '{"http://www.w3.org/2001/XMLSchema":unique, "http://www.w3.org/2001/XMLSchema":key, "http://www.w3.org/2001/XMLSchema":keyref}' is expected. ------------------------------------------------------------------------ ERROR file = file:test.xsd line 100 column 70 SEVERITY: 1 ERROR TYPE: 1 MESSAGE cvc-complex-type.3.2.2: Attribute 'use' is not allowed to appear in element 'xs:attribute'. ------------------------------------------------------------------------ ERROR file = file:test.xsd line 85 column 41 SEVERITY: 1 ERROR TYPE: 1 MESSAGE The reference nameaddr uses the empty string as its prefix. But there is no namespace declaration which associates the empty string with a namespace. To fix the problem, you may add the attribute "xmlns" in the root element (<schema>) ------------------------------------------------------------------------ end time = 2005-01-24T14:28:24 -Scott-

1 0

Registration of MIME media type .pss
by Tony Mohr 21 Jan '05

21 Jan '05

To: ietf-types(a)iana.org Subject: Registration of MIME media type *.pss MIME media type name: Application MIME subtype name: .pss Required parameters: none Optional parameters: none Encoding considerations: ESS files are binary data and thus should be encoded for MIME mail transmission. The same guidelines that apply to application/octet-stream apply to this. Security considerations: none Interoperability considerations: none Published specification: The specifications for this content type are proprietary. They are specified by Essential Security Software, Inc. Applications which use this media type: Essential Security Software product, Essential Security Suite and Ecrypt-it. Contains encrypted information. Additional information: Magic number(s): none File extension(s): *.pss Macintosh File Type Code(s): none Person & email address to contact for further information: Tony Mohr tonym(a)essentialsecurity.com 425.454.2632 Intended usage: common (One of COMMON, LIMITED USE or OBSOLETE) Best Regards, Tony Mohr Essential Security Software Director - Business Development Desk: 425-454-2632 Cell: 425-443-6713 Email: tonym@essentialsecurity,com Web: <blocked::blocked::BLOCKED::http://www.essentialsecurity.com> www.essentialsecurity.com "Security Made Simple"

3 2

Re: [AVT] Updated 3GPP2 MIME ID: draft-garudadri-avt-3gpp2-mime-01.txt
by Harinath Garudadri 21 Jan '05

21 Jan '05

At 10:49 AM 1/16/2005, Colin Perkins wrote: >On 17 Dec 2004, at 22:19, Harinath Garudadri wrote: >> An updated version of the ID registering 3gpp2 MIME types is now >>available at >>http://www.ietf.org/internet-drafts/draft-garudadri-avt-3gpp2-mime >>-01.txt. This version uses the correct template and incorporates some >>editorial changes. > >I have a few details that should be resolved: > > - Please move the paragraph defining "Conventions used in this >document" to > be part of the introduction, rather than being a separate section. >Also, > please remove section 6 and add the text as an unnumbered note in the > boilerplate at the start of the draft. Done. The latest draft can obtained from http://people.qualcomm.com/randy/draft-garudadri-avt-3gpp2-mime-02.txt if you need it before the ID appears at http://www.ietf.org/internet-drafts/draft-garudadri-avt-3gpp2-mime -02.txt > - Is there a need to register media types other than audio or video >(the > most obvious being "text/3gpp2", to allow a future timed text >format)? 3GPP2 timed text is same as 3GPP timed text. So, there is no need for other media types and we plan to use text/3gpp-tt >Otherwise this draft looks reasonable to me, although I'm not a MIME >expert. Once you've made these changes, you might consider asking for >review on the <ietf-types(a)iana.org> mailing list. I have copied <ietf-types(a)iana.org> in this thread. Is this adequate or do I need to do anything else? Thanks, hari. >Colin Dr. Hari Garudadri Qualcomm Inc. work : +1 858 651 6383 mobile : +1 858 229 2801

1 0