- Ietf-types - alvestrand.no

for review: draft -02 of application/samlassertion+xml registration
by Jeff.Hodges＠KingsMountain.com 20 Sep '04

20 Sep '04

Registration of MIME media type application/samlassertion+xml <@@NOTE: This document is: sstc-saml-2.0-application-samlassertion-registration-02 Jeff Hodges <Jeff.Hodges(a)Sun.com> 20-Sep-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. 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 [SAMLv2Bind]. Acknowledgments: Thanks to Ned Freed, Larry Masinter, Graham Klyne, and Chris Lilley for their comments on prior drafts 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, may be 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 <Assertion>, and will be in one of the version-specific SAML assertion XML namespaces, as defined by the appropriate version-specific SAML "core" specification (see bibliography). With SAMLv2.0 specifically, the root element of the returned object may be either <saml:Assertion> or <saml:EncryptedAssertion>,where "saml" represents any XML namespace prefix that maps to the SAMLv2.0 assertion namespace URI: 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= 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

Re: Please review: DRAFT Reg of application/samlassertion+xml
by Graham Klyne 20 Sep '04

20 Sep '04

Jeff, That wording looks OK to me. One additional point to consider, but I think it's marginal: the case when the default namespace is a SAML namespace. (In practice, I think anyone who knows enough about XML to use this stuff will understand that case is implied, but maybe it's better to be explicit.) #g -- At 11:52 06/09/04 -0700, you wrote: > > I'm a bit concerned that this might be read as asserting that a > > application/samlassertion+xml object must use the specific namespace > prefix > > "saml", rather than any namesp[ace prefix that maps to a SAML namespace > URI. > > >good catch, thanks. > > > > Assuming this is not being claimed, I'd suggest: > > [[ > > 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" as any namespace prefix that > maps > > to a version-specific SAML assertion namespace URI, 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" is a prefix that maps to the SAMLv2.0 assertion > > namespace URI: urn:oasis:names:tc:SAML:2.0:assertion. > > ]] > > >how 'bout this build: > > > 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" represents any XML namespace > prefix that maps to a version-specific SAML assertion XML > namespace URI, as defined by the appropriate version-specific > SAML "core" specification (see bibliography). > > With SAMLv2.0 specifically, the root element of the returned > object may be either <saml:Assertion> or > <saml:EncryptedAssertion> >, > where "saml" is an XML namspace prefix that maps to the SAMLv2.0 > assertion namespace URI: urn:oasis:names:tc:SAML:2.0:assertion. > > >? > >thanks, > >JeffH ------------ Graham Klyne For email: http://www.ninebynine.org/#Contact

2 1

Registration for application/gdiff
by Lisa Dusseault 16 Sep '04

16 Sep '04

I'm trying to register a MIME type officially for application/gdiff. This type was defined in a W3C NOTE several years ago: <http://www.w3.org/TR/NOTE-gdiff-19970901> That Note defines the MIME type but apparently the authors never registered the MIME type with IANA. Now we'd like to use gdiff in applications where we'd be using the MIME type so having it officially registered would be nice. For example: <http://www.ietf.org/internet-drafts/draft-dusseault-http-patch-03.txt> (try -04 if -03 turns up not found) I submitted the registration through the IANA web form a couple weeks ago but haven't gotten a response other than the automated form submission response. Is this smoothly underway or is there anything else I need to or can optionally do to help this registration out? Thanks, Lisa

2 1

Request For Registration of Media Type
by Marc Clifton 16 Sep '04

16 Sep '04

2 1

Comments on draft-freed-media-types-reg-01.txt
by Even, Roni 13 Sep '04

13 Sep '04

