- Ietf-types - example.com

test to ietf-types@ietf.org
by Chris Newman 07 Oct '08

07 Oct '08

Test. If someone accidentally uses ietf-types(a)ietf.org instead of ietf-types(a)iana.org, it should now work. - Chris

1 0

Types review request: draft-ietf-simple-imdn-07.txt
by Robert Sparks 06 Oct '08

06 Oct '08

The SIMPLE working group has requested publication of a draft that registers message/imdn+xml and would appreciate this lists review. The draft can be found at http://www.ietf.org/internet-drafts/draft-ietf-simple-imdn-07.txt Thanks! Robert Sparks SIMPLE co-chair

1 0

RE: Review for media types: application/ibe-pp-data, application/ibe-key-request+xml, and application/ibe-pkg-reply+xml
by Luther Martin 03 Oct '08

03 Oct '08

> -----Original Message----- > From: mark(a)coactus.com [mailto:mark@coactus.com] On Behalf Of Mark > Baker > Sent: Friday, October 03, 2008 11:49 AM > To: Luther Martin > Cc: Chris Newman; Turner, Sean P.; ietf-types(a)iana.org; > tim.polk(a)nist.gov > Subject: Re: Review for media types: application/ibe-pp-data, > application/ibe-key-request+xml, and application/ibe-pkg-reply+xml > > On Fri, Oct 3, 2008 at 2:18 PM, Luther Martin <martin(a)voltage.com> > wrote: > >> -----Original Message----- > >> From: mark(a)coactus.com [mailto:mark@coactus.com] On Behalf Of Mark > >> Baker > >> > In the case of IBE, the public key is the identity, so the content > of > >> the proposed application/ibe-key-request is really just a subset of > >> what's encoded with application/pkcs10. (It's not-self signed, etc., > >> but that's really a minor difference.) > >> > > >> > What's the fundamental difference between these two that warrants > >> greatly different processing? > >> > >> It's the two mandatory media type parameters as described in sec > 5.4, > >> and (unmentioned until now) the mandatory parameter in 5.7. > > > > So if the mandatory parameter sections are deleted, then it would be > OK? That's the way that the media types application/pkcs10 and > application/pkcs7-mime are defined. > > Right. No problem. Communicating by e-mail just isn't as efficient as communicating in person, is it?

1 0

RE: Review for media types: application/ibe-pp-data, application/ibe-key-request+xml, and application/ibe-pkg-reply+xml
by Turner, Sean P. 03 Oct '08

03 Oct '08

There was another update: http://www.ietf.org/internet-drafts/draft-ietf-smime-ibearch-08.txt spt >-----Original Message----- >From: stian(a)mygrid.org.uk [mailto:stian@mygrid.org.uk] On >Behalf Of Stian Soiland-Reyes >Sent: Tuesday, September 23, 2008 7:07 AM >To: Turner, Sean P. >Cc: ietf-types(a)iana.org >Subject: Re: Review for media types: application/ibe-pp-data, >application/ibe-key-request+xml, and application/ibe-pkg-reply+xml > >On Mon, Aug 11, 2008 at 21:05, Turner, Sean P. ><turners(a)ieca.com> wrote: >> The Identity-based Encryption Architecture and Supporting Data >> Structures ID, an S/MIME WG item, is seeking to register >three new media types: >> application/ibe-pp-data, application/ibe-key-request+xml, and >> application/ibe-pkg-reply+xml. We're seeking a wider >community review >> of these media types. The ID can be found at: >> >> http://www.ietf.org/internet-drafts/draft-ietf-smime-ibearch-07.txt > >I get a 404 error when trying to follow the above mentioned link. > >-- >Stian Soiland-Reyes, myGrid team >School of Computer Science >The University of Manchester

4 14

review of audio media types for G.719
by Roni Even 01 Oct '08

01 Oct '08

Hi, The AVT working group requests media type review for the g719 media type defined in section 7.1 of http://tools.ietf.org/html/draft-ietf-avt-rtp-g719-02 . This draft is currently in AVT working group last call. We would be grateful if any comments could be made by October 1st. Thanks, Roni Even (AVT co-chair)

3 2

please review "application/rif+xml"
by Sandro Hawke 29 Sep '08

