December 2004 - Ietf-types

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

Media Type review request for "application/resource-lists+xml" and "application/rls-services+xml"
by Hisham Khartabil 20 Jan '05

20 Jan '05

The SIMPLE Working Group requests a Media Type review for the following 2 new types: - application/resource-lists+xml - application/rls-services+xml These are intended for the IETF tree, and specified in section 8.2 of http://www.ietf.org/internet-drafts/draft-ietf-simple-xcap-list-usage -04.txt Thanks, Hisham Khartabil SIMPLE WG Co-chair

2 1

MIME Type Review for KPML MIME Types
by Eric Burger 20 Jan '05

20 Jan '05

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 Thanks. -- Eric Burger

2 1

Re: I-D ACTION:draft-lilly-text-troff-00.txt
by Tony Hansen 09 Jan '05

09 Jan '05

I have a serious problem with this parameter: process Lists a recommended command pipeline for formatting. The parameter value may need to be quoted or encoded as provided for by [RFC2045] as amended by [RFC2231] and [errata]. I'd hate to see someone actually implement a mechanism to automatically execute the pipeline. I think this is just ASKING for someone to do so. Now, the information provided in the pipeline IS useful; it provides the list of the preprocessors that are needed to properly process the troff souce. So instead, I'd recommend that there be a parameter that provides just THAT information: preprocessors Lists the preprocessors that need to be invoked to properly process the troff input. The names of the preprocessors are comma separated. The parameter value may need to be quoted or encoded as provided for by [RFC2045] as amended by [RFC2231] and [errata]. In addition, there is one more MAJOR parameter that doesn't appear to be specified anywhere: the macro package that was used in the troff document, such as man, mm, ms, me, etc. So, I'd like to see this optional parameter added: macro package Lists the macro package that needs to be used with the troff document. Examples of macro package names are man, mm, ms and me. Tony Hansen tony(a)att.com

2 2

RE: Registration of media type "application/nss"
by Scott Hollenbeck 04 Jan '05

04 Jan '05

Mike, Request received. I will shepherd your request once the ietf-types review has been completed and any comments have been addressed. Please contact me directly at the end of the two-week review period and we'll go from there. Can you provide a link to the published specification referenced below? -Scott- > -----Original Message----- > From: Mike Hammer [mailto:mhammer@cisco.com] > Sent: Thursday, December 30, 2004 1:52 PM > To: iesg(a)ietf.org > Cc: ietf-types(a)iana.org; iana(a)iana.org > Subject: Registration of media type "application/nss" > > This email requests that the IESG approve the assignment of > the media subtype as described in the registration template below. > > Reference: draft-freed-media-type-reg-01.txt, August 17, 2004, > Media Type Specifications and Registration Procedures, > Section 5, Registration Procedures, > Section 10, Registration Template. > > To: ietf-types(a)iana.org > Subject: Registration of media type "application/nss" > > Type name: application > > Subtype name: nss > > Required parameters: none > > Optional parameters: charset > > Encoding considerations: binary (Note: Data is in US-ASCII range.) > > Restrictions on usage: none > > Security considerations: > > NSS has the potential to disclose private customer information > and the potential for modification of NSS bodies during message > transport to manipulate call setup, mid-call events, or call > release. Modification means the addition of an NSS body where > none existed, the removal of an NSS body where one existed, or > the changing of contents of existing NSS bodies in messages. > NSS can reveal information about telephone subscribers that is > requested to remain private. Security mechanisms must be > provided to meet privacy agreements and regulations. > > NSS can be deployed as an interdomain signaling mechanism and > may be subject to trust relationships and agreements between > administrative domains as well as legal requirements in various > jurisdictions. NSS can affect routing of telephone calls and > associated billing. Security mechanisms must be provided to > control fraud, malicious intents, and unintended consequences. > Such mechanisms include the ability to selectively filter or map > and forward each information element within NSS upon entry or exit > of an administrative domain. All information from unauthenticated > entities must be validated and authorized before being mapped and > forwarded in subsequent signaling messages. Such checks are > particularly needed when information is mapped to/from SIP headers. > > When encapsulated by SIP, the integrity and confidentiality of SIP > messages containing NSS bodies MUST be addressed through > the use of > Transport Layer Security (TLS) or Internet Protocol > Security (IPSEC) > mechanisms as described in the Session Initiation Protocol RFC 3261 > on signaling hops between nodes trusted to handle PSTN signaling. > When intermediate hops are not trusted, end-to-end integrity and > confidentiality may be addressed using RFC 2633, > "Secure/Multipurpose > Internet Mail Extensions (S/MIME) Version 3 Message > Specification", > June 1999. NSS MIME bodies SHOULD be secured using S/MIME > to mitigate > concerns with authentication of the sender, integrity protection > during transit, and confidentiality protection from disclosure to > unauthorized third parties. NSS endpoints MUST support S/MIME > signatures and SHOULD support S/MIME encryption. > > For H.323-based encapsulation of NSS bodies, the security > mechanisms > of ITU-T Recommendation H.235, "Security and encryption > for H-series > (H.323 and other H.245-based) multimedia terminals", > August 2003, must > be used to provide integrity and confidentiality. > > NSS consists of well defined message types and parameters. > Arbitrary > content or directives within field values is not permitted. > > NSS does not employ "active content." > > NSS contains fields which instruct whether privacy data such as > calling party's number is to be presented or restricted. > > NSS is used without and is silent about compression. Use > of compression > in conjunction with NSS does not present any security issues. > > Interoperability considerations: Compatibility mechanisms are > defined in Q.1980.1. > > Published specification: ITU-T Recommendation Q.1980.1, "The > Narrowband > Signalling Syntax (NSS) - Syntax Definition", December 2004. > > Applications which use this media type: Applications in PSTN > Gateways and call control application servers. > > Additional Information: > > Magic numbers: None > > File Extensions: None > > Macintosh File Type Codes: None > > Object Identifiers: {itu-t(0) recommendation(0) q(17) 1980 1} > (0.0.17.1980.1) > See ITU-T Recommendation H.323 Annex M.4 "Tunnelling of > Narrowband Signalling Syntax (NSS) for H.323", December 2004. > > Intended Usage: COMMON > > Person to contact for further information: > > Name: Michael Hammer > E-Mail: mhammer(a)cisco.com > Author/Change controller: ITU-T Study Group 11 > > END > >