Hi, Reading the document and looking at the IANA database I noticed that the media types do not include "data" and "control". The current SDP draft has in section 9 9.2.1 Media types ("media") The set of media types is intended to be small and SHOULD NOT be extended except under rare circumstances. The same rules should apply for media names as for top-level MIME content types, and where possible the same name should be registered for SDP as for MIME. For media other than existing MIME top-level content types, a standards-track RFC MUST be produced for a new top-level content type to be registered, and the registration MUST provide good justification why no existing media name is appropriate (the "Standards Action" policy of RFC 2434 [5]. This memo registers the media types "audio", "video", "text", "application", "data" and "control". So does it mean that in an RTP payload specification I will register a payload type as application and use in SDP m line as data? Roni Even ************************************************************* Roni Even Polycom Israel Tel: +972-3-9251200 Cell: +972-54-5481099 Fax: +972-3-9211571 *****************************************************************

2 1

Registration of media type text/3gpp-tt
by Jose Rey 13 Sep '04

13 Sep '04

Hello, please consider the following media type text/3gpp-tt for registration under the IETF tree. This section is copied from the draft http://www.ietf.org/internet-drafts/draft-ietf-avt-rtp-3gpp-timed-text-06.tx t. MIME type: text MIME subtype: 3gpp-tt Required parameters rate: the RTP timestamp clockrate is equal to the clockrate of the media. If RTP packets are generated out of a 3GP file, the clockrate of the text media MUST be copied from the 3GP file, i.e. the clockrate is the value of "timescale" parameter in the Media Header Box describing that text track. Other tracks (audio/video/text) in the 3GP file may have their own clockrates as indicated in their corresponding Media Header Box. For live encoding, a clockrate of 1000 Hz is RECOMMENDED but other values MAY be used. If a different timestamp rate value is used, this MUST be chosen carefully as per Section 3 in RFCXXXX. sver: The parameter "sver" contains a list of supported backwards-compatible versions of the timed text format specification (3GPP TS 26.245) that the sender accepts to receive (and which are the same that it would be willing to send). The first value is the value preferred to be received ( or preferred to send). The first value MAY be followed by a comma-separated list of versions that SHOULD be used as alternatives. The order is meaningful, being first the most preferred and last the least preferred. Each entry has the format Zi(xi*256+yi), where "Zi" is the number of the Release, "xi" and "yi" are taken from the 3GPP specification version, i.e. vZi.xi.yi. For example, for 3GPP TS 26.245 v6.0.0, Zi(xi*256+yi)=6(0), the version value is "60". (Note that "60" is the concatenation of the values Zi=6 and (xi*256+yi)=0 and not its product.) width: This parameter indicates the width in pixels of the text track or area of the text being sent. This is a 16 bit integer. height: This parameter indicates the height in pixels of the text track being sent. This is a 16 bit integer. max-w: This parameter indicates display capabilities. This is the maximum "width" value that the sender of this parameter supports. This is a 16 bit unsigned integer. max-h: This parameter indicates display capabilities. This is the maximum "height" value that the sender of this parameter supports. This is a 16 bit unsigned integer. tx: This parameter indicates the horizontal translation offset in pixels of the text track with respect to the origin of the video track. This is a 16 bit integer. ty: This parameter indicates the vertical translation offset in pixels of the text track with respect to the origin of the video track. This is a 16 bit integer. layer: This parameter indicates the proximity of the text track to the viewer. More negative values mean closer to the viewer. This parameter has no units. This is a 16 bit integer. Optional parameters: tx3g: This parameter MUST be used for conveying sample descriptions out-of-band. It contains a comma-separated list of base64-encoded entries. The entries of this list that MAY follow any particular order and the list MAY be empty. The absence of this parameter is equivalent to an empty list of sample descriptions. Each entry is the result of running base64 encoding over the concatenation of the SIDX and the sample description for that SIDX, in this order. The format of a sample description entry can be found in 3GPP TS 26.245 Release 6 and later releases. All servers and clients MUST understand this parameter and MUST be capable of using the sample description(s) contained in it. Please refer to RFC 3548 [6] for details on the base64 encoding. Encoding considerations: RTP payloads complying with this payload format contain binary data. Note that this type is incompatible with the use of text media types in other protocols, e.g. text/html. This is because in order to extract and decode any of the timed text media it is necessary understand the (binary) payload headers defined in RFCXXXX. Restrictions on usage: This type is only defined for transfer via RTP. Security considerations: Please refer to Section 10 of RFCXXXX. Interoperability considerations: The 3GPP Timed Text media format for which this payload format is defined is specified in Release 6 of 3GPP TS 26.245 "Transparent end-to-end packet switched streaming service (PSS); Timed Text Format (Release 6)". The 3GPP file format (3GP) and the SMIL language profile used can be found in Release 5 of 3GPP TS 26.234 and in the corresponding specifications for later Releases. Note also that 3GPP may in future Releases specify extensions or updates to the media format in a backwards- compatible way, e.g. new modifier boxes or extensions to the sample descriptions. The payload format defined in RFCXXXX Rey & Matsui [Page 29] Internet Draft Payload Format for 3GPP Timed Text September 10, 2004 allows for such extensions. For future 3GPP Releases of the Timed Text Format, the parameter "sver" is used to identify the exact specification used. Published specification: RFC XXXX Applications which use this media type: Multimedia streaming applications. Additional information: the 3GPP Timed Text media format is specified in 3GPP TS 26.245 "Transparent end-to-end packet switched streaming service (PSS); Timed Text Format (Release 6)". This document and future extensions to the 3GPP Timed Text format are publicly available at http://www.3gpp.org. Magic number(s): None. File extension(s): None. Macintosh File Type Code(s): None. Person & email address to contact for further information: Jose Rey, rey(a)panasonic.de Yoshinori Matsui, matsui.yoshinori(a)jp.panasonic.com Audio/Video Transport Working Group. Intended usage: COMMON Author/Change controller: Jose Rey Yoshinori Matsui IETF AVT WG Thank, --------------------------------- Jose Rey Mobile Multimedia Team Panasonic R&D Center Germany GmbH D-63225 Langen, Germany Tel.:+49-6103-766-134 Fax :+49-6103-766-166 Email: rey(a)panasonic.de Web: www.prdcg.panasonic.de ---------------------------------

1 0

Re: Comments on draft-freed-media-types-reg-01.txt
by ned.freed＠mrochek.com 12 Sep '04

12 Sep '04

> I recently had the please of reading and trying to use the I-D and it is in > very good shape. My "implementation experience" input is: > * However robust the x. and x- discussion text becomes, it is essential that > x. continues to be allowed so that well behaved applications can reject non > registered types, without some other private agreement to use and x. instance. OK. > * I understand that the standards track RFC for Standards Tree registration > can be a dedicated RFC (start life as a dedicated I-D) OR included in the IANA > considerations section of a "not dedicated" RFC. Whether or not the latter case > is allowed, please state this explicitly (it's not so clear). I definitely > support allowing the MIME registration to be bundled with a wider purpose RFC > as surely that's what the IANA considerations sections are meant for anyway? I would have thought it obvious that registrations can either be standalone or they can be part of a more general specification. However, I have no problem making this explicit and will do in the next revision. > * It would be helpful to state whether or not the "bundled RFC" (and a > dedicated RFC) must use the syntax of the registration template or whether it > is sufficient to cover all those items (in the whole RFC or specifically in the > IANA considerations). As someone who has so far not registered any MIME types, > I couldn't say from draft-freed-media-types-reg-01 whether the template is for > a specific communication to IANA only (e.g. in an email). Actually, this is explicit in the document: The section on publications requirements says "Such specifications MUST contain an appropriate media type registration template." I'll add a pointer to the actual template. > * Which bring me to my final request, for a registration-newbie (like me) the > registration process is something of a black art and a newbie does not know > what action they must take. Does RFC Editor queue entry OR standards track RFC > publication OR email from RFC author actually initiate the IANA registration > process for Standards Tree? (i.e. does the individual or the IETF have to > translate the I-D/RFC into a request to IANA?) This is also fairly explicit in the current document. The section on registration procedures says "The normal IETF processes should be followed for all IETF registrations in the standards tree, with the posting of an internet-draft being a necessary first step." It is considerably beyond the scope of this document to cover the process of moving a document from Internet Draft to RFC. Ned

1 0

Re: [AVT] Re: Comments on draft-freed-media-types-reg-01.txt
by Colin Perkins 11 Sep '04

11 Sep '04

On 10 Sep 2004, at 10:24, Rod.Walsh(a)nokia.com wrote: > I recently had the please of reading and trying to use the I-D and it > is in very good shape. My "implementation experience" input is: ... > * I understand that the standards track RFC for Standards Tree > registration can be a dedicated RFC (start life as a dedicated I-D) OR > included in the IANA considerations section of a "not dedicated" RFC. > Whether or not the latter case is allowed, please state this > explicitly (it's not so clear). I definitely support allowing the MIME > registration to be bundled with a wider purpose RFC as surely that's > what the IANA considerations sections are meant for anyway? I hope so; this is how many RTP payload formats register their MIME type. > * It would be helpful to state whether or not the "bundled RFC" (and a > dedicated RFC) must use the syntax of the registration template or > whether it is sufficient to cover all those items (in the whole RFC or > specifically in the IANA considerations). As someone who has so far > not registered any MIME types, I couldn't say from > draft-freed-media-types-reg-01 whether the template is for a specific > communication to IANA only (e.g. in an email). I believe the template MUST be used in all cases. > * Which bring me to my final request, for a registration-newbie (like > me) the registration process is something of a black art and a newbie > does not know what action they must take. Does RFC Editor queue entry > OR standards track RFC publication OR email from RFC author actually > initiate the IANA registration process for Standards Tree? (i.e. does > the individual or the IETF have to translate the I-D/RFC into a > request to IANA?) The RFC Editor and IANA co-ordinate to ensure that registrations take place during the RFC publication process. The author doesn't need to contact the IANA directly. Colin

1 0

publication of FITS MIME Internet-Draft
by Steve Allen 11 Sep '04

11 Sep '04

In accordance with the recommendation of the International Astronomical Union FITS Working Group (IAUFWG) I have requested that the Internet-Draft with the name <draft-allen-fitsmime-00.txt> be considered for publication as an Informational RFC. This Internet-Draft specifies two new top-level MIME media types, image/fits and application/fits The shepherd, Scott Hollenbeck, points out the requirement that IETF-Types be involved. Please review the content of <draft-allen-fitsmime-00.txt> and the two media type applications within it. Thank you. Background information: The process by which this document gained IAUFWG approval is visible at http://www.ucolick.org/~sla/fits/mime/ The archives of the IAUFWG are visible via http://listmgr.cv.nrao.edu/pipermail/iaufwg/ The charter given to me by the IAUFWG is visible in the archives at http://listmgr.cv.nrao.edu/pipermail/iaufwg/2004-July/000200.html The vote results indicating unanimous approval for submission is 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

2 1

Re: Comments on draft-freed-media-types-reg-01.txt
by Rod.Walsh＠nokia.com 10 Sep '04

10 Sep '04

Hello all I recently had the please of reading and trying to use the I-D and it is in very good shape. My "implementation experience" input is: * However robust the x. and x- discussion text becomes, it is essential that x. continues to be allowed so that well behaved applications can reject non registered types, without some other private agreement to use and x. instance. * I understand that the standards track RFC for Standards Tree registration can be a dedicated RFC (start life as a dedicated I-D) OR included in the IANA considerations section of a "not dedicated" RFC. Whether or not the latter case is allowed, please state this explicitly (it's not so clear). I definitely support allowing the MIME registration to be bundled with a wider purpose RFC as surely that's what the IANA considerations sections are meant for anyway? * It would be helpful to state whether or not the "bundled RFC" (and a dedicated RFC) must use the syntax of the registration template or whether it is sufficient to cover all those items (in the whole RFC or specifically in the IANA considerations). As someone who has so far not registered any MIME types, I couldn't say from draft-freed-media-types-reg-01 whether the template is for a specific communication to IANA only (e.g. in an email). * Which bring me to my final request, for a registration-newbie (like me) the registration process is something of a black art and a newbie does not know what action they must take. Does RFC Editor queue entry OR standards track RFC publication OR email from RFC author actually initiate the IANA registration process for Standards Tree? (i.e. does the individual or the IETF have to translate the I-D/RFC into a request to IANA?) (Apologies in advance for any overly stupid questions). Cheers, Rod.

1 0