- Ietf-types - alvestrand.no

Registration of media type application/sparql-query
by Eric Prud'hommeaux 09 Mar '06

09 Mar '06

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: public-rdf-dawg-comments(a)w3.org 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 (eric(a)w3.org) Feel free to forward this message to any list for any purpose other than email address distribution.

1 1

Registration of media type application/sparql-results+xml
by Eric Prud'hommeaux 09 Mar '06

09 Mar '06

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 <public-rdf-dawg-comments(a)w3.org> 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 (eric(a)w3.org) Feel free to forward this message to any list for any purpose other than email address distribution.

1 1

Transport Area requests Media Type review for draft-jones-avt-audio-t38-05.txt
by Allison Mankin 08 Mar '06

08 Mar '06

The Transport Area requests a Media Type review for draft-jones-avt-audio-t38-05.txt. This document was given IETF Last Call for Historic status because review by the Audio Video Transport Working Group and the IESG led to concern that the audio/t38 format should not become a precedent for future media types, though it should be registered, as it is required by a specific application within ITU SG 16's T.38 real-time fax support. The document states this is a "legacy" application so this is a registration by a Historic document not for new development. Please provide any comments before March 22, 2006. Thanks, Allison

1 0

Last call for review comments for audio/sp-midi and audio/mobile-xmf
by timo.kosonen＠nokia.com 16 Feb '06

16 Feb '06

I am about to ask IANA for the publication for the two mediatypes below. They were posted on this email reflector on 11.11.2005. This is the last call for comments. Please provide any review comments for the internet drafts below at the latest by the 23rd of February 2006. http://www.ietf.org/internet-drafts/draft-kosonen-sp-midi-mediatype-00.t xt http://www.ietf.org/internet-drafts/draft-kosonen-mobile-xmf-mediatype-0 0.txt Best Regards, Timo Kosonen

1 0

Re: Preliminary Community Review: text/json
by Douglas Crockford 10 Feb '06

10 Feb '06

The section on Security Considerations addressed this directly. Security considerations: Generally there are security issues with scripting languages. JSON is a subset of JavaScript, but it is a safe subset that excludes assignment and invocation. A JSON text can be safely passed into JavaScript's eval() function (which compiles and executes a string) if all of the characters not enclosed in strings are in the set of characters which form JSON tokens. This can be quickly determined in JavaScript with two regular expressions and calls to the test and replace methods. var my_JSON_object = !(/[^,:{}\[\]0-9.\-+Eaeflnr-u \n\r\t]/.test( text.replace(/"(\\.|[^"\\])*"/g, ''))) && eval('(' + text + ')'); ----- Original Message ---- From: Graham Klyne <GK(a)ninebynine.org> To: Douglas Crockford <douglas(a)crockford.com> Cc: ietf-types(a)iana.org Sent: Thursday, February 9, 2006 4:14:33 PM Subject: Re: Preliminary Community Review: text/json Douglas Crockford wrote: > This is notice of a potential media type registration. > The details may be found here: > > http://www.ietf.org/internet-drafts/draft-crockford-jsonorg-json-02.txt > I have some limited experience of using JSON with TurboGears, and I think this registration is useful and appropriate. I haven't read the technical spec in great detail, but didn't see any major problems on cursory reading. However, I think there is an important issue that is missing from the security considerations: Because JSON is a subset of Javascript, and is sometimes used as a way of communicating information to Javascript programs, there is a possibility for implementers to simply treat the JSON expressions directly as Javascript source code (e.g. via Javascript eval()). This is safe if the expression is known to conform the the JSON specification, but if this is not checked there is a possibility that executable code inject side effects into a running Javascript program. Therefore, applications that receive JSON expressions need to ensure that they are processed in such a way that ill-formed expressions have no possibility of causing unexpected side effects or distorting the information that is displayed to users. There is one other thing I noticed. The proposed MIME type is text/json. I think that, based on comments I have seen made previously, that application/json would be more appropriate. My understanding is that text/... is intended for textual information that is suitable for display to a general human audience; e.g., it has been suggested that text/html was a mistake, which should not be repeated. #g -- Graham Klyne For email: http://www.ninebynine.org/#Contact

3 2