2 2

Registration of media type "application/nss"
by Mike Hammer 30 Dec '04

30 Dec '04

This email requests that the IESG approve the assignment of the media subtype as described in the registration template below. Reference: draft-freed-media-type-reg-01.txt, August 17, 2004, Media Type Specifications and Registration Procedures, Section 5, Registration Procedures, Section 10, Registration Template. To: ietf-types(a)iana.org Subject: Registration of media type "application/nss" Type name: application Subtype name: nss Required parameters: none Optional parameters: charset Encoding considerations: binary (Note: Data is in US-ASCII range.) Restrictions on usage: none Security considerations: NSS has the potential to disclose private customer information and the potential for modification of NSS bodies during message transport to manipulate call setup, mid-call events, or call release. Modification means the addition of an NSS body where none existed, the removal of an NSS body where one existed, or the changing of contents of existing NSS bodies in messages. NSS can reveal information about telephone subscribers that is requested to remain private. Security mechanisms must be provided to meet privacy agreements and regulations. NSS can be deployed as an interdomain signaling mechanism and may be subject to trust relationships and agreements between administrative domains as well as legal requirements in various jurisdictions. NSS can affect routing of telephone calls and associated billing. Security mechanisms must be provided to control fraud, malicious intents, and unintended consequences. Such mechanisms include the ability to selectively filter or map and forward each information element within NSS upon entry or exit of an administrative domain. All information from unauthenticated entities must be validated and authorized before being mapped and forwarded in subsequent signaling messages. Such checks are particularly needed when information is mapped to/from SIP headers. When encapsulated by SIP, the integrity and confidentiality of SIP messages containing NSS bodies MUST be addressed through the use of Transport Layer Security (TLS) or Internet Protocol Security (IPSEC) mechanisms as described in the Session Initiation Protocol RFC 3261 on signaling hops between nodes trusted to handle PSTN signaling. When intermediate hops are not trusted, end-to-end integrity and confidentiality may be addressed using RFC 2633, "Secure/Multipurpose Internet Mail Extensions (S/MIME) Version 3 Message Specification", June 1999. NSS MIME bodies SHOULD be secured using S/MIME to mitigate concerns with authentication of the sender, integrity protection during transit, and confidentiality protection from disclosure to unauthorized third parties. NSS endpoints MUST support S/MIME signatures and SHOULD support S/MIME encryption. For H.323-based encapsulation of NSS bodies, the security mechanisms of ITU-T Recommendation H.235, "Security and encryption for H-series (H.323 and other H.245-based) multimedia terminals", August 2003, must be used to provide integrity and confidentiality. NSS consists of well defined message types and parameters. Arbitrary content or directives within field values is not permitted. NSS does not employ "active content." NSS contains fields which instruct whether privacy data such as calling party's number is to be presented or restricted. NSS is used without and is silent about compression. Use of compression in conjunction with NSS does not present any security issues. Interoperability considerations: Compatibility mechanisms are defined in Q.1980.1. Published specification: ITU-T Recommendation Q.1980.1, "The Narrowband Signalling Syntax (NSS) - Syntax Definition", December 2004. Applications which use this media type: Applications in PSTN Gateways and call control application servers. Additional Information: Magic numbers: None File Extensions: None Macintosh File Type Codes: None Object Identifiers: {itu-t(0) recommendation(0) q(17) 1980 1} (0.0.17.1980.1) See ITU-T Recommendation H.323 Annex M.4 "Tunnelling of Narrowband Signalling Syntax (NSS) for H.323", December 2004. Intended Usage: COMMON Person to contact for further information: Name: Michael Hammer E-Mail: mhammer(a)cisco.com Author/Change controller: ITU-T Study Group 11 END

