- Ietf-types - alvestrand.no

Re: draft-freed-mime-p4-04 is apparently superseded by..
by Jeff.Hodges＠KingsMountain.com 27 Aug '04

27 Aug '04

> I didn't see a LAST CALL or a Protocol Action > > http://www1.ietf.org/mail-archive/web/ietf-announce/current/index.html According to Ned (I called him), this is indeed the case. He said he'd post an explanation here in the near future. JeffH > > -----Original Message----- > > From: ietf-types-bounces(a)alvestrand.no > > [mailto:ietf-types-bounces@alvestrand.no] On Behalf Of Jeff Hodges > > Sent: Saturday, August 21, 2004 12:10 PM > > To: IETF Types vetting list > > Subject: draft-freed-mime-p4-04 is apparently superseded by.. > > > > draft-freed-mime-p4-05 > > http://www.ietf.org/internet-drafts/draft-freed-mime-p4-05.txt > > > > draft-freed-media-type-reg-01 > > http://www.ietf.org/internet-drafts/draft-freed-media-type-reg-01.txt > > > > > > MartinD or whomever might want to update their very nice page.. > > > > How to Register a Media Type with IANA (for the IETF tree) > > http://www.w3.org/2002/06/registering-mediatype.html > > > > > > thanks, > > > > JeffH > > > JeffH

1 0

MIME Sub-type Registrations for FITS
by Steve Allen 26 Aug '04

26 Aug '04

Greetings. The FITS Working Group of the International Astronomical Union has approved the submission of the attached document as an Internet-Draft in the expectation that it may become an Informational RFC and result in the registration of the two MIME media types image/fits and application/fits. The approval process for this document is visible in the archives of the IAU FITS Working Group at http://listmgr.cv.nrao.edu/pipermail/iaufwg/ The call for votes in the IAUFWG is visible at http://listmgr.cv.nrao.edu/pipermail/iaufwg/2004-July/000200.html The approval of the document by the IAUFWG is visible at http://listmgr.cv.nrao.edu/pipermail/iaufwg/2004-August/000212.html -- Steve Allen UCO/Lick Observatory Santa Cruz, CA 95064 sla(a)ucolick.org Voice: +1 831 459 3046 http://www.ucolick.org/~sla PGP: 1024/E46978C5 F6 78 D1 10 62 94 8F 2E 49 89 0E FE 26 B4 14 93

1 0

Re: [PHP-DEV] Re: Registration of MIME media type application/vnd.php.serialized
by Mario Salzer 24 Aug '04

24 Aug '04

Martin Duerst <duerst(a)w3.org> schrieb am 24.08.04 08:24:08: > [...] > What are 'arbitrary non-printable characters, binary octets'? > Does iso-8859-1 allow the encoding of arbitrary non-printable > characters? Does iso-8859-1 encode binary octets? Is it possible > in this format to serialize data that is another encoding than > iso-8859-1? > > My advice: Please remove any mention of iso-8859-1 from this > draft, it doesn't belong here. Thank you, Martin! I remove that again (just wanted to make it a bit more informative here), and it was wrong anyhow - since it is a charset-less data format, and the contained strings could even be in different character sets each. mario ________________________________________________________________ Verschicken Sie romantische, coole und witzige Bilder per SMS! Jetzt neu bei WEB.DE FreeMail: http://freemail.web.de/?mc=021193

1 0

Registration of MIME media type application/vnd.php.serialized
by Mario Salzer 24 Aug '04

24 Aug '04