29 Sep '08

The following media type registration is currently published as part of a W3C Last Call Working Draft [1] and will soon be submitted to the IESG for review, approval, and registration with IANA (as per [2]). At this point, we would appreciate comments on this registration information. If you see any problems, please let us know. (It's tempting to say a few words about RIF here, but I suppose I should let the registration stand on its own. It does includes links to the specification and to the Working Group home page.) -- Sandro [1] http://www.w3.org/TR/2008/WD-rif-bld-20080730/#Appendix:_RIF_Media_Type_Reg… [2] http://www.w3.org/2002/06/registering-mediatype ================================================================ Type name: application Subtype name: rif+xml Required parameters: none Optional parameters: charset, as per RFC 3023 (XML Media Types) Encoding considerations: same as RFC 3023 (XML Media Types) Security considerations: Systems which consume RIF documents are potentially vulnerable to attack by malicious producers of RIF documents. The vulnerabilities and forms of attack are similar to those of other Web-based formats with programming or scripting capabilities, such as HTML with embedded Javascript. Excessive Resource Use / Denial of Service Attacks Full and complete processing of a RIF document, even one conforming to the RIF-BLD dialect, may require unlimited CPU and memory resources. Through the use of "import", it may also require arbitrary URI dereferencing, which may consume all available network resources on the consuming system or other systems. RIF consuming systems SHOULD implement reasonable defenses against these attacks. Exploiting Implementation Flaws RIF is a relatively complex format, and rule engines can be extremely sophisticated, so it is likely that some RIF consuming systems will have bugs which allow specially constructed RIF documents to perform inappropriate operations. We urge RIF implementors to make systems which carefully anticipate and handle all possible inputs, including those which present syntactic or semantic errors. External (Application) Functions Because RIF may be extended with local, application defined datatypes and functions, arbitrary vulnerabilities may be introduced. Before being installed on systems which consume untrusted RIF documents, these external functions should be closely reviewed for their own vulnerabilities and for the vulnerabilities that may occur when they are used in unexpected combinations, like "cross-site scripting" attacks. In addition, as this media type uses the "+xml" convention, it shares the same security considerations as other XML formats; see RFC 3023 (XML Media Types). Interoperability considerations: This media type is intended to be shared with other RIF dialects, to be specified in the future. Interoperation between the dialects is governed by the RIF specifications. Published specification: RIF Basic Logic Dialect W3C Working Draft (Recommendation Track) http://www.w3.org/TR/rif-bld/ This media type is intended to be shared with other RIF dialects, to be specified in the future. Applications that use this media type: Unknown at the time of this draft. Multiple applications are expected, however, before the specification reaches W3C Proposed Recommendation status. Additional information: Magic number(s): As with XML in general (See RFC 3023 (XML Media Types)), there is no magic number for this format. However, the XML namespace "http://www.w3.org/2007/rif#" will normally be present in the document. It may theoretically be missing if the document uses XML entities in an obfuscatory manner. The hex form of that namespace will depend on the charset. For utf-8, the hex is: 68 74 74 70 3a 2f 2f 77 77 77 2e 77 33 2e 6f 72. File extension(s): .rif (or .xml) Macintosh file type code(s): "TEXT" (like other XML) Person & email address to contact for further information: Sandro Hawke, sandro(a)w3.org. Please send technical comments and questions about RIF to public-rif-comments(a)w3.org, a mailing list with a public archive at http://lists.w3.org/Archives/Public/public-rif-comments/ Intended usage: COMMON Restrictions on usage: None Author: The editor and contact for this media type registration is Sandro Hawke, sandro(a)w3.org. Change controller: RIF is a product of the Rule Interchange Format (RIF) Working Group of the World Wide Web Consortium (W3C). See http://www.w3.org/2005/rules/wg for information on the group. The W3C (currently acting through this working group) has change control over the RIF specification. (Any other information that the author deems interesting may be added below this line.)

2 1

test to ietf-types@iana.org
by Chris Newman 23 Sep '08

23 Sep '08

Test, please ignore. - Chris

1 0

test to ietf-types@alvestrand.no
by Chris Newman 23 Sep '08

23 Sep '08

Test, please ignore. - Chris

1 0

Request for review of media types on URC framework
by Gottfried Zimmermann 15 Sep '08

15 Sep '08

ISO/IEC 24752:2008 is a new standard on the Universal Remote Console (URC) framework which facilitates pluggable user interfaces for the control of devices and services. It defines various XML-based documents for information exchange within a control network. We (the editor and the corresponding subcommittee SC35 in ISO/IEC JTC1) are seeking feedback on a set of 5 MIME types proposed to be registered with IANA: . application/urc-uisocketdesc+xml: User Interface Socket Description (as defined in ISO/IEC 24752-2:2008) . application/urc-pret+xml: Presentation Template (as defined in ISO/IEC 24752-3:2008) . application/urc-targetdesc+xml: Target Description (as defined in ISO/IEC 24752-4:2008) . application/urc-ressheet+xml: Resource Sheet (as defined in ISO/IEC 24752-5:2008) . application/urc-resdir+xml: Resource Directory (as defined in ISO/IEC 24752-5:2008) Please see the attached files for the proposed registrations. Thanks, Gottfried ___________________________________________________ Gottfried Zimmermann, Ph.D. Phone +49 7121 790806 ICT Systems Architect under contract for: Trace R&D Center, University of Wisconsin-Madison ___________________________________________________

1 0

Review requests: application/news-* + message/news
by Frank Ellermann 28 Aug '08

28 Aug '08

Hi, the USEFOR WG is about to finish <http://tools.ietf.org/html/draft-ietf-usefor-usepro> Section 4 of this draft -12 contains four MIME types: message/news (OBSOLETE) application/news-transmission (update) application/news-groupinfo (new) application/news-checkgroups (new) See the registration templates below, Frank --- MIME type name: message MIME subtype name: news Required parameters: none Optional parameters: charset, compare message/rfc822 Encoding considerations: compare message/rfc822 (RFC 2046) Security considerations: OBSOLETE, use message/rfc822. Interoperability considerations: Rarely used; and therefore often handled as application/octet-stream. Disposition should by default be inline. Published specification: [SON-OF-1036], RFCXXXX Applications that use this media type: Some old mail and news user agents. Intended usage: OBSOLETE Author: Henry Spencer Change controller: IETF --- MIME type name: application MIME subtype name: news-transmission Required parameters: none Optional parameters: One and only one of "usage=moderate", "usage=inject", or "usage=relay". Encoding considerations: A transfer-encoding different from that of the article transmitted MAY be supplied to ensure correct transmission over some 7bit transport medium. Security considerations: A news article may be a control message, which if processed could have effects on the recipient host's system beyond just storage of the article. Published specification: RFCXXXX Body part: A complete proto-article ready for injection into Netnews or an article being relayed to another agent. Applications that use this media type: Injecting agents, Netnews moderators. Intended usage: COMMON Change controller: IETF --- MIME type name: application MIME subtype name: news-groupinfo Required parameters: none Optional parameters: charset, which MUST be a charset registered for use with MIME text types and has the same syntax as the parameter defined for text/plain [RFC2046]. Specifies the charset of the body part. If not given, the charset defaults to US-ASCII [ASCII]. Encoding considerations: 7bit or 8bit MUST be used to maintain compatibility. Security considerations: None. Interoperability considerations: Disposition should by default be inline. Applications that use this media type: Control message issuers, relaying agents, serving agents. Published specification: RFCXXXX Intended usage: COMMON Change controller: IETF --- MIME type name: application MIME subtype name: news-checkgroups Required parameters: none Optional parameters: charset, which MUST be a charset registered for use with MIME text types and has the same syntax as the parameter defined for text/plain [RFC2046]. Specifies the charset of the body part. If not given, the charset defaults to US-ASCII [ASCII]. Encoding considerations: 7bit or 8bit MUST be used to maintain compatibility. Security considerations: This media type provides only a means for conveying a list of newsgroups and does not provide any information indicating whether the sender is authorized to state which newsgroups should exist within a hierarchy. Such authorization must be accomplished by other means. Interoperability considerations: Disposition should by default be inline. Applications that use this media type: Control message issuers, relaying agents, serving agents. Published specification: RFCXXXX Intended usage: COMMON Change controller: IETF ---

1 0