Re: Last Call: 'Media Type Specifications and Registration Procedures' to BCP
On 15 Mar 2005, at 21:25, The IESG wrote: The IESG has received a request from an individual submitter to consider the following document: - 'Media Type Specifications and Registration Procedures ' draft-freed-media-type-reg-02.txt as a BCP The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send any comments to the iesg@ietf.org or ietf@ietf.org mailing lists by 2005-04-12. I have reviewed draft-freed-media-type-reg-03.txt, and have a number of comments intended to align the registration procedures with the current practice defined RFC 3555. These primarily arise due to the widespread use of media subtype names to identify formats that can be conveyed within RTP. The rules for display of text media types assume that such types are, to some extent, readable without special purpose viewing software. This is certainly true for most types, but some existing types have restrictions on their use which are incompatible with this rule (e.g. the text/t140 type specified in RFC 2793 is a framed encoding defined only for transfer via RTP and cannot be directly displayed). The following edit to Section 4.2.1 (Text Media Types), third paragraph, is one way to resolve this inconsistency, by noting that subtypes which are defined with restricted usage cannot necessarily be directly displayed: OLD: Beyond plain text, there are many formats for representing what might be known as rich text. An interesting characteristic of many such representations is that they are to some extent readable even without the software that interprets them. It is useful, then, to distinguish them, at the highest level, from such unreadable data as images, audio, or text represented in an unreadable form. In the absence of appropriate interpretation software, it is reasonable to show subtypes of text to the user, while it is not reasonable to do so with most non textual data. Such formatted textual data should be represented using subtypes of text. NEW: Beyond plain text, there are many formats for representing what might be known as rich text. An interesting characteristic of many such representations is that they are to some extent readable even without the software that interprets them. It is useful, then, to distinguish them, at the highest level, from such unreadable data as images, audio, or text represented in an unreadable form. In the absence of appropriate interpretation software, and provided the subtype is not defined for restricted usage, it is reasonable to show subtypes of text to the user, while it is not reasonable to do so with most non textual data. Such formatted textual data should be represented using subtypes of text. The addition of the framed encoding defined in section 4.8 is valuable now that media types are being widely used outside the traditional email environment. Since there are many media types defined to use RTP framing, and since RFC 3555 imposes additional registration requirements on these formats, it would be useful to reference it from within this draft. The following change to section 4.8 is one possible such edit: OLD: framed The content consists of a series of frames or packets without internal framing or alignment indicators. Additional out of band information is needed to interpret the data properly, including but not necessarily limited to knowledge of the boundaries between successive frames. Note that media types of this sort cannot simply be stored in a file or transported as a simple stream of octets, and therefore such media types are unsuitable for use in many traditional protocols. Additional restrictions on 7bit and 8bit are given in [RFC2046]. NEW: framed The content consists of a series of frames or packets without internal framing or alignment indicators. Additional out of band information is needed to interpret the data properly, including but not necessarily limited to knowledge of the boundaries between successive frames and knowledge of the transport mechanism. Note ^ that media types of this sort cannot simply be stored in a file or transported as a simple stream of octets, and therefore such media types are unsuitable for use in many traditional protocols. Additional restrictions on 7bit and 8bit are given in [RFC2046]. A commonly used transport with framed encoding is the Real-time ^^^ Transport Protocol, RTP. Additional rules for framed encodings ^^^ defined for transport using RTP are given in [RFC3555].
Re: Last Call: 'Media Type Specifications and Registration Procedures' to BCP
On 15 Mar 2005, at 21:25, The IESG wrote: The IESG has received a request from an individual submitter to consider the following document: - 'Media Type Specifications and Registration Procedures ' draft-freed-media-type-reg-02.txt as a BCP The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send any comments to the iesg@ietf.org or ietf@ietf.org mailing lists by 2005-04-12. I have reviewed draft-freed-media-type-reg-03.txt, and have a number of comments intended to align the registration procedures with the current practice defined RFC 3555. These primarily arise due to the widespread use of media subtype names to identify formats that can be conveyed within RTP. Thanks for taking the time to review it. The rules for display of text media types assume that such types are, to some extent, readable without special purpose viewing software. This is certainly true for most types, but some existing types have restrictions on their use which are incompatible with this rule (e.g. the text/t140 type specified in RFC 2793 is a framed encoding defined only for transfer via RTP and cannot be directly displayed). The following edit to Section 4.2.1 (Text Media Types), third paragraph, is one way to resolve this inconsistency, by noting that subtypes which are defined with restricted usage cannot necessarily be directly displayed: OLD: Beyond plain text, there are many formats for representing what might be known as rich text. An interesting characteristic of many such representations is that they are to some extent readable even without the software that interprets them. It is useful, then, to distinguish them, at the highest level, from such unreadable data as images, audio, or text represented in an unreadable form. In the absence of appropriate interpretation software, it is reasonable to show subtypes of text to the user, while it is not reasonable to do so with most non textual data. Such formatted textual data should be represented using subtypes of text. NEW: Beyond plain text, there are many formats for representing what might be known as rich text. An interesting characteristic of many such representations is that they are to some extent readable even without the software that interprets them. It is useful, then, to distinguish them, at the highest level, from such unreadable data as images, audio, or text represented in an unreadable form. In the absence of appropriate interpretation software, and provided the subtype is not defined for restricted usage, it is reasonable to show subtypes of text to the user, while it is not reasonable to do so with most non textual data. Such formatted textual data should be represented using subtypes of text. I'm quite sympathetc to the underlying problem, but IMO this change is unacceptable, in that in order to make it work the fact that a given subtype is intended for restricted usage would have to be known to the display agent. The whole idea of having top-level types is predicated on not needing this sort of exception information. The addition of the framed encoding defined in section 4.8 is valuable now that media types are being widely used outside the traditional email environment. Since there are many media types defined to use RTP framing, and since RFC 3555 imposes additional registration requirements on these formats, it would be useful to reference it from within this draft. The following change to section 4.8 is one possible such edit: OLD: framed The content consists of a series of frames or packets without internal framing or alignment indicators. Additional out of band information is needed to interpret the data properly, including but not necessarily limited to knowledge of the boundaries between successive frames. Note that media types of this sort cannot simply be stored in a file or transported as a simple stream of octets, and therefore such media types are unsuitable for use in many traditional protocols. Additional restrictions on 7bit and 8bit are given in [RFC2046]. NEW: framed The content consists of a series of frames or packets without internal framing or alignment indicators. Additional out of band information is needed to interpret the data properly, including but not necessarily limited to knowledge of the boundaries between successive frames and knowledge of the transport mechanism. Note ^ that media types of this sort cannot simply be stored in a file or transported as a simple stream of octets, and therefore such media types are unsuitable for use in many traditional protocols.
RE: Last Call: 'Media Type Specifications and Registration Procedures' to BCP
-Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of [EMAIL PROTECTED] Sent: Tuesday, April 12, 2005 12:57 PM To: Colin Perkins Cc: iesg@ietf.org; ietf@ietf.org Subject: Re: Last Call: 'Media Type Specifications and Registration Procedures' to BCP [snip] I'm quite sympathetc to the underlying problem, but IMO this change is unacceptable, in that in order to make it work the fact that a given subtype is intended for restricted usage would have to be known to the display agent. The whole idea of having top-level types is predicated on not needing this sort of exception information. Ned, how would you reconcile the current text in your document with the practice specified in RFC 3555? It's been alleged that the documents are not in alignment. -Scott- ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
RE: Last Call: 'Media Type Specifications and Registration Procedures' to BCP
-Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of [EMAIL PROTECTED] Sent: Tuesday, April 12, 2005 12:57 PM To: Colin Perkins Cc: iesg@ietf.org; ietf@ietf.org Subject: Re: Last Call: 'Media Type Specifications and Registration Procedures' to BCP [snip] I'm quite sympathetc to the underlying problem, but IMO this change is unacceptable, in that in order to make it work the fact that a given subtype is intended for restricted usage would have to be known to the display agent. The whole idea of having top-level types is predicated on not needing this sort of exception information. Ned, how would you reconcile the current text in your document with the practice specified in RFC 3555? It's been alleged that the documents are not in alignment. Assuming they really are out of alignment, I'd reconcile them by making whatever changes are appropriate in a revision to RFC 3555. Changing fundamental aspects of how media types are supposed to work and which vast tracts of code depend on is just not an option. Ned ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Last Call: 'Media Type Specifications and Registration Procedures' to BCP
On 12 Apr 2005, at 18:30, [EMAIL PROTECTED] wrote: -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of [EMAIL PROTECTED] Sent: Tuesday, April 12, 2005 12:57 PM To: Colin Perkins Cc: iesg@ietf.org; ietf@ietf.org Subject: Re: Last Call: 'Media Type Specifications and Registration Procedures' to BCP [snip] I'm quite sympathetc to the underlying problem, but IMO this change is unacceptable, in that in order to make it work the fact that a given subtype is intended for restricted usage would have to be known to the display agent. The whole idea of having top-level types is predicated on not needing this sort of exception information. Ned, how would you reconcile the current text in your document with the practice specified in RFC 3555? It's been alleged that the documents are not in alignment. Assuming they really are out of alignment, I'd reconcile them by making whatever changes are appropriate in a revision to RFC 3555. Changing fundamental aspects of how media types are supposed to work and which vast tracts of code depend on is just not an option. The other changes I suggested were to align the draft with RFC 3555. This is a related change, primarily introduced because of the text/t140 type which is clearly textual data, but requires software to decode (and was registered under the RFC 3555 rules). Apologies if that wasn't clear. Colin ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Last Call: 'Media Type Specifications and Registration Procedures' to BCP
On 12 Apr 2005, at 17:57, [EMAIL PROTECTED] wrote: ... The rules for display of text media types assume that such types are, to some extent, readable without special purpose viewing software. This is certainly true for most types, but some existing types have restrictions on their use which are incompatible with this rule (e.g. the text/t140 type specified in RFC 2793 is a framed encoding defined only for transfer via RTP and cannot be directly displayed). The following edit to Section 4.2.1 (Text Media Types), third paragraph, is one way to resolve this inconsistency, by noting that subtypes which are defined with restricted usage cannot necessarily be directly displayed: ... NEW: Beyond plain text, there are many formats for representing what might be known as rich text. An interesting characteristic of many such representations is that they are to some extent readable even without the software that interprets them. It is useful, then, to distinguish them, at the highest level, from such unreadable data as images, audio, or text represented in an unreadable form. In the absence of appropriate interpretation software, and provided the subtype is not defined for restricted usage, it is reasonable to show subtypes of text to the user, while it is not reasonable to do so with most non textual data. Such formatted textual data should be represented using subtypes of text. I'm quite sympathetc to the underlying problem, but IMO this change is unacceptable, in that in order to make it work the fact that a given subtype is intended for restricted usage would have to be known to the display agent. The whole idea of having top-level types is predicated on not needing this sort of exception information. Sure, but if the display agent is unaware of the restrictions, it won't ever be able to receive the media data. The example I have in mind in text/t140 which is UTF-8 text framed within RTP packets [RFC 2793]. The media type is defined only for use with RTP, and an agent that doesn't know how to decode RTP framing (i.e. a sequence of UDP packets with explicit time and ordering data) will never see the data. Colin ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Last Call: 'Media Type Specifications and Registration Procedures' to BCP
Date: 2005-04-12 11:58 From: Colin Perkins [EMAIL PROTECTED] I have reviewed draft-freed-media-type-reg-03.txt, and have a number of comments intended to align the registration procedures with the current practice defined RFC 3555. These primarily arise due to the widespread use of media subtype names to identify formats that can be conveyed within RTP. The rules for display of text media types assume that such types are, to some extent, readable without special purpose viewing software. This is certainly true for most types, but some existing types have restrictions on their use which are incompatible with this rule (e.g. the text/t140 type specified in RFC 2793 is a framed encoding defined only for transfer via RTP and cannot be directly displayed). RFC 2793 states COMMON usage, not restricted, and makes no mention of any sort of restrictions under Interoperability considerations! RFC 2793 also says: Applications which use this media type: Text communication terminals and text conferencing tools. Surely when some content is reassembled from the individual packets, it can be presented without special purpose software (other than that required for charset issues and local presentation conditions). If it cannot be presented, it's difficult to imagine how the media type would be used in the stated intended applications. If a substantial amount (more than one MTU) of text/plain is transmitted via some application-level protocol over TCP (rather than RTP), one of course has to reassemble the content for the application layer for presentation. In what way does use of RTP instead of TCP (UDP, etc.) at a transport protocol layer change that? One might even ask in what sense -- at the application layer -- text/t140 is meant to be different from text/plain. Perhaps the issue is not so much with the registration procedure draft as with the text/t140 registration... or maybe RFC 2793 isn't a good example of the issue you have in mind. The following edit to Section 4.2.1 (Text Media Types), third paragraph, is one way to resolve this inconsistency, by noting that subtypes which are defined with restricted usage cannot necessarily be directly displayed: Again, I'm not sure that helps for RFC 2793, which doesn't indicate restricted usage. OLD: Beyond plain text, there are many formats for representing what might [...] show subtypes of text to the user, while it is not reasonable to do present might be an improvement over show, as it accommodates text-to-speech conversion (for visually impaired users). ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Last Call: 'Media Type Specifications and Registration Procedures' to BCP
On 12 Apr 2005, at 19:45, Bruce Lilly wrote: Date: 2005-04-12 11:58 From: Colin Perkins [EMAIL PROTECTED] I have reviewed draft-freed-media-type-reg-03.txt, and have a number of comments intended to align the registration procedures with the current practice defined RFC 3555. These primarily arise due to the widespread use of media subtype names to identify formats that can be conveyed within RTP. The rules for display of text media types assume that such types are, to some extent, readable without special purpose viewing software. This is certainly true for most types, but some existing types have restrictions on their use which are incompatible with this rule (e.g. the text/t140 type specified in RFC 2793 is a framed encoding defined only for transfer via RTP and cannot be directly displayed). RFC 2793 states COMMON usage, not restricted, and makes no mention of any sort of restrictions under Interoperability considerations! RFC 2793 also says: Applications which use this media type: Text communication terminals and text conferencing tools. The encoding considerations section of the registration limits this to RTP. The lack of clarity on where to specify restricted domains of applicability is one of the things I hope this update to the media type registration guidelines will fix. Surely when some content is reassembled from the individual packets, it can be presented without special purpose software (other than that required for charset issues and local presentation conditions). If it cannot be presented, it's difficult to imagine how the media type would be used in the stated intended applications. If a substantial amount (more than one MTU) of text/plain is transmitted via some application-level protocol over TCP (rather than RTP), one of course has to reassemble the content for the application layer for presentation. In what way does use of RTP instead of TCP (UDP, etc.) at a transport protocol layer change that? One might even ask in what sense -- at the application layer -- text/t140 is meant to be different from text/plain. Perhaps the issue is not so much with the registration procedure draft as with the text/t140 registration... or maybe RFC 2793 isn't a good example of the issue you have in mind. An alternative example would be draft-ietf-avt-text-red-05.txt which, due to the way SDP/SIP signalling works, needs to use the same top level media type as text/t140. Colin ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Last Call: 'Media Type Specifications and Registration Procedures' to BCP
Date:Tue, 12 Apr 2005 19:03:03 +0100 From:Colin Perkins [EMAIL PROTECTED] Message-ID: [EMAIL PROTECTED] | Sure, but if the display agent is unaware of the restrictions, it won't | ever be able to receive the media data. The example I have in mind in | text/t140 which is UTF-8 text framed within RTP packets [RFC 2793]. | The media type is defined only for use with RTP, I'm not sure I believe that works. What prevents this message from containing an alternative to the text/plain that is (currently) its only body type, with a Content-Type: text/t140 field (and correctly formatted for that, as much as it can be in a e-mailbody) ? Or what prevents a HTTP response with Content-Type: text/t140? Sure, the rules for use of that content-type may have been violated, but what is your MUA (or browser) supposed to do when it receives the message? All it is likely to know is that it has received yet another odd text/unknown content type. And if it is to be displayed, treating it just like all other text/weird types as the fallback (better than nothing) option ? I think Ned's point (though he can certainly speak for himself) is that if rfc3555 is allowing registrations like that, then rfc3555 needs to be fixed, and any bogus registrations that have been made, need to be corrected. kre ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Last Call: 'Media Type Specifications and Registration Procedures' to BCP
On 12 Apr 2005, at 20:51, Robert Elz wrote: Date:Tue, 12 Apr 2005 19:03:03 +0100 From:Colin Perkins [EMAIL PROTECTED] Message-ID: [EMAIL PROTECTED] | Sure, but if the display agent is unaware of the restrictions, it won't | ever be able to receive the media data. The example I have in mind in | text/t140 which is UTF-8 text framed within RTP packets [RFC 2793]. | The media type is defined only for use with RTP, I'm not sure I believe that works. What prevents this message from containing an alternative to the text/plain that is (currently) its only body type, with a Content-Type: text/t140 field (and correctly formatted for that, as much as it can be in a e-mailbody) ? Or what prevents a HTTP response with Content-Type: text/t140? Sure, the rules for use of that content-type may have been violated, but what is your MUA (or browser) supposed to do when it receives the message? All it is likely to know is that it has received yet another odd text/unknown content type. And if it is to be displayed, treating it just like all other text/weird types as the fallback (better than nothing) option ? I think Ned's point (though he can certainly speak for himself) is that if rfc3555 is allowing registrations like that, then rfc3555 needs to be fixed, and any bogus registrations that have been made, need to be corrected. RFC 3555 allows media types to be defined for transport only via RTP. The majority of these registrations are under the audio and video top-level types, with a small number being under text. Is your objection to any media type being defined only for transport via RTP, or to text media types being defined only for transport via RTP? Colin ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Last Call: 'Media Type Specifications and Registration Procedures' to BCP
Date:Tue, 12 Apr 2005 21:20:28 +0100 From:Colin Perkins [EMAIL PROTECTED] Message-ID: [EMAIL PROTECTED] | RFC 3555 allows media types to be defined for transport only via RTP. | The majority of these registrations are under the audio and video | top-level types, with a small number being under text. Is your | objection to any media type being defined only for transport via RTP, | or to text media types being defined only for transport via RTP? Not to either of those being attempted, but to the expectation that the only via RTP will, or can, ever be enforced. That is, to your earlier statement ... Sure, but if the display agent is unaware of the restrictions, it won't ever be able to receive the media data. You'd need to be able to show me how that can possibly be true, when I can trivially easily send e-mail with text/t140 in the Content-Type header. kre ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Last Call: 'Media Type Specifications and Registration Procedures' to BCP
On 12 Apr 2005, at 23:04, Robert Elz wrote: Date:Tue, 12 Apr 2005 21:20:28 +0100 From:Colin Perkins [EMAIL PROTECTED] Message-ID: [EMAIL PROTECTED] | RFC 3555 allows media types to be defined for transport only via RTP. | The majority of these registrations are under the audio and video | top-level types, with a small number being under text. Is your | objection to any media type being defined only for transport via RTP, | or to text media types being defined only for transport via RTP? Not to either of those being attempted, but to the expectation that the only via RTP will, or can, ever be enforced. That is, to your earlier statement ... Sure, but if the display agent is unaware of the restrictions, it won't ever be able to receive the media data. You'd need to be able to show me how that can possibly be true, when I can trivially easily send e-mail with text/t140 in the Content-Type header. You can put anything you like in a Content-Type header, but that doesn't make the data meaningful without a specification for the content. The restriction for only via RTP is made by only specifying the framing rules for RTP transport; the necessary information to convey the type via non-RTP transports is simply not specified. There are many (more than 50) such media types registered, and they are widely implemented without the problems at which you are hinting. Colin ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Last Call: 'Media Type Specifications and Registration Procedures' to BCP
On Wed, 13 Apr 2005, Robert Elz wrote: Date:Tue, 12 Apr 2005 21:20:28 +0100 From:Colin Perkins [EMAIL PROTECTED] Message-ID: [EMAIL PROTECTED] | RFC 3555 allows media types to be defined for transport only via RTP. | The majority of these registrations are under the audio and video | top-level types, with a small number being under text. Is your | objection to any media type being defined only for transport via RTP, | or to text media types being defined only for transport via RTP? Not to either of those being attempted, but to the expectation that the only via RTP will, or can, ever be enforced. What that means is that the specifications only supply instructions about how to format and transmit the data via RTP, not any other method. Therefore... That is, to your earlier statement ... Sure, but if the display agent is unaware of the restrictions, it won't ever be able to receive the media data. You'd need to be able to show me how that can possibly be true, when I can trivially easily send e-mail with text/t140 in the Content-Type header. When you set out to do that, how are you going to figure out what some text/t140 content should be? Are you saying that you would use that Content-Type but just put US-ASCII into the body? You could also use Content-Type=audio/basic and put US-ASCII into the body, but it would probably not be very useful. -- Steve ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Last Call: 'Media Type Specifications and Registration Procedures' to BCP
Date:Tue, 12 Apr 2005 21:20:28 +0100 From:Colin Perkins [EMAIL PROTECTED] Message-ID: [EMAIL PROTECTED] | RFC 3555 allows media types to be defined for transport only via RTP. | The majority of these registrations are under the audio and video | top-level types, with a small number being under text. Is your | objection to any media type being defined only for transport via RTP, | or to text media types being defined only for transport via RTP? Not to either of those being attempted, but to the expectation that the only via RTP will, or can, ever be enforced. Exactly so. This is why I've been pushing back on this. Stuff slops from one application/transport to another all the time. That is, to your earlier statement ... Sure, but if the display agent is unaware of the restrictions, it won't ever be able to receive the media data. You'd need to be able to show me how that can possibly be true, when I can trivially easily send e-mail with text/t140 in the Content-Type header. Two points: (1) IMO text/t140 content actually conforms pretty well to the restrictions on the text top-level type. In particular, text/t140 material basically consists of unadorned UTF-8 text. There are a couple of control characters used for special purposes, but we're not talking about HTML here or anything similar. (2) The place where text/t140 parts ways with other media type usage is in how it is encoded. text/t140 cannot be encoded as a simple series of octets. Rather, it depends critically on RTP packet framing both to tie the content to other media and to eliminate duplicate material. We added the framed encoding type to the media type registration to take care of this and similar cases. A media type that uses the framed encoding really is confined to a particular transport realm. So, in the case of text/t140, I reallly don't see any conflict we need to resolve. But this doesn't mean there aren't potential conflicts - media types have been defined that work in both the packet and stream worlds. And such types could very easily leak - in fact I'd be surprised if they didn't. Ned ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Last Call: 'Media Type Specifications and Registration Procedures' to BCP
On Fri April 1 2005 12:02, Ned Freed wrote: FWIW, I have every intention of incorporating your comments on message/partial into the next revision of the base MIME specification. I like to think we a reasonable job overall on the initial set of security considerations, but this is one we clearly missed. As I mentioned to you and Nat, I think RFC 1344 covers the relevant message/partial issues; unfortunately it hasn't been kept up-to-date with the rest of the MIME RFCs, and has merely Informational status. It very obviously has been ignored by developers, at the peril of those developers' customers and the Internet at large. My comments to you and Nat the following day regarding general MIME security issues I believe addresses issues that have not yet been covered in any MIME- related RFCs. And I'm confident that the issues will be addressed in due course. However my concern about the registration/commentary mechanism remains that there does not appear to be a lightweight mechanism for registering commentary on media type registrations issued as RFCs (2046 isn't a single type registration per se, and represents an unusual case that probably isn't worth fussing over w.r.t. the draft under discussion). For example, consider the potential problems that might arise if the application/msword registration had been in an RFC [it is not, but my reading of section 3.1 of the draft under discussion is that if it weren't grandfathered it would have to be an RFC]; as I see it there would be two possible approaches to adding security issues comments: 1. issue a separate RFC addressing only the security issues, requesting that the RFC Editor note that it updates the original RFC. Even with such a note, that later RFC would likely be ignored by many developers (as many have ignored 2231, which updates 2045; as many have ignored updates to 821/822, leading to consolidation in 2821 and 2822 via DRUMS). [medium-weight, low-visibility mechanism] 2. issue a new RFC obsoleting the old one, and incorporating the entire media type registration. In the case of application/msword, I doubt that the specification by example would pass muster in a new registration, and there are a number of new registration template items that would have to be added. Somebody who wishes to note security considerations (or e.g. to note a new value for the version parameter) shouldn't have to jump through a lot of hoops to do so. [heavy-weight, high-visibility mechanism] Either type of RFC would take a minimum of 6 weeks for a mere peon such as me (2-week types review plus 4 week Last Call period) [according to RFC 2026, the IESG can request a variance (sect. 9.1), but such a variance itself would require a Last Call of at least 4 weeks, so that would result in a longer overall process!], and in the case of security considerations in particular, such a delay might be inadvisable. An IETF WG could rush through an RFC with a 2 week Last Call; maybe the media types review panel (http://www.iana.org/numbers.html#M under Multipurpose Internet Mail Extensions (MIME) Media Types) should be an IETF WG so as to be able to take advantage of that. [maybe IANA is wrong about a panel, as I don't see that in the draft under discussion] As I wrote earlier, I don't have a specific lightweight mechanism to offer, and if your plan remains to work out such issues on-the-fly as problems arise, so be it. My immediate objective is to make my concerns clearly known. ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Last Call: 'Media Type Specifications and Registration Procedures' to BCP
On Wed March 30 2005 13:07, Bob Braden wrote: For RFC publication, RFC Editor does use a spell checker, which no doubt has a US bias. We do try for consistency. but we also try to allow consistent non-US usage. In either case, we are less than perfect, but we try. Joe Abley wrote: * The spelling error comments above are attributed to The IESG. As * someone who learnt to read and write outside the US, I would hope that * there's no conscious ambition to enforce the us US English spelling in * new documents. I am responsible for the comments. The attribution interpretation is probably an artifact (or artefact, if you prefer) of misinterpretation of quoting by Ned's MUA (which did not include an attribution line, but copied (with one level of quoting) the attribution line inserted by my MUA). Note that the text included directly from my comment message has a single '' attribution mark (that includes the IESG attribution line and my comments) whereas the material quoted from the IESG ID-announce message (correctly attributed to The IESG) has two '' attribution marks. For the record, I detected the errors while reading the draft (having made the same errors myself in the past) and confirmed them by two methods: 1. via the ispell program 2. by referencing published RFCs (to ensure consistency among the collection of RFCs) ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Last Call: 'Media Type Specifications and Registration Procedures' to BCP
On Tue March 29 2005 14:03, [EMAIL PROTECTED] wrote: [I wrote] Section 4.2.1 might benefit from a clarification of text as communication in a natural language intended primarily for human consumption (perhaps something like the description in BCP 18). Perhaps, but this text was very carefully crafted after a long debate and I don't feel comfortable changing it. I recall the debate :-). BTW, I like the wording under the application media types discussion, which may be sufficient to cover the case of scripting (computer programming) languages. As Mac OS is a somewhat obscure platform, and as the registration template provides for Mac OS Type codes, a normative reference providing information on those codes would be appropriate in section 4.11. Suggestions welcome as to what an appropriate reference would be. Hmmm. As we've discussed, that may be difficult. Unfortunately, the vendor (Apple) doesn't seem to provide much useful information (at least not online); the best I was able to find after hours of searching was http://docs.info.apple.com/article.html?artnum=55381. IIRC you suggested http://cocoa.mamasam.com/COCOADEV/2001/09/1/11740.php. It is -- as you noted -- unclear whether either of those URIs would be acceptable to the RFC Editor (http://www.rfc-editor.org/policy.html#policy.urls). By the way, a note to the effect that in order to avoid confusion, four-letter words indicating lack of a code (e.g. none) should be avoided, might be advisable (since the codes themselves consist of four characters). Section 5.4 references RFC 2026 regarding decisions made by the media types reviewer, but RFC 2026 does not contain any text specifically regarding media types review. RFC 2026 section 6.5 discusses conflict resolution and has three parts, none of which seem apropos to media type review (6.5.1 Working Group disputes, 6.5.2 [IESG] Process Failures, and 6.5.3 Questions of Applicable Procedure) [publication of the draft as-is as a BCP might raise a question of applicable procedure]. At minimum, some clarification (regarding which section(s) of RFC 2026 is meant to apply) seems necessary. It is not necessary for RFC 2026 to have text specifically dealing with the case of appealing a reviewer decision. RFC 2026 specifies what's necessary to appeal something, and that's sufficient. The fact that RFC 2026 also deals with several specific sorts of appeals and why they might arise is not relevant. I see no real reason to add anything here, but I'll make the reference specific to section 6.5.4 (which describes the actual appeals procedure). 6.5.4 discusses content and timing, but doesn't address to whom (IESG as a body, IESG/IETF chair, IAB, ISOC). I don't anticipate problems, but I mentioned the issue for completeness. I've had my say; I'll leave it to you, the IESG, and/or other commenters to discuss and decide whether to further tweak the wording. The section 6 procedure (modified from RFC 2048 section 2.4) doesn't seem to be effective in practice. While the additional step of review by the media types reviewer might be an improvement, specific statements regarding necessary IANA actions should probably be included in the IANA Considerations section (the present IANA Considerations section seems somewhat sparse). Well, if the goal is to make the procedure more effective, the last thing we need to do is nail it down more precisely. This has been shown over and over and over again to be an inhibiting factor in this general space, not a facilitator. What really needs to happen here is for someone to issue a comment on a registration and let the process run. If this turns up a problem we can examine it and amend the process accordingly. And if it doesn't, if it ain't broke... In any case, I am extrelemy reluctant to twiddle with this further in the absence of any running code. We've discussed this off-list based on a security-related comment on a registered type; let's see what happens. Section 8 is somewhat unclear regarding standards tree registration requirements. It states Registrations in the standards tree MUST satisfy the additional requirement that they originate from the IETF itself or from another standards body recognized as such by the IETF. Ignoring the part about another standards body, there is some ambiguity regarding standards tree registrations using IETF procedures (i.e. published RFCs). The ambiguity arises from the phrase originate from the IETF itself, coupled with the fact that the IETF is not a well-defined set. It is unclear whether or not an individual submission RFC (as distinct from an RFC which is the product of an IETF working group) qualifies for registration of a media type or subtype in the standards tree. The vagueness here is intentional since it isn't clear who gets to make the call as to whether or not some other organization is a standards body
Re: Last Call: 'Media Type Specifications and Registration Procedures' to BCP
On Tue March 29 2005 14:03, [EMAIL PROTECTED] wrote: [I wrote] Section 4.2.1 might benefit from a clarification of text as communication in a natural language intended primarily for human consumption (perhaps something like the description in BCP 18). Perhaps, but this text was very carefully crafted after a long debate and I don't feel comfortable changing it. I recall the debate :-). BTW, I like the wording under the application media types discussion, which may be sufficient to cover the case of scripting (computer programming) languages. Good. It's always hard to know if the balance between specificity and generality is right in these things. As Mac OS is a somewhat obscure platform, and as the registration template provides for Mac OS Type codes, a normative reference providing information on those codes would be appropriate in section 4.11. Suggestions welcome as to what an appropriate reference would be. Hmmm. As we've discussed, that may be difficult. Unfortunately, the vendor (Apple) doesn't seem to provide much useful information (at least not online); the best I was able to find after hours of searching was http://docs.info.apple.com/article.html?artnum=55381. OK, let's run with that. We'll see what the RFC Editor thinks. Besides, it gives me the chance to try out some xml2rfc features I just learned about on the xml2rfc list ;-) FWIW, the cite I came up with looks like this: reference anchor=MacOSFileTypes target=http://docs.info.apple.com/article.html?artnum=55381; front titleMac OS: File Type and Creator Codes, and File Formats/title author organizationApple Computer, Inc./organization /author date month=June year=1993/ /front seriesInfo name=Apple Knowledge Base value=Article 55381/ /reference IIRC you suggested http://cocoa.mamasam.com/COCOADEV/2001/09/1/11740.php. It is -- as you noted -- unclear whether either of those URIs would be acceptable to the RFC Editor (http://www.rfc-editor.org/policy.html#policy.urls). On inspection I think this one is too much about file extensions and too little about file type codes to be useful. By the way, a note to the effect that in order to avoid confusion, four-letter words indicating lack of a code (e.g. none) should be avoided, might be advisable (since the codes themselves consist of four characters). Good idea. Added. I also pointed out that there are similar concerns for file extensions. The section 6 procedure (modified from RFC 2048 section 2.4) doesn't seem to be effective in practice. While the additional step of review by the media types reviewer might be an improvement, specific statements regarding necessary IANA actions should probably be included in the IANA Considerations section (the present IANA Considerations section seems somewhat sparse). Well, if the goal is to make the procedure more effective, the last thing we need to do is nail it down more precisely. This has been shown over and over and over again to be an inhibiting factor in this general space, not a facilitator. What really needs to happen here is for someone to issue a comment on a registration and let the process run. If this turns up a problem we can examine it and amend the process accordingly. And if it doesn't, if it ain't broke... In any case, I am extrelemy reluctant to twiddle with this further in the absence of any running code. We've discussed this off-list based on a security-related comment on a registered type; let's see what happens. Agreed. Section 8 is somewhat unclear regarding standards tree registration requirements. It states Registrations in the standards tree MUST satisfy the additional requirement that they originate from the IETF itself or from another standards body recognized as such by the IETF. Ignoring the part about another standards body, there is some ambiguity regarding standards tree registrations using IETF procedures (i.e. published RFCs). The ambiguity arises from the phrase originate from the IETF itself, coupled with the fact that the IETF is not a well-defined set. It is unclear whether or not an individual submission RFC (as distinct from an RFC which is the product of an IETF working group) qualifies for registration of a media type or subtype in the standards tree. The vagueness here is intentional since it isn't clear who gets to make the call as to whether or not some other organization is a standards body or not. Hmmm. That wasn't my concern. Rather it's about individual submissions (as distinct from WG items) as standards tree registrations (a real case that is in process, albeit under the current RFC 2048 procedure) and the case of a revision to an RFC-based registration for the purpose of adding comments (e.g. revising security considerations; see below). OK, now I understand. I don't think there is, or
Re: Last Call: 'Media Type Specifications and Registration Procedures' to BCP
On 29 March 2005, at 14:03, [EMAIL PROTECTED] wrote: Section heading in table of contents and in the actual section contains a spelling error: Acknowledgements should be Acknowledgments. According to two dictionaries I checked (Random House and Ultralingua) both spelling are acceptable. But shorter is better so I'll switch to the shorter. Acknowledgements is the most common spelling outside the US. Acknowledgments is most common within the US. Section .. contains a spelling error: labelled should be labeled. Again, your dictionary needs some new entries. Both spellings are perfectly acceptable. I'll change it since shorter is better. Labelled is the most common spelling outside the US. Labeled is most common within the US. Declarations of correctness depend very much on your frame of reference, I think. Personally, I don't think it matters which spelling conventions are used in a document, but I think consistency (i.e. using US English spelling or rest-of-world English spelling throughout) is better than mixing. The approach of choosing the spelling with the least number of letters, word-by-word, might well approximate the convention of using US English throughout. However, that goal (if chosen) might be better achieved by installing a US English dictionary and spell-checking the text. The spelling error comments above are attributed to The IESG. As someone who learnt to read and write outside the US, I would hope that there's no conscious ambition to enforce the us US English spelling in new documents. Joe ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Last Call: 'Media Type Specifications and Registration Procedures' to BCP
* The approach of choosing the spelling with the least number of letters, * word-by-word, might well approximate the convention of using US English * throughout. However, that goal (if chosen) might be better achieved by * installing a US English dictionary and spell-checking the text. * For RFC publication, RFC Editor does use a spell checker, which no doubt has a US bias. We do try for consistency. but we also try to allow consistent non-US usage. In either case, we are less than perfect, but we try. RFC Editor/bb * The spelling error comments above are attributed to The IESG. As * someone who learnt to read and write outside the US, I would hope that * there's no conscious ambition to enforce the us US English spelling in * new documents. * * * Joe * * ___ * Ietf mailing list * Ietf@ietf.org * https://www1.ietf.org/mailman/listinfo/ietf * ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Last Call: 'Media Type Specifications and Registration Procedures' to BCP
The spelling error comments above are attributed to The IESG. The IESG authored the Last Call message to which the spelling error comments were a reply. Ned quoted Bruce's attribution with no attribution (but it was indented with a prefix.) Bill ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Last Call: 'Media Type Specifications and Registration Procedures' to BCP
Joe Abley wrote: The approach of choosing the spelling with the least number of letters, word-by-word, might well approximate the convention of using US English throughout. Not for centre. Shorter is always better was only a joke, Ned is the author, he can pick any correct spelling he likes. Bye, Frank (back to LTRU and its en-GB-oed) ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Last Call: 'Media Type Specifications and Registration Procedures' to BCP
On Tue March 15 2005 16:25, The IESG wrote: The IESG has received a request from an individual submitter to consider the following document: - 'Media Type Specifications and Registration Procedures ' draft-freed-media-type-reg-02.txt as a BCP The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send any comments to the iesg@ietf.org or ietf@ietf.org mailing lists by 2005-04-12. [...] Comments, in same order as the draft (though some as noted apply in general or to multiple sections of the draft): Section 13 heading in table of contents and in the actual section contains a spelling error: Acknowledgements should be Acknowledgments. According to two dictionaries I checked (Random House and Ultralingua) both spelling are acceptable. But shorter is better so I'll switch to the shorter. Historical Note, 2nd paragraph, 2nd line needs a period and additional space character at the end of the first sentence (i.e. between environments and This). Fixed. Formatting seems a bit peculiar (e.g. huge empty space on page 5). An unavoidable consequence of the put each major section on a new page rule imposed by xml2rfc. There does not appear to be any mention of case-insensitivity of media type and subtype names (e.g. sect. 3 w.r.t. tree and facet names, sect. 4 w.r.t. additional name components). [see also RFC 1958 section 4.3] I'll add a note to this effect. Section 4.2.1 might benefit from a clarification of text as communication in a natural language intended primarily for human consumption (perhaps something like the description in BCP 18). Perhaps, but this text was very carefully crafted after a long debate and I don't feel comfortable changing it. Section 4.2.6 contains a spelling error: labelled should be labeled. Again, your dictionary needs some new entries. Both spellings are perfectly acceptable. I'll change it since shorter is better. Syntax of parameter attribute names is significantly changed from that of RFC 2045 as amended by RFC 2231 and errata. Those RFCs prohibited '%' and tspecials, while the draft specifies reg-name as defined in the draft, which explicitly includes '%'. [draft sections 4.2, 4.3] Yep, % is now reserved in parameter names at least. Forgot about that. I'll remove it from the ABNF. This also will prevent it from being used in a media type name, but that's hardly a bad thing... More generally, the intent here is to have an explicit list of what characters can be used, as opposed to defining what's allowed by exclusion. The result is deliberately intended to be more restrictive than what's actually allowed by the RFC 2045 ABNF. Section 4.8 introduces framed content type, but that change is not noted in Appendix B. Added. As Mac OS is a somewhat obscure platform, and as the registration template provides for Mac OS Type codes, a normative reference providing information on those codes would be appropriate in section 4.11. Suggestions welcome as to what an appropriate reference would be. Section 4.11 refers to RFC 2396, which (according to the rfc-index) has been obsoleted by RFC 3986. Updated. Section 5.4 references RFC 2026 regarding decisions made by the media types reviewer, but RFC 2026 does not contain any text specifically regarding media types review. RFC 2026 section 6.5 discusses conflict resolution and has three parts, none of which seem apropos to media type review (6.5.1 Working Group disputes, 6.5.2 [IESG] Process Failures, and 6.5.3 Questions of Applicable Procedure) [publication of the draft as-is as a BCP might raise a question of applicable procedure]. At minimum, some clarification (regarding which section(s) of RFC 2026 is meant to apply) seems necessary. It is not necessary for RFC 2026 to have text specifically dealing with the case of appealing a reviewer decision. RFC 2026 specifies what's necessary to appeal something, and that's sufficient. The fact that RFC 2026 also deals with several specific sorts of appeals and why they might arise is not relevant. I see no real reason to add anything here, but I'll make the reference specific to section 6.5.4 (which describes the actual appeals procedure). The section 6 procedure (modified from RFC 2048 section 2.4) doesn't seem to be effective in practice. While the additional step of review by the media types reviewer might be an improvement, specific statements regarding necessary IANA actions should probably be included in the IANA Considerations section (the present IANA Considerations section seems somewhat sparse). Well, if the goal is to make the procedure more effective, the last thing we need to do is nail it down more precisely. This has been shown over and over and over again to be an inhibiting factor in this general space, not a facilitator. What really needs to happen here is for someone to issue a comment on a registration and let the process run. If
Re: Last Call: 'Media Type Specifications and Registration Procedures' to BCP
On Tue March 15 2005 16:25, The IESG wrote: The IESG has received a request from an individual submitter to consider the following document: - 'Media Type Specifications and Registration Procedures ' draft-freed-media-type-reg-02.txt as a BCP The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send any comments to the iesg@ietf.org or ietf@ietf.org mailing lists by 2005-04-12. [...] Comments, in same order as the draft (though some as noted apply in general or to multiple sections of the draft): Section 13 heading in table of contents and in the actual section contains a spelling error: Acknowledgements should be Acknowledgments. Historical Note, 2nd paragraph, 2nd line needs a period and additional space character at the end of the first sentence (i.e. between environments and This). Formatting seems a bit peculiar (e.g. huge empty space on page 5). There does not appear to be any mention of case-insensitivity of media type and subtype names (e.g. sect. 3 w.r.t. tree and facet names, sect. 4 w.r.t. additional name components). [see also RFC 1958 section 4.3] Section 4.2.1 might benefit from a clarification of text as communication in a natural language intended primarily for human consumption (perhaps something like the description in BCP 18). Section 4.2.6 contains a spelling error: labelled should be labeled. Syntax of parameter attribute names is significantly changed from that of RFC 2045 as amended by RFC 2231 and errata. Those RFCs prohibited '%' and tspecials, while the draft specifies reg-name as defined in the draft, which explicitly includes '%'. [draft sections 4.2, 4.3] Section 4.8 introduces framed content type, but that change is not noted in Appendix B. As Mac OS is a somewhat obscure platform, and as the registration template provides for Mac OS Type codes, a normative reference providing information on those codes would be appropriate in section 4.11. Section 4.11 refers to RFC 2396, which (according to the rfc-index) has been obsoleted by RFC 3986. Section 5.4 references RFC 2026 regarding decisions made by the media types reviewer, but RFC 2026 does not contain any text specifically regarding media types review. RFC 2026 section 6.5 discusses conflict resolution and has three parts, none of which seem apropos to media type review (6.5.1 Working Group disputes, 6.5.2 [IESG] Process Failures, and 6.5.3 Questions of Applicable Procedure) [publication of the draft as-is as a BCP might raise a question of applicable procedure]. At minimum, some clarification (regarding which section(s) of RFC 2026 is meant to apply) seems necessary. The section 6 procedure (modified from RFC 2048 section 2.4) doesn't seem to be effective in practice. While the additional step of review by the media types reviewer might be an improvement, specific statements regarding necessary IANA actions should probably be included in the IANA Considerations section (the present IANA Considerations section seems somewhat sparse). Section 8 is somewhat unclear regarding standards tree registration requirements. It states Registrations in the standards tree MUST satisfy the additional requirement that they originate from the IETF itself or from another standards body recognized as such by the IETF. Ignoring the part about another standards body, there is some ambiguity regarding standards tree registrations using IETF procedures (i.e. published RFCs). The ambiguity arises from the phrase originate from the IETF itself, coupled with the fact that the IETF is not a well-defined set. It is unclear whether or not an individual submission RFC (as distinct from an RFC which is the product of an IETF working group) qualifies for registration of a media type or subtype in the standards tree. Section 9 raises some issues which should probably be incorporated into the IANA Considerations section so that IANA's roles are consolidated in one place as mentioned above. Several of the references are amended by other RFCS (e.g. RFC 2231 amends normative reference RFC 2045) or by errata maintained by the RFC Editor. Additional references to those amending RFCs and errata should probably be included. A list of the specific media types which are affected by ownership and change control principles in the draft should probably be included in Appendix A. ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