Request for review of application/h224 media type
by Magnus Westerlund 02 Feb '06

02 Feb '06

The AVT WG is currently in WG last call of MIME type registration for RTP Payload format for H.224: http://www.ietf.org/internet-drafts/draft-ietf-avt-mime-h224-05.txt This document defines the application/h224 media type. Please provide any review comments at the latest by the 16th of February 2006. Thanks Magnus Westerlund AVT Chair

1 0

Request for review of update of H.261 media type (video/h261)
by Magnus Westerlund 01 Feb '06

01 Feb '06

The AVT WG is currently in WG last call of the update of the H.261 video codecs payload format. That includes an updated media type registration that we would like you to review. Please provide any feedback before the 14th of February. Please see section 6.1.1: http://www.ietf.org/internet-drafts/draft-ietf-avt-rfc2032-bis-13.txt Thanks Magnus Westerlund Multimedia Technologies, Ericsson Research EAB/TVA/A ---------------------------------------------------------------------- Ericsson AB | Phone +46 8 4048287 Torshamsgatan 23 | Fax +46 8 7575550 S-164 80 Stockholm, Sweden | mailto: magnus.westerlund(a)ericsson.com

1 0

Transport Area requests Media Type review for audio/rtp-midi and audio/asc
by Allison Mankin 08 Jan '06

08 Jan '06

The Transport Area requests a Media Type review for the proposed new types audio/rtp-midi and audio/asc, intended for the IETF tree, specified in http://www.ietf.org/internet-drafts/draft-ietf-avt-rtp-midi-format-14.txt The audio/rtp-midi registration is specified in Appendix H.1 The audio/asc registration is specified in Appendix H.3, and additional information about it is found in Appendix C.6.5. In particular, this shows that the AudioSpecificConfig data object is a binary file format with midi audio field contents provided to the renderer as initial input. This is why this particular registration uses the audio top-level. Please provide any comments by January 23, 2006. Thanks, Allison

1 0

Request for media type review of video/vc1
by Colin Perkins 04 Jan '06

04 Jan '06

The Audio/Video Transport working group requests media type review for the new video/vc1 media type, defined in section 6.1 of draft- ietf-avt-rtp-vc1-05.txt. This draft is currently in working group last call. We would be grateful if any comments could be made by 6th January 2006. Thanks, Colin Perkins (AVT co-chair) Begin forwarded message: > From: Internet-Drafts(a)ietf.org > Date: 3 January 2006 20:50:02 GMT > To: i-d-announce(a)ietf.org > Cc: avt(a)ietf.org > Subject: [AVT] I-D ACTION:draft-ietf-avt-rtp-vc1-05.txt > > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > This draft is a work item of the Audio/Video Transport Working > Group of the IETF. > > Title : RTP Payload Format for Video Codec 1 (VC-1) > Author(s) : A. Klemets > Filename : draft-ietf-avt-rtp-vc1-05.txt > Pages : 33 > Date : 2006-1-3 > > This memo specifies an RTP payload format for encapsulating Video > Codec 1 (VC-1) compressed bit streams, as defined by the Society of > Motion Picture and Television Engineers (SMPTE) standard, SMPTE > 421M. > SMPTE is the main standardizing body in the motion imaging industry > and the SMPTE 421M standard defines a compressed video bit stream > format and decoding process for television. > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-ietf-avt-rtp-vc1-05.txt

1 1

video/vnd.avi and audio/vnd.wave media types
by Bjoern Hoehrmann 21 Dec '05

21 Dec '05

Hi, It seems http://www.iana.org/assignments/media-types/video/ and http://www.iana.org/assignments/media-types/audio/ lack the types for which RFC 2361 established the codec registry, video/vnd.avi and audio/vnd.wave. I think they should be added with reference to RFC 2361 (http://www.rfc-editor.org/rfc/rfc2361.txt) regards, -- Björn Höhrmann · mailto:bjoern@hoehrmann.de · http://bjoern.hoehrmann.de Weinh. Str. 22 · Telefon: +49(0)621/4309674 · http://www.bjoernsworld.de 68309 Mannheim · PGP Pub. KeyID: 0xA4357E78 · http://www.websitedev.de/

1 0