This vendor tree MIME type registration application discusses the data format emitted by PHPs "serialize()". It is no longer in use only within there; some independent implementations exist (evtl. becoming an exchange format). Now that doesn't require a MIME Type per se, but people also started pushing data in this format through the wires ("me too!"). See also "PHP-RPC" in [http://geri.cc.fer.hr/~ivoras/web2/papers/phprpc.pdf] -- not the best example, but at least highlights the necessarity of a MIME Type - else people go by text/html. * I guess by RFC2048 the PHP group [//php.net] should have filed this rather, but if they had any interest in it they'd already done long before. The vendor name was more accurately "zend" or "phpnet", but simply "application/vnd.php.serialized" looks much better. * Not all too sure if this MIME subtype should have the trailing 'd' or simply be called "/vnd.php.serialize". The "/...d" version however seems to match better with "/x-www-form-urlencoded". * I've included an as-short-as-possible description, cause Google didn't found anything worth getting referenced, and I'm really not aware of an official format spec. * Btw, "Person & email address to contact for further information" could be a mailing list instead, couldn't it? hope the wording is 'good enough' for a vnd. subtype :) mario --------------------------------------------------------------------- MIME media type name: application MIME subtype name: vnd.php.serialized Required parameters: NONE Optional parameters: version=x.y.z SHOULD be added in responses (not in Accept: headers [RFC2295]) to indicate which PHP interpreter version the data was compacted by. This is useful to identify and eventually work around bugs (format violations) from earlier implementations. Encoding considerations: BINARY As per current use, contents assigned this MIME Type should be considered to be in the ISO-8859-1 (Latin-1) character set, so that they also may contain arbitrary non-printable characters, binary octets. Transport channels not capable of handling raw 8 bit without data corruption SHOULD therefore apply a Transfer-Encoding of "base64" or something similar. Security considerations: Implementations SHOULDN'T attempt to reproduce more complex data types like objects, file descriptors, function bytecode and pointers, because most of this was typically of little use if the received data came from a remote machine or even from a different programming language. For optimal security only the basic data types are to be extracted and messages fully be rejected as soon as unknown data type identifiers were detected. Strongly typed languages with fixed-length variable data storage should additionally take care not to expand entities of the format described herein beyond memory boundaries; even if none of the mentioned types is that difficult to decipher. Interoperability considerations: The specified format is meant to transport data in a machine- independent representation, and is especially freed from byte- ordering issues, because all integer types pass in string representation. However, there is no surety that the described data representation could be used by every possible system, especially since it originally was made for use by interpreted languages only. Published specification: To date there is no openly published specification of this data representation format. For reference the original implementation in [http://cvs.php.net/php-src/ext/standard/var.c#click-display] or even better the Perl implementation by Scott Hurring available under [http://hurring.com/code/perl/serialize/] can be reviewed. A terse documentation of how the basic data types are to be encoded is however included here. Format description: Data is compacted into string representation by bailing out chunks containing a type identifier (one letter) an optional length/count field (for strings and arrays) and an optional value (optional because the NULL/undef type does not require one for obvious reasons), all separated by colons and ended with a semicolon in most cases. <app/vnd.php.serialized#TEXT> = (<data>) *1 <data> = ( <undef> | <boolean> | <int> | <float> | <string> | <hash> | <strangethings> ) <undef> = 'N;' <boolean> = ( 'b:0;' | 'b:1;' ) <int> = 'i:' ['-'] <digit>*1 ';' <float> = 'd:' ['-'] <digit>*1 '.' <digit>*1 ';' <string> = 's:' ( <LENGTH> ) <:"> <text> <";> <text> is the string this entity represents after serialization. It has exactly <LENGTH> characters and is enclosed here by two quote marks. No escaping is to be applied, and the receiver shouldn't have to decode it. <hash> = 'a:' ( <COUNT> ) ':{' (<data> <data>)*COUNT '}' Where <COUNT> is a positive integer (as string) matching the number of key<data>+value<data> pairs in between the curly braces. As an exception the string representation of an array or hash does not carry a final semicolon (unlike all basic data types). Other known data type identifiers are "O" for objects, "R" for references and "r" for object references. They are not further mentioned here, because they are of little use for exchanging data across servers as outlined in the Security considerations section. Applications which use this media type: [http://www.php.net/] PHP interpreter with original implementation [http://hurring.com/code/perl/serialize/] Perl 'serialize.pm' by Scott Hurring and others [http://php.net/serialize#41948] serialize methods for Ecma/JavaScript types by Iván Montes Additional information: Magic numbers: NONE File extensions: NONE Macintosh File Type Codes: NONE Object Identifiers or OIDs: NONE Person & email address to contact for further information: Mario Salzer <mario(a)erphesfurt.de> Intended usage: COMMON This data format is in heavy use for temporarily storing data to disk to keep it beyond a single application run. Recently it also started to get used for transportation of data via HTTP, as lightweight alternative to SOAP and also XML-RPC. By including the original representation types of transcoded data, it can be used advantageous to "multipart/form-data" and of course the more simple "application/x-www-form-urlencoded". It's not only much simpler and faster due to less requirements on escaping, but also indirectly allows for validation (data types). Author/Change controller: Mario Salzer <mario(a)erphesfurt.de> Since this registration happened on deputy of the vendor, it's only senseful to transfer 'change control' to <.*(a)php.net> on request.

2 1

DRAFT Registration of MIME media type application/samlmetadata+xml
by Jeff Hodges 23 Aug '04

23 Aug '04

comments appreciated... thanks, JeffH ----- <NOTE: Registration of MIME media type application/samlmetadata+xml sstc-saml-2.0-application-samlmetadata-registration-00 Jeff Hodges <Jeff.Hodges(a)Sun.com> 23-Aug-2004 This document is intended to be included in sstc-saml-metadata-2.0-cd-02 (ie the next time [SAMLv2Meta] is rev'd), as an appendix. Please see http://www.w3.org/2002/06/registering-mediatype.html for an overview of the intricities involved when a non-IETF organization registers a MIME media type in the "standards tree" (aka "IETF tree"). The below registration material is intended to satisfy the requirements stated in draft-freed-media-type-reg-01.txt (which superseded draft-freed-mime-p4-04.txt). This "NOTE" is intended to be removed upon copying this document's content into [SAMLv2Meta]. Acknowledgments: Thanks to Ned Freed and Larry Masinter for their comments on a draft of a related registration. The security considerations section leverages that of http://www.iana.org/assignments/media-types/application/vnd.paos+xml, by John Kemp. > To: ietf-types(a)iana.org Subject: Registration of MIME media type application/samlmetadata+xml Introduction This document defines a MIME media type -- application/samlmetadata+xml -- for use with the XML serialization of Security Assertion Markup Language metadata. SAML is a work product of the OASIS Security Services Technical Committee [SSTC]. The SAML specifications define XML-based constructs with which one may make, and convey, security assertions. Using SAML, one can assert that an authentication event pertaining to some subject has occurred and convey said assertion to a relying party, for example. SAML profiles require agreements between system entities regarding identifiers, binding support, endpoints, certificates, keys, and so forth. Such information is treated as metadata by SAML v2.0. [SAMLv2Meta] specifies this metadata, as well as specifying metadata publication and resolution mechanisms. If the publishing protocol permits MIME-based identification of content types, then use of the application/samlmetadata+xml MIME media type is required. MIME media type name: application MIME subtype name: samlmetadata+xml Required parameters: none Optional parameters: charset Same as charset parameter of application/xml [RFC3023]. Encoding considerations: Same as for application/xml [RFC3023]. Security considerations: Per their specification, samlmetadata+xml typed objects do not contain executable content. However, these objects are XML-based [XML], and thus they have all of the general security considerations presented in section 10 of [RFC3023]. SAML metadata [SAMLv2Meta] contains information whose integrity and authenticity is important – identity provider and service provider public keys and endpoint addresses, for example. To counter potential issues, the publisher may sign samlmetadata+xml typed objects. Any such signature should be verified by the recipient of the data - both as a valid signature, and as being the signature of the publisher. Additionally, various of the publication protocols, e.g. HTTP-over-TLS/SSL, offer means for ensuring the authenticity of the publishing party and for protecting the metadata in transit. [SAMLv2Meta] also defines prescriptive metadata caching directives, as well as guidance on handling HTTPS redirects, trust processing, server authentication, and related items. For a more detailed discussion of SAML v2.0 metadata and its security considerations, please see [SAMLv2Meta]. For a discussion of overall SAML v2.0 security considerations and specific security-related design features, please refer to the SAML v2.0 specifications listed in the below bibliography. The specifications containing security-specific information are explicitly listed. Interoperability considerations: SAML v2.0 metadata explicitly supports identifying the protocols and versions supported by the identified entities. For example, an identity provider entity can be denoted as supporting SAML v2.0, SAML v1.1 [SAMLv1.1], Liberty ID-FF 1.2 [LAPFF], or even other protocols if they are unambiguously identifiable via URI [RFC2396]. This protocol support information is conveyed via the protocolSupportEnumeration attribute of metadata objects of the RoleDescriptorType. Published specification: [SAMLv2Meta] explicitly specifies use of the application/samlmetadata+xml MIME media type. Applications which use this media type: Potentially any application implementing SAML v2.0, as well as those applications implementing specifications based on SAML, e.g. those available from the Liberty Alliance [LAP]. Additional information: Magic number(s): In general, the same as for application/xml [RFC3023]. In particular, the XML root element of the returned object will be one of <md:EntityDescriptor>, <md:AffiliationDescriptor>, or <md:EntitiesDescriptor>. where "md" maps to the SAML v2.0 metadata namespace: urn:oasis:names:tc:SAML:2.0:metadata File extension(s): none Macintosh File Type Code(s): none Person & email address to contact for further information: This registration is made on behalf of the OASIS Security Services Technical Committee (SSTC) Please refer to the SSTC website for current information on committee chairperson(s) and their contact addresses: http://www.oasis-open.org/committees/security/. Committee members should submit comments and potential errata to the securityservices(a)lists.oasis-open.org list. Others should submit them by filling out the web form located at http://www.oasis-open.org/committees/comments/form.php?wg_abbrev=s Additionally, the SAML developer community email distribution list, saml-dev(a)lists.oasis-open.org, may be employed to discuss usage of the application/samlmetadata+xml MIME media type. The "saml-dev" mailing list is publicly archived here: http://lists.oasis-open.org/archives/saml-dev/. To post to the "saml-dev" mailing list, one must subscribe to it. To subscribe, send a message with the single word "subscribe" in the message body, to: saml-dev-request(a)lists.oasis-open.org. Intended usage: COMMON Author/Change controller: The SAML specification sets are a work product of the OASIS Security Services Technical Committee (SSTC). OASIS and the SSTC have change control over the SAML specification sets. Bibliography [LAP] "Liberty Alliance Project". See http://www.projectliberty.org/ [LAPFF] "Liberty Alliance Project: Federation Framework". See http://www.projectliberty.org/resources/ specifications.php#box1 [OASIS] "Organization for the Advancement of Structured Information Systems". See http://www.oasis-open.org/ [RFC2396] T. Berners-Lee, R. Fielding, L. Masinter, Uniform Resource Identifiers (URI): Generic Syntax. IETF RFC 2396, August 1998. Available at http://www.ietf.org/rfc/rfc2396.txt [RFC3023] M. Murata, S. St.Laurent, D. Kohn, "XML Media Types", IETF Request for Comments 3023, January 2001. Available as http://www.rfc-editor.org/rfc/rfc3023.txt [SAMLv1.1] OASIS Security Services Technical Committee, "Security Assertion Markup Language (SAML) Version 1.1 Specification Set". OASIS Standard 200308, August 2003. Available as http://www.oasis-open.org/committees/download.php /3400/oasis-sstc-saml-1.1-pdf-xsd.zip [SAMLv2.0] OASIS Security Services Technical Committee, "Security Assertion Markup Language (SAML) Version 2.0 Specification Set". WORK IN PROGRESS. Available at http://www.oasis-open.org/committees/security/ [SAMLv2Bind] S. Cantor et al., "Bindings for the OASIS Security Assertion Markup Language (SAML) V2.0". OASIS SSTC, August 2004. Document ID sstc-saml-bindings-2.0-cd-01, WORK IN PROGRESS. See http://www.oasis-open.org/committees/security/ [SAMLv2Core] S. Cantor et al., "Assertions and Protocols for the OASIS Security Assertion Markup Language (SAML) V2.0". OASIS SSTC, August 2004. Document ID sstc-saml-core-2.0-cd-01, WORK IN PROGRESS. See http://www.oasis-open.org/committees/security/ [SAMLv2Meta] S. Cantor et al., Metadata for the OASIS Security Assertion Markup Language (SAML) V2.0. OASIS SSTC, August 2004. Document ID sstc-saml-metadata-2.0-cd-01. See http://www.oasis-open.org/committees/security/ [SAMLv2Prof] S. Cantor et al., "Profiles for the OASIS Security Assertion Markup Language (SAML) V2.0". OASIS SSTC, August 2004. Document ID sstc-saml-profiles-2.0-cd-01, WORK IN PROGRESS. See http://www.oasis-open.org/committees/security/ [SAMLv2Sec] F. Hirsch et al., "Security and Privacy Considerations for the OASIS Security Assertion Markup Language (SAML) V2.0". OASIS SSTC, August 2004, WORK IN PROGRESS. Document ID sstc-saml-sec-consider-2.0-cd-01. See http://www.oasis-open.org/committees/security/ [SSTC] "OASIS Security Services Technical Committee". See http://www.oasis-open.org/committees/security/ [XML] Bray, T., Paoli, J., Sperberg-McQueen, C.M. and E. Maler, "Extensible Markup Language (XML) 1.0 (Second Edition)", World Wide Web Consortium Recommendation REC-xml, October 2000, Available as http://www.w3.org/TR/REC-xml --- end

1 0

Re: DRAFT Registration of MIME media type application/samlassertion+xml
by Jeff.Hodges＠KingsMountain.com 23 Aug '04

23 Aug '04

oops, fixed a small-but-important bug: corrected MIME subtype name. JeffH ----- <NOTE: Registration of MIME media type application/samlassertion+xml sstc-saml-2.0-application-samlassertion-registration-00 Jeff Hodges <Jeff.Hodges(a)Sun.com> 21-Aug-2004 This document supersedes draft-hodges-saml-mediatype-02.txt. It is intended to be included in sstc-saml-bindings-2.0-cd-02 (ie the next time [SAMLv2Bind] is rev'd) as an appendix. For an overview of the intricities involved when a non-IETF organization registers a MIME media type in the "standards tree" (aka "IETF tree"), please see http://www.w3.org/2002/06/registering-mediatype.html. The below registration material is intended to satisfy the requirements stated in draft-freed-media-type-reg-01.txt (which superseded draft-freed-mime-p4-04.txt). This "NOTE" is intended to be removed upon copying this document's content into [SAMLv2Bind]. Acknowledgments: Thanks to Ned Freed and Larry Masinter for their comments on a prior draft of this registration. The security considerations section leverages that of http://www.iana.org/assignments/media-types/application/vnd.paos+xml, by John Kemp. > To: ietf-types(a)iana.org Subject: Registration of MIME media type application/samlassertion+xml Introduction This document defines a MIME media type -- application/samlassertion+xml -- for use with the XML serialization of SAML (Security Assertion Markup Language) assertions. The SAML specification sets -- [SAMLv1.0], [SAMLv1.1], [SAMLv2.0] -- are work products of the OASIS Security Services Technical Committee [SSTC]. The SAML specifications define XML-based constructs with which one may make, and convey, security assertions. Using SAML, one can assert that an authentication event pertaining to some subject has occured and convey said assertion to a relying party, for example. SAML assertions, which are explicitly versioned, are defined by [SAMLv1Core], [SAMLv11Core], and [SAMLv2Core]. MIME media type name: application MIME subtype name: samlassertion+xml Required parameters: none Optional parameters: charset Same as charset parameter of application/xml [RFC3023]. Encoding considerations: Same as for application/xml [RFC3023]. Security considerations: Per their specification, samlassertion+xml typed objects do not contain executable content. However, SAML assertions are XML-based objects [XML]. As such, they have all of the general security considerations presented in section 10 of [RFC3023], as well as additional ones, since they are explicit security objects. For example, samlassertion+xml typed objects will often contain data that may identify or pertain to a natural person, and may be used as a basis for sessions and access control decisions. To counter potential issues, samlassertion+xml typed objects contain data that should be signed appropriately by the sender. Any such signature must be verified by the recipient of the data - both as a valid signature, and as being the signature of the sender. Issuers of samlassertion+xml objects containing SAMLv2 assertions may also encrypt all, or portions of, the assertions [SAMLv2Core]. In addition, SAML profiles and protocol bindings specify use of secure channels as appropriate. [SAMLv2.0] incorporates various privacy-protection techniques in its design. For example: opaque handles, specific to interactions between specific system entities, are assigned to subjects. The handles are mappable to wider-context identifiers (e.g. email addresses, account identifiers, etc) by only the specific parties. For a more detailed discussion of SAML security considerations and specific security-related design techniques, please refer to the SAML specifications listed in the below bibliography. The specifications containing security-specific information have been explicitly listed for each version of SAML. Interoperability considerations: SAML assertions are explicitly versioned. Relying parties should ensure that they observe assertion version information and behave accordingly. See "Chapter 4 SAML Versioning" in [SAMLv1Core], [SAMLv11Core], or [SAMLv2Core], as appropriate. Published specification: [SAMLv2Bind] explicitly specifies use of the application/samlassertion+xml MIME media type. However, it is conceivable that non-SAMLv2 assertions (i.e. SAMLv1 and/or SAMLv1.1) might in practice be conveyed using SAMLv2 bindings. Applications which use this media type: Potentially any application implementing SAML, as well as those applications implementing specifications based on SAML, e.g. those available from the Liberty Alliance [LAP]. Additional information: Magic number(s): In general, the same as for application/xml [RFC3023]. In particular, the XML root element of the returned object will be <saml:Assertion>, where "saml" maps to a version-specific SAML assertion namespace, as defined by the appropriate SAML "core" specification (see bibliography). In the case of SAMLv2.0, the root element of the returned object may be either <saml:Assertion> or <saml:EncryptedAssertion>, where "saml" maps to the SAMLv2.0 assertion namespace: urn:oasis:names:tc:SAML:2.0:assertion File extension(s): none Macintosh File Type Code(s): none Person & email address to contact for further information: This registration is made on behalf of the OASIS Security Services Technical Committee (SSTC) Please refer to the SSTC website for current information on committee chairperson(s) and their contact addresses: http://www.oasis-open.org/committees/security/. Committee members should submit comments and potential errata to the securityservices(a)lists.oasis-open.org list. Others should submit them by filling out the web form located at http://www.oasis-open.org/committees/comments/form.php?wg_abbrev=secur Additionally, the SAML developer community email distribution list, saml-dev(a)lists.oasis-open.org, may be employed to discuss usage of the application/samlassertion+xml MIME media type. The "saml-dev" mailing list is publicly archived here: http://lists.oasis-open.org/archives/saml-dev/. To post to the "saml-dev" mailing list, one must subscribe to it. To subscribe, send a message with the single word "subscribe" in the message body, to: saml-dev-request(a)lists.oasis-open.org. Intended usage: COMMON Author/Change controller: The SAML specification sets are a work product of the OASIS Security Services Technical Committee (SSTC). OASIS and the SSTC have change control over the SAML specification sets. Bibliography [LAP] "Liberty Alliance Project". See http://www.projectliberty.org/ [OASIS] "Organization for the Advancement of Structured Information Systems". See http://www.oasis-open.org/ [RFC3023] M. Murata, S. St.Laurent, D. Kohn, "XML Media Types", IETF Request for Comments 3023, January 2001. Available as http://www.rfc-editor.org/rfc/rfc3023.txt [SAMLv1.0] OASIS Security Services Technical Committee, "Security Assertion Markup Language (SAML) Version 1.0 Specification Set". OASIS Standard 200205, November 2002. Available as http://www.oasis-open.org/committees/download.php/2290/ oasis-sstc-saml-1.0.zip [SAMLv1Bind] Prateek Mishra et al., "Bindings and Profiles for the OASIS Security Assertion Markup Language (SAML)", OASIS, November 2002. Document ID oasis-sstc-saml-bindings-1.0. See http://www.oasis-open.org/committees/security/ [SAMLv1Core] Phillip Hallam-Baker et al., "Assertions and Protocol for the OASIS Security Assertion Markup Language (SAML)", OASIS, November 2002. Document ID oasis-sstc-saml-core-1.0. See http://www.oasis-open.org/committees/security/ [SAMLv1Sec] Chris McLaren et al., "Security Considerations for the OASIS Security Assertion Markup Language (SAML)", OASIS, November 2002. Document ID oasis-sstc-saml-sec-consider-1.0. See http://www.oasis-open.org/committees/security/ [SAMLv1.1] OASIS Security Services Technical Committee, "Security Assertion Markup Language (SAML) Version 1.1 Specification Set". OASIS Standard 200308, August 2003. Available as http://www.oasis-open.org/committees/download.php/3400/ oasis-sstc-saml-1.1-pdf-xsd.zip [SAMLv11Bind] E. Maler et al. "Bindings and Profiles for the OASIS Security Assertion Markup Language (SAML)". OASIS, September 2003. Document ID oasis-sstc-saml-bindings-1.1. http://www.oasis-open.org/committees/security/ [SAMLv11Core] E. Maler et al. "Assertions and Protocol for the OASIS Security Assertion Markup Language (SAML)". OASIS, September 2003. Document ID oasis-sstc-saml-core-1.1. http://www.oasis-open.org/committees/security/ [SAMLv11Sec] E. Maler et al. "Security Considerations for the OASIS Security Assertion Markup Language (SAML)". OASIS, September 2003. Document ID oasis-sstc-saml-sec-consider-1.1. http://www.oasis-open.org/committees/security/ [SAMLv2.0] OASIS Security Services Technical Committee, "Security Assertion Markup Language (SAML) Version 2.0 Specification Set". WORK IN PROGRESS. Available at http://www.oasis-open.org/committees/security/ [SAMLv2Bind] S. Cantor et al., "Bindings for the OASIS Security Assertion Markup Language (SAML) V2.0". OASIS SSTC, August 2004. Document ID sstc-saml-bindings-2.0-cd-01, WORK IN PROGRESS. See http://www.oasis-open.org/committees/security/ [SAMLv2Core] S. Cantor et al., "Assertions and Protocols for the OASIS Security Assertion Markup Language (SAML) V2.0". OASIS SSTC, August 2004. Document ID sstc-saml-core-2.0-cd-01, WORK IN PROGRESS. See http://www.oasis-open.org/committees/security/ [SAMLv2Prof] S. Cantor et al., "Profiles for the OASIS Security Assertion Markup Language (SAML) V2.0". OASIS SSTC, August 2004. Document ID sstc-saml-profiles-2.0-cd-01, WORK IN PROGRESS. See http://www.oasis-open.org/committees/security/ [SAMLv2Sec] F. Hirsch et al., "Security and Privacy Considerations for the OASIS Security Assertion Markup Language (SAML) V2.0". OASIS SSTC, August 2004, WORK IN PROGRESS. Document ID sstc-saml-sec-consider-2.0-cd-01. See http://www.oasis-open.org/committees/security/ [SSTC] "OASIS Security Services Technical Committee". See http://www.oasis-open.org/committees/security/ [XML] Bray, T., Paoli, J., Sperberg-McQueen, C.M. and E. Maler, "Extensible Markup Language (XML) 1.0 (Second Edition)", World Wide Web Consortium Recommendation REC-xml, October 2000, Available as http://www.w3.org/TR/REC-xml

1 0

DRAFT Registration of MIME media type application/samlassertion+xml
by Jeff Hodges 21 Aug '04

21 Aug '04

comments appreciated... thanks, JeffH ----- <NOTE: Registration of MIME media type application/samlassertion+xml sstc-saml-2.0-application-samlassertion-registration-00 Jeff Hodges <Jeff.Hodges(a)Sun.com> 21-Aug-2004 This document supersedes draft-hodges-saml-mediatype-02.txt. It is intended to be included in sstc-saml-bindings-2.0-cd-02 (ie the next time [SAMLv2Bind] is rev'd) as an appendix. For an overview of the intricities involved when a non-IETF organization registers a MIME media type in the "standards tree" (aka "IETF tree"), please see http://www.w3.org/2002/06/registering-mediatype.html. The below registration material is intended to satisfy the requirements stated in draft-freed-media-type-reg-01.txt (which superseded draft-freed-mime-p4-04.txt). This "NOTE" is intended to be removed upon copying this document's content into [SAMLv2Bind]. Acknowledgments: Thanks to Ned Freed and Larry Masinter for their comments on a prior draft of this registration. The security considerations section leverages that of http://www.iana.org/assignments/media-types/application/vnd.paos+xml, by John Kemp. > To: ietf-types(a)iana.org Subject: Registration of MIME media type application/samlassertion+xml Introduction This document defines a MIME media type -- application/samlassertion+xml -- for use with the XML serialization of SAML (Security Assertion Markup Language) assertions. The SAML specification sets -- [SAMLv1.0], [SAMLv1.1], [SAMLv2.0] -- are work products of the OASIS Security Services Technical Committee [SSTC]. The SAML specifications define XML-based constructs with which one may make, and convey, security assertions. Using SAML, one can assert that an authentication event pertaining to some subject has occured and convey said assertion to a relying party, for example. SAML assertions, which are explicitly versioned, are defined by [SAMLv1Core], [SAMLv11Core], and [SAMLv2Core]. MIME media type name: application MIME subtype name: saml+xml Required parameters: none Optional parameters: charset Same as charset parameter of application/xml [RFC3023]. Encoding considerations: Same as for application/xml [RFC3023]. Security considerations: Per their specification, samlassertion+xml typed objects do not contain executable content. However, SAML assertions are XML-based objects [XML]. As such, they have all of the general security considerations presented in section 10 of [RFC3023], as well as additional ones, since they are explicit security objects. For example, samlassertion+xml typed objects will often contain data that may identify or pertain to a natural person, and may be used as a basis for sessions and access control decisions. To counter potential issues, samlassertion+xml typed objects contain data that should be signed appropriately by the sender. Any such signature must be verified by the recipient of the data - both as a valid signature, and as being the signature of the sender. Issuers of samlassertion+xml objects containing SAMLv2 assertions may also encrypt all, or portions of, the assertions [SAMLv2Core]. In addition, SAML profiles and protocol bindings specify use of secure channels as appropriate. [SAMLv2.0] incorporates various privacy-protection techniques in its design. For example: opaque handles, specific to interactions between specific system entities, are assigned to subjects. The handles are mappable to wider-context identifiers (e.g. email addresses, account identifiers, etc) by only the specific parties. For a more detailed discussion of SAML security considerations and specific security-related design techniques, please refer to the SAML specifications listed in the below bibliography. The specifications containing security-specific information have been explicitly listed for each version of SAML. Interoperability considerations: SAML assertions are explicitly versioned. Relying parties should ensure that they observe assertion version information and behave accordingly. See "Chapter 4 SAML Versioning" in [SAMLv1Core], [SAMLv11Core], or [SAMLv2Core], as appropriate. Published specification: [SAMLv2Bind] explicitly specifies use of the application/samlassertion+xml MIME media type. However, it is conceivable that non-SAMLv2 assertions (i.e. SAMLv1 and/or SAMLv1.1) might in practice be conveyed using SAMLv2 bindings. Applications which use this media type: Potentially any application implementing SAML, as well as those applications implementing specifications based on SAML, e.g. those available from the Liberty Alliance [LAP]. Additional information: Magic number(s): In general, the same as for application/xml [RFC3023]. In particular, the XML root element of the returned object will be <saml:Assertion>, where "saml" maps to a version-specific SAML assertion namespace, as defined by the appropriate SAML "core" specification (see bibliography). In the case of SAMLv2.0, the root element of the returned object may be either <saml:Assertion> or <saml:EncryptedAssertion>, where "saml" maps to the SAMLv2.0 assertion namespace: urn:oasis:names:tc:SAML:2.0:assertion File extension(s): none Macintosh File Type Code(s): none Person & email address to contact for further information: This registration is made on behalf of the OASIS Security Services Technical Committee (SSTC) Please refer to the SSTC website for current information on committee chairperson(s) and their contact addresses: http://www.oasis-open.org/committees/security/. Committee members should submit comments and potential errata to the securityservices(a)lists.oasis-open.org list. Others should submit them by filling out the web form located at http://www.oasis-open.org/committees/comments/form.php?wg_abbrev=secur Additionally, the SAML developer community email distribution list, saml-dev(a)lists.oasis-open.org, may be employed to discuss usage of the application/samlassertion+xml MIME media type. The "saml-dev" mailing list is publicly archived here: http://lists.oasis-open.org/archives/saml-dev/. To post to the "saml-dev" mailing list, one must subscribe to it. To subscribe, send a message with the single word "subscribe" in the message body, to: saml-dev-request(a)lists.oasis-open.org. Intended usage: COMMON Author/Change controller: The SAML specification sets are a work product of the OASIS Security Services Technical Committee (SSTC). OASIS and the SSTC have change control over the SAML specification sets. Bibliography [LAP] "Liberty Alliance Project". See http://www.projectliberty.org/ [OASIS] "Organization for the Advancement of Structured Information Systems". See http://www.oasis-open.org/ [RFC3023] M. Murata, S. St.Laurent, D. Kohn, "XML Media Types", IETF Request for Comments 3023, January 2001. Available as http://www.rfc-editor.org/rfc/rfc3023.txt [SAMLv1.0] OASIS Security Services Technical Committee, "Security Assertion Markup Language (SAML) Version 1.0 Specification Set". OASIS Standard 200205, November 2002. Available as http://www.oasis-open.org/committees/download.php/2290/ oasis-sstc-saml-1.0.zip [SAMLv1Bind] Prateek Mishra et al., "Bindings and Profiles for the OASIS Security Assertion Markup Language (SAML)", OASIS, November 2002. Document ID oasis-sstc-saml-bindings-1.0. See http://www.oasis-open.org/committees/security/ [SAMLv1Core] Phillip Hallam-Baker et al., "Assertions and Protocol for the OASIS Security Assertion Markup Language (SAML)", OASIS, November 2002. Document ID oasis-sstc-saml-core-1.0. See http://www.oasis-open.org/committees/security/ [SAMLv1Sec] Chris McLaren et al., "Security Considerations for the OASIS Security Assertion Markup Language (SAML)", OASIS, November 2002. Document ID oasis-sstc-saml-sec-consider-1.0. See http://www.oasis-open.org/committees/security/ [SAMLv1.1] OASIS Security Services Technical Committee, "Security Assertion Markup Language (SAML) Version 1.1 Specification Set". OASIS Standard 200308, August 2003. Available as http://www.oasis-open.org/committees/download.php/3400/ oasis-sstc-saml-1.1-pdf-xsd.zip [SAMLv11Bind] E. Maler et al. "Bindings and Profiles for the OASIS Security Assertion Markup Language (SAML)". OASIS, September 2003. Document ID oasis-sstc-saml-bindings-1.1. http://www.oasis-open.org/committees/security/ [SAMLv11Core] E. Maler et al. "Assertions and Protocol for the OASIS Security Assertion Markup Language (SAML)". OASIS, September 2003. Document ID oasis-sstc-saml-core-1.1. http://www.oasis-open.org/committees/security/ [SAMLv11Sec] E. Maler et al. "Security Considerations for the OASIS Security Assertion Markup Language (SAML)". OASIS, September 2003. Document ID oasis-sstc-saml-sec-consider-1.1. http://www.oasis-open.org/committees/security/ [SAMLv2.0] OASIS Security Services Technical Committee, "Security Assertion Markup Language (SAML) Version 2.0 Specification Set". WORK IN PROGRESS. Available at http://www.oasis-open.org/committees/security/ [SAMLv2Bind] S. Cantor et al., "Bindings for the OASIS Security Assertion Markup Language (SAML) V2.0". OASIS SSTC, August 2004. Document ID sstc-saml-bindings-2.0-cd-01, WORK IN PROGRESS. See http://www.oasis-open.org/committees/security/ [SAMLv2Core] S. Cantor et al., "Assertions and Protocols for the OASIS Security Assertion Markup Language (SAML) V2.0". OASIS SSTC, August 2004. Document ID sstc-saml-core-2.0-cd-01, WORK IN PROGRESS. See http://www.oasis-open.org/committees/security/ [SAMLv2Prof] S. Cantor et al., "Profiles for the OASIS Security Assertion Markup Language (SAML) V2.0". OASIS SSTC, August 2004. Document ID sstc-saml-profiles-2.0-cd-01, WORK IN PROGRESS. See http://www.oasis-open.org/committees/security/ [SAMLv2Sec] F. Hirsch et al., "Security and Privacy Considerations for the OASIS Security Assertion Markup Language (SAML) V2.0". OASIS SSTC, August 2004, WORK IN PROGRESS. Document ID sstc-saml-sec-consider-2.0-cd-01. See http://www.oasis-open.org/committees/security/ [SSTC] "OASIS Security Services Technical Committee". See http://www.oasis-open.org/committees/security/ [XML] Bray, T., Paoli, J., Sperberg-McQueen, C.M. and E. Maler, "Extensible Markup Language (XML) 1.0 (Second Edition)", World Wide Web Consortium Recommendation REC-xml, October 2000, Available as http://www.w3.org/TR/REC-xml --- end

1 0

draft-hodges-saml-mediatype-01
by Jeff Hodges 21 Aug '04

21 Aug '04

Any feedback on the below draft? thanks, JeffH ----- http://www.ietf.org/internet-drafts/draft-hodges-saml-mediatype-01.txt ----------------------------------------------------------------------------- Network Working Group J. Hodges Internet-Draft Sun Microsystems, Inc. Expires: December 16, 2004 June 17, 2004 application/saml+xml Media Type Registration draft-hodges-saml-mediatype-01 Status of this Memo By submitting this Internet-Draft, I certify that any applicable patent or other IPR claims of which I am aware have been disclosed, and any of which I become aware will be disclosed, in accordance with RFC 3667. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http:// www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This Internet-Draft will expire on December 16, 2004. Copyright Notice Copyright (C) The Internet Society (2004). All Rights Reserved. Abstract This document describes a MIME media type -- application/saml+xml -- for use with the XML serialization of SAML (Security Assertion Markup Language) assertions, or other SAML-defined objects. Hodges Expires December 16, 2004 [Page 1] Internet-Draft application/saml+xml June 2004 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1.1 Discussion of this Document . . . . . . . . . . . . . . . 3 1.2 Document Conventions . . . . . . . . . . . . . . . . . . . 3 2. Usage of the application/saml+xml MIME Media Type . . . . . . 4 3. application/saml+xml MIME Media Type Registration . . . . . . 4 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6 5. Security Considerations . . . . . . . . . . . . . . . . . . . 6 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 6 Normative References . . . . . . . . . . . . . . . . . . . . . 6 Informative References . . . . . . . . . . . . . . . . . . . . 8 Author's Address . . . . . . . . . . . . . . . . . . . . . . . 8 A. Revision History . . . . . . . . . . . . . . . . . . . . . . . 8 Intellectual Property and Copyright Statements . . . . . . . . 9 Hodges Expires December 16, 2004 [Page 2] Internet-Draft application/saml+xml June 2004 1. Introduction This document defines a MIME media type -- application/saml+xml -- for use with the XML serialization of SAML (Security Assertion Markup Language) assertions, or other SAML-defined objects. The SAML specification sets, SAML V1.0 [5] and SAML V1.1 [9], are work products of the OASIS [13] Security Services Technical Committee (SSTC) [14]. The SAML specifications define XML-based constructs with which one may make, and convey, security assertions. For example, one can assert that an authentication event pertaining to some subject has occured and convey said assertion to a relying party. 1.1 Discussion of this Document Please send comments on this document to the "security services comment" email distribution list: <mailto:security-services-comment@lists.oasis-open.org> The "security services comment" mailing list is publically archived here [15]. To post to the "security services comment" mailing list, one must subscribe to it. To subscribe, send a message with the single word "subscribe" in the message body, to: <mailto:security-services-comment-request@lists.oasis-open.org> Additionally, the SAML developer community email distribution list: <mailto:saml-dev@lists.oasis-open.org> may be employed to discuss usage of the application/saml+xml MIME media type. The "saml-dev" mailing list is publically archived here [16]. To post to the "saml-dev" mailing list, one must subscribe to it. To subscribe, send a message with the single word "subscribe" in the message body, to: <mailto:saml-dev-request@lists.oasis-open.org> 1.2 Document Conventions The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", Hodges Expires December 16, 2004 [Page 3] Internet-Draft application/saml+xml June 2004 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [2]. 2. Usage of the application/saml+xml MIME Media Type Application protocols capable of conveying MIME entities, such as HTTP [3], SHOULD use the media type defined in this document when conveying SAML-defined objects. 3. application/saml+xml MIME Media Type Registration This is a media type registration as defined in Multipurpose Internet Mail Extensions (MIME) Part Four: Registration Procedures [1] and XML Media Types [4]. MIME media type name: application MIME subtype name: saml+xml Required parameters: none Optional parameters: charset Same as charset parameter of application/xml. Encoding considerations: Same as charset parameter of application/xml. Security considerations: Security considerations include many of those described in section 10 of RFC 3023 [4] as well as those specifically described in: SAML V1.0 Assertions and Protocol [6] SAML V1.0 Bindings and Profiles [7] SAML V1.0 Security and Privacy Considerations [8] ..and/or.. Hodges Expires December 16, 2004 [Page 4] Internet-Draft application/saml+xml June 2004 SAML V1.1 Assertions and Protocol [10] SAML V1.1 Bindings and Profiles [11] SAML V1.1 Security and Privacy Considerations [12] . ..depending on the version of the SAML object (see the next item). Interoperability considerations: SAML assertions are explicitly versioned. Relying parties SHOULD ensure that they observe assertion version information and behave accordingly. See "Chapter 4 SAML Versioning" in SAML V1.0 Assertions and Protocol [6], and/or SAML V1.1 Assertions and Protocol [10], as appropriate. Published specification: See the SAML V1.0 [5] and SAML V1.1 [9] specification sets. Applications which use this media type: SAML is device-, platform-, and vendor-neutral and is supported by a range of server- and client-side applications and tools. Additional information: Magic number(s): none, but.. Although no byte sequences can be counted on to consistently identify SAML objects, i.e. assertions and/or protocol messages, they will contain either one, or both of, the strings: urn:oasis:names:tc:SAML:1.0:assertion urn:oasis:names:tc:SAML:1.0:protocol to identify the SAML XML namespace(s). File extension(s): none Macintosh File Type Code(s): none Hodges Expires December 16, 2004 [Page 5] Internet-Draft application/saml+xml June 2004 Person & email address to contact for further information: Use the email distribution lists identified in Section 1.1 above. Additionally, or otherwise, refer to the Security Services Technical Committee website [14]. Intended usage: COMMON Author/Change controller: The SAML specification sets are a work product of the OASIS Security Services Technical Committee (SSTC). OASIS and the SSTC have change control over the SAML specification sets. 4. IANA Considerations This document calls for registration of a new MIME content-type, according to the registration information given above in Section 3. 5. Security Considerations See the "Security Considerations" item in Section 3 above. 6. Acknowledgements This doc is based on Aaron Schwartz' internet-draft for the application/rdf+xml MIME media type [18]. Thanks to Graham Klyne for pointing me to the latter, to Scott Cantor and John Kemp for volunteering me to write this, and to Marshall Rose for his xml2rfc document converter gizmo [17]. Artists whose music contributed to the writing of this spec ranged from John Coltrane [19] to Trapt [20]. Normative References [1] Freed, N., Klensin, J. and J. Postel, "Multipurpose Internet Mail Extensions (MIME) Part Four: Registration Procedures", BCP 13, RFC 2048, November 1996. [2] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [3] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., Masinter, L., Leach, P. and T. Berners-Lee, "Hypertext Transfer Protocol -- Hodges Expires December 16, 2004 [Page 6] Internet-Draft application/saml+xml June 2004 HTTP/1.1", RFC 2616, June 1999. [4] Murata, M., St. Laurent, S. and D. Kohn, "XML Media Types", RFC 3023, January 2001. [5] OASIS, "Security Assertion Markup Language (SAML) Version 1.0 Specification Set", OASIS Standard 200205, September 2003, <http://www.oasis-open.org/committees/download.php/2290/ oasis-sstc-saml-1.0.zip>. [6] Hallam-Baker, P., Ed. and E. Maler, Ed., "Assertions and Protocol for the OASIS Security Assertion Markup Language (SAML) V1.0", OASIS Standard 200205, November 2002, <http:// www.oasis-open.org/apps/org/workgroup/security/download.php/ 1371/oasis-sstc-saml-core-1.0.pdf>. [7] Mishra, P., Ed., "Bindings and Profiles for the OASIS Security Assertion Markup Language (SAML) V1.0", OASIS Standard 200205, November 2002, <http://www.oasis-open.org/apps/org/workgroup/ security/download.php/1372/oasis-sstc-saml-bindings-1.0.pdf>. [8] McLaren, C., Ed., "Security and Privacy Considerations for the OASIS Security Assertion Markup Language (SAML) V1.0", OASIS Standard 200205, November 2002, <http://www.oasis-open.org/ apps/org/workgroup/security/download.php/1375/ oasis-sstc-saml-sec-consider-1.0.pdf>. [9] OASIS, "Security Assertion Markup Language (SAML) Version 1.1 Specification Set", OASIS Standard 200308, September 2003, <http://www.oasis-open.org/committees/download.php/3400/ oasis-sstc-saml-1.1-pdf-xsd.zip>. [10] Maler, E., Ed., Mishra, P., Ed. and R. Philpott, Ed., "Assertions and Protocol for the OASIS Security Assertion Markup Language (SAML) V1.1", OASIS Standard 200308, September 2003, <http://www.oasis-open.org/apps/org/workgroup/security/ download.php/3406/oasis-sstc-saml-core-1.1.pdf>. [11] Maler, E., Ed., Mishra, P., Ed. and R. Philpott, Ed., "Bindings and Profiles for the OASIS Security Assertion Markup Language (SAML) V1.1", OASIS Standard 200308, September 2003, <http:// www.oasis-open.org/apps/org/workgroup/security/download.php/ 3405/oasis-sstc-saml-bindings-1.1.pdf>. [12] Maler, E., Ed. and R. Philpott, Ed., "Security and Privacy Considerations for the OASIS Security Assertion Markup Language (SAML) V1.1", OASIS Standard 200308, September 2003, <http://www.oasis-open.org/apps/org/workgroup/security/ Hodges Expires December 16, 2004 [Page 7] Internet-Draft application/saml+xml June 2004 download.php/3404/oasis-sstc-saml-sec-consider-1.1.pdf>. Informative References [13] "Organization for the Advancement of Structured Information Systems (OASIS)", <http://www.oasis-open.org/>. [14] "Security Services Technical Committee (SSTC/SAML)", <http:// www.oasis-open.org/committees/security/>. [15] "SSTC/SAML 'comment' Mailing List Archives", <http:// lists.oasis-open.org/archives/security-services-comment/>. [16] "SSTC/SAML 'saml-dev' Mailing List Archives", <http:// lists.oasis-open.org/archives/saml-dev/>. [17] "Marshall Rose's xml2rfc tool", <http://xml.resource.org>. URIs [18] <http://www.aaronsw.com/2002/ draft-w3c-rdfcore-rdfxml-mediatype-01> [19] <http://www.johncoltrane.com/> [20] <http://www.trapt.com/> Author's Address Jeff Hodges Sun Microsystems, Inc. 4220 Network Circle, Bldg 22, USCA22-212 Santa Clara, CA 95054 USA Phone: +1 408.276.5467 EMail: Jeff.Hodges(a)sun.com URI: http://www.sun.com/ Appendix A. Revision History Hodges Expires December 16, 2004 [Page 8] Internet-Draft application/saml+xml June 2004 Intellectual Property Statement The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the IETF's procedures with respect to rights in IETF Documents can be found in BCP 78 and BCP 79. Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr(a)ietf.org. Disclaimer of Validity This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Copyright Statement Copyright (C) The Internet Society (2004). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights. Acknowledgment Funding for the RFC Editor function is currently provided by the Internet Society. Hodges Expires December 16, 2004 [Page 9] -----------------------------------------------------------------------------

2 2

Re: draft-hodges-saml-mediatype-01
by Jeff.Hodges＠KingsMountain.com 21 Aug '04

21 Aug '04

Larry -- thanks for the feedback on that earlier I-D, it was helpful. I'll post a revision to draft-hodges-saml-mediatype-01 (but no longer in the form of an I-D) in a subsequent message. JeffH

1 0

fyi: draft-freed-mime-p4-04 morphs into draft-freed-media-type-reg-01 and draft-freed-mime-p4-05
by Jeff.Hodges＠KingsMountain.com 20 Aug '04

20 Aug '04

Note that draft-freed-mime-p4-04 has been apparently superseded by draft-freed-media-type-reg-01 and draft-freed-mime-p4-05 MartinD -- your nice page.. http://www.w3.org/2002/06/registering-mediatype.html ..will need some minor updating. JeffH

1 0