1 0

Media Type review request for video/raw
by Allison Mankin 22 Dec '04

22 Dec '04

The Transport Area requests a Media Type review for the proposed new type video/raw, intended for the IETF tree, and specified in http://www.ietf.org/internet-drafts/draft-ietf-uncomp-video-06.txt (Section 6.1). We know of the following needed changes: 1. Author will be separated from Change Controller, and Change Controller will be modified to "AVT Working Group delegated from the IESG" 2. The text "No file format is defined at this time" should be changed to something like "A file format media type is not defined for this media type at this time" We'll also advise removing the empty fields for Magic Number, File extension, and Macintosh File Type. Please provide any comments as soon as possible. Thanks, Allison

1 0

Media Type review request for audio/ video/ text/ and application/rtx
by Allison Mankin 22 Dec '04

22 Dec '04

The Transport Area requests a Media Type review for four proposed new types: audio/rtx, video/rtx, text/rxt and application/rtx, intended for the IETF tree, and specified in http://www.ietf.org/internet-drafts/draft-ietf-avt-rtp-retransmission-10.txt (Section 8). We know of one needed change: Author will be separated from Change Controller, and Change Controller will be modified to "AVT Working Group delegated from the IESG" Please provide any other comments as soon as possible. Note that these media types are defined only for transport via RTP. Thanks, Allison

1 0

Media Types review
by Hisham Khartabil 16 Dec '04

16 Dec '04

The SIMPLE Working Group requests a Media Type review for the following 4 new types: - application/xcap-el+xml - application/xcap-att+xml - application/xcap-error+xml - application/xcap-caps+xml MIME Type These are intended for the IETF tree, and specified in section 14.2 of http://www.ietf.org/internet-drafts/draft-ietf-simple-xcap-05.txt Thanks, Hisham Khartabil SIMPLE WG Co-chair

1 0

Re: SVG12: image/svg+xml gzip requirements
by Bjoern Hoehrmann 11 Dec '04

11 Dec '04

* Chris Lilley wrote: >BH> Use of the +xml convention implies that such metadata needs to be >BH> overridden > >No, it does not. An xml encoding declaration is sender provided >metadata. However, in the case where a charset parameter is allowed, and >where it can be different, and thus where one has to win over the other, >metadata is indeed being overridden. I agree with you that silent >recovery here is not inthe user interest and a warning should be shown. You either missed that the mail you responded to did not discuss the charset parameter at all, or you are trying to suggest that there is a character encoding that is based on gzip. Such a character encoing would of course by easy to construct, In order to encode a XML document using the gzip-xml character encoding, the XML document is first serialized using a second character encoding such that the resulting octet sequence meets the requirements of the XML 1.0 Recommendation. The new octet sequence is then compressed using the gzip method as defined in RFC 1952. In order to decode a gzip-xml encoded XML document, the octet stream that represents the XML document is first uncompressed using the method defined in RFC 1952. The decoder determines then the character encoding of the resulting octet sequence as defined in the XML 1.0 Recommendation and decodes the sequence according to this character encoding with the exception that the resulting character sequence must be constructed such that XML processors that would processes the character sequence would only read EncName nonterminals that match "gzip-xml" in order to circumvent the the requirment in the XML 1.0 Rec that ... it is a fatal error for an entity including an encoding declaration to be presented to the XML processor in an encoding other than that named in the declaration ... Implementations may implement other algorithms than those described above as long as those alternate algorithms yield in the same processing result. If you imply this gzip-xml character encoding then there is indeed no metadata that is overriden (unless there happend to be higher- level protocol information that would require XML processors to determine a character encoding that is different from "gzip-xml"). If that is your point, I should probably request that support for this gzip-xml character encoding is required for SVG Viewers... -- 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/

2 2