From: iana at iana.org (iana@iana.org) Date: Fri Oct 29 13:03:59 2004 Subject: ConfirmSystem: iana@icann.org [[b8cff28327f85e7c]] Message-ID: <200410291103.i9TB3sK21523@santee.icann.org> Thank you for your message. The iana@iana.org address collects a tremendous amount of spam, and we have been forced to implement protective measures. In order to process your message we need to confirm that it came from a real email address. To confirm your message, you can either: 1) Reply to this message, without altering the subject line The "Re: " added by many mail clients is OK, but please note that this method is *not* foolproof. or 2) Visit the URL If you want to be very sure that your message gets through, do both steps above -- it does no harm to confirm more than once. For your reference, the subject of the message you sent was: "{Filename?} Re: Thank you!" and it arrived at IANA approximately at Fri Oct 29 04:03:54 2004. --------------------------------------------------------------- ConfirmSystem: iana@icann.org [[b8cff28327f85e7c]] 4 From: iana at iana.org (iana@iana.org) Date: Tue Jan 3 16:22:51 2006 Subject: ConfirmSystem: iana@icann.org [[b8cff28327f85e7c]] Message-ID: <200410291103.i9TB3sK21523@santee.icann.org> Thank you for your message. The iana@iana.org address collects a tremendous amount of spam, and we have been forced to implement protective measures. In order to process your message we need to confirm that it came from a real email address. To confirm your message, you can either: 1) Reply to this message, without altering the subject line The "Re: " added by many mail clients is OK, but please note that this method is *not* foolproof. or 2) Visit the URL If you want to be very sure that your message gets through, do both steps above -- it does no harm to confirm more than once. For your reference, the subject of the message you sent was: "{Filename?} Re: Thank you!" and it arrived at IANA approximately at Fri Oct 29 04:03:54 2004. --------------------------------------------------------------- ConfirmSystem: iana@icann.org [[b8cff28327f85e7c]] 4 From: iana at iana.org (iana@iana.org) Date: Fri Oct 29 12:37:45 2004 Subject: ConfirmSystem: iana@icann.org [[c1bcd9ea4cb39927]] Message-ID: <200410291037.i9TAbfj20234@santee.icann.org> Thank you for your message. The iana@iana.org address collects a tremendous amount of spam, and we have been forced to implement protective measures. In order to process your message we need to confirm that it came from a real email address. To confirm your message, you can either: 1) Reply to this message, without altering the subject line The "Re: " added by many mail clients is OK, but please note that this method is *not* foolproof. or 2) Visit the URL If you want to be very sure that your message gets through, do both steps above -- it does no harm to confirm more than once. For your reference, the subject of the message you sent was: "{Filename?} Re: Hello" and it arrived at IANA approximately at Fri Oct 29 03:37:41 2004. --------------------------------------------------------------- ConfirmSystem: iana@icann.org [[c1bcd9ea4cb39927]] 3 From: iana at iana.org (iana@iana.org) Date: Tue Jan 3 16:22:51 2006 Subject: ConfirmSystem: iana@icann.org [[c1bcd9ea4cb39927]] Message-ID: <200410291037.i9TAbfj20234@santee.icann.org> Thank you for your message. The iana@iana.org address collects a tremendous amount of spam, and we have been forced to implement protective measures. In order to process your message we need to confirm that it came from a real email address. To confirm your message, you can either: 1) Reply to this message, without altering the subject line The "Re: " added by many mail clients is OK, but please note that this method is *not* foolproof. or 2) Visit the URL If you want to be very sure that your message gets through, do both steps above -- it does no harm to confirm more than once. For your reference, the subject of the message you sent was: "{Filename?} Re: Hello" and it arrived at IANA approximately at Fri Oct 29 03:37:41 2004. --------------------------------------------------------------- ConfirmSystem: iana@icann.org [[c1bcd9ea4cb39927]] 3 From: iana at iana.org (iana@iana.org) Date: Fri Oct 29 12:27:46 2004 Subject: ConfirmSystem: iana@icann.org [[83f3d701c0925134]] Message-ID: <200410291027.i9TARei19847@santee.icann.org> Thank you for your message. The iana@iana.org address collects a tremendous amount of spam, and we have been forced to implement protective measures. In order to process your message we need to confirm that it came from a real email address. To confirm your message, you can either: 1) Reply to this message, without altering the subject line The "Re: " added by many mail clients is OK, but please note that this method is *not* foolproof. or 2) Visit the URL If you want to be very sure that your message gets through, do both steps above -- it does no harm to confirm more than once. For your reference, the subject of the message you sent was: "{Filename?} Re: Thanks :)" and it arrived at IANA approximately at Fri Oct 29 03:27:40 2004. --------------------------------------------------------------- ConfirmSystem: iana@icann.org [[83f3d701c0925134]] 2 From: iana at iana.org (iana@iana.org) Date: Tue Jan 3 16:22:51 2006 Subject: ConfirmSystem: iana@icann.org [[83f3d701c0925134]] Message-ID: <200410291027.i9TARei19847@santee.icann.org> Thank you for your message. The iana@iana.org address collects a tremendous amount of spam, and we have been forced to implement protective measures. In order to process your message we need to confirm that it came from a real email address. To confirm your message, you can either: 1) Reply to this message, without altering the subject line The "Re: " added by many mail clients is OK, but please note that this method is *not* foolproof. or 2) Visit the URL If you want to be very sure that your message gets through, do both steps above -- it does no harm to confirm more than once. For your reference, the subject of the message you sent was: "{Filename?} Re: Thanks :)" and it arrived at IANA approximately at Fri Oct 29 03:27:40 2004. --------------------------------------------------------------- ConfirmSystem: iana@icann.org [[83f3d701c0925134]] 2 From: iana at iana.org (iana@iana.org) Date: Tue Jan 3 16:22:51 2006 Subject: ConfirmSystem: iana@icann.org [[f27213adb9130923]] Message-ID: <200410290805.i9T85bU13544@santee.icann.org> Thank you for your message. The iana@iana.org address collects a tremendous amount of spam, and we have been forced to implement protective measures. In order to process your message we need to confirm that it came from a real email address. To confirm your message, you can either: 1) Reply to this message, without altering the subject line The "Re: " added by many mail clients is OK, but please note that this method is *not* foolproof. or 2) Visit the URL If you want to be very sure that your message gets through, do both steps above -- it does no harm to confirm more than once. For your reference, the subject of the message you sent was: "{Filename?} Re: Hi" and it arrived at IANA approximately at Fri Oct 29 01:05:37 2004. --------------------------------------------------------------- ConfirmSystem: iana@icann.org [[f27213adb9130923]] 1 From: ned.freed at mrochek.com (ned.freed@mrochek.com) Date: Thu Oct 28 17:43:52 2004 Subject: Pre review of 3GPP MIME type for RTP payload format In-Reply-To: "Your message dated Wed, 27 Oct 2004 13:40:05 +0200" <417F8915.1040305@ericsson.com> References: <411B666A.1070509@ericsson.com> <417F8915.1040305@ericsson.com> Message-ID: <01LGK4NZ2ZJ200005R@mauve.mrochek.com> > U have a question about the usage of "." in the subtype name. Is this > usage okay, Not unless there's a specification for an rtp facet I'm unaware of. > as it can/should be interpret as belonging to a tree named RTP? Exactly. The first dot in a media type name serves as a separator between the facet name and the remainder of the type name. At one point I specified an std. facet so that names could be registered in the standards tree with dots in them, but everyone else pretty much hated the notion so I dropped it. Ned >From iana@iana.org Fri Oct 29 10:05:37 2004 From: iana at iana.org (iana@iana.org) Date: Fri Oct 29 10:05:47 2004 Subject: ConfirmSystem: iana@icann.org [[f27213adb9130923]] Message-ID: <200410290805.i9T85bU13544@santee.icann.org> Thank you for your message. The iana@iana.org address collects a tremendous amount of spam, and we have been forced to implement protective measures. In order to process your message we need to confirm that it came from a real email address. To confirm your message, you can either: 1) Reply to this message, without altering the subject line The "Re: " added by many mail clients is OK, but please note that this method is *not* foolproof. or 2) Visit the URL If you want to be very sure that your message gets through, do both steps above -- it does no harm to confirm more than once. For your reference, the subject of the message you sent was: "{Filename?} Re: Hi" and it arrived at IANA approximately at Fri Oct 29 01:05:37 2004. --------------------------------------------------------------- ConfirmSystem: iana@icann.org [[f27213adb9130923]] 1 From: ned.freed at mrochek.com (ned.freed@mrochek.com) Date: Tue Jan 3 16:22:51 2006 Subject: Pre review of 3GPP MIME type for RTP payload format In-Reply-To: "Your message dated Wed, 27 Oct 2004 13:40:05 +0200" <417F8915.1040305@ericsson.com> References: <411B666A.1070509@ericsson.com> <417F8915.1040305@ericsson.com> Message-ID: <01LGK4NZ2ZJ200005R@mauve.mrochek.com> > U have a question about the usage of "." in the subtype name. Is this > usage okay, Not unless there's a specification for an rtp facet I'm unaware of. > as it can/should be interpret as belonging to a tree named RTP? Exactly. The first dot in a media type name serves as a separator between the facet name and the remainder of the type name. At one point I specified an std. facet so that names could be registered in the standards tree with dots in them, but everyone else pretty much hated the notion so I dropped it. Ned From: csp at csperkins.org (Colin Perkins) Date: Tue Jan 3 16:22:51 2006 Subject: Comments on draft-freed-media-types-reg-01.txt In-Reply-To: <20041027183455.GA7564@osiris.mauzo.dyndns.org> References: <01LF8MCCIOM400005R@mauve.mrochek.com> <01LFATFLKFG600005R@mauve.mrochek.com> <01LFLB1HN9SU00005R@mauve.mrochek.com> <4C2DF04E-1587-11D9-B636-000A957FC5F2@csperkins.org> <01LFLM83HHTG00005R@mauve.mrochek.com> <6E33DC8A-1597-11D9-B636-000A957FC5F2@csperkins.org> <41793590.6020904@ericsson.com> <20041027183455.GA7564@osiris.mauzo.dyndns.org> Message-ID: <0ED3517A-2861-11D9-AFD3-000A957FC5F2@csperkins.org> On 27 Oct 2004, at 19:34, Ben Morrow wrote: > At 4pm on 27/10/04 you (Colin Perkins) wrote: >> I'd also like to see a resolution of this, since we have new RTP >> payload formats under development that need MIME types to be assigned, >> and it's clear there are different understandings of the rules. > > What would people think about standardising the suffix '+rtp' for RTP > media types that differ from their on-disk format? Then we could > unabiguously have two types video/foo and video/foo+rtp, with a clear > relationship between them. This raises the issue of whether it's worth sharing the namespace between RTP and other users, but yes. > FWIW, I would agree that having incompatible formats given the same > type > but 'in different domains' is a very bad idea. Data has a nasty habit > of > leaking between 'domains' :) Sure, I have no problem with that. I'm just looking for clarification in the draft on what makes formats incompatible, since the boundary doesn't seem to be well defined (especially if the concept of framed data formats is accepted). This discussion came about since there are existing formats sharing a name which some consider to be compatible, but others consider incompatible. Colin From: ben at morrow.me.uk (Ben Morrow) Date: Wed Oct 27 23:11:53 2004 Subject: Comments on draft-freed-media-types-reg-01.txt In-Reply-To: References: <01LF8MCCIOM400005R@mauve.mrochek.com> <01LFATFLKFG600005R@mauve.mrochek.com> <01LFLB1HN9SU00005R@mauve.mrochek.com> <4C2DF04E-1587-11D9-B636-000A957FC5F2@csperkins.org> <01LFLM83HHTG00005R@mauve.mrochek.com> <6E33DC8A-1597-11D9-B636-000A957FC5F2@csperkins.org> <41793590.6020904@ericsson.com> Message-ID: <20041027183455.GA7564@osiris.mauzo.dyndns.org> At 4pm on 27/10/04 you (Colin Perkins) wrote: > I'd also like to see a resolution of this, since we have new RTP > payload formats under development that need MIME types to be assigned, > and it's clear there are different understandings of the rules. What would people think about standardising the suffix '+rtp' for RTP media types that differ from their on-disk format? Then we could unabiguously have two types video/foo and video/foo+rtp, with a clear relationship between them. FWIW, I would agree that having incompatible formats given the same type but 'in different domains' is a very bad idea. Data has a nasty habit of leaking between 'domains' :) Ben -- The cosmos, at best, is like a rubbish heap scattered at random. - Heraclitus ben@morrow.me.uk >From csp@csperkins.org Wed Oct 27 23:42:10 2004 From: csp at csperkins.org (Colin Perkins) Date: Wed Oct 27 23:42:27 2004 Subject: Comments on draft-freed-media-types-reg-01.txt In-Reply-To: <20041027183455.GA7564@osiris.mauzo.dyndns.org> References: <01LF8MCCIOM400005R@mauve.mrochek.com> <01LFATFLKFG600005R@mauve.mrochek.com> <01LFLB1HN9SU00005R@mauve.mrochek.com> <4C2DF04E-1587-11D9-B636-000A957FC5F2@csperkins.org> <01LFLM83HHTG00005R@mauve.mrochek.com> <6E33DC8A-1597-11D9-B636-000A957FC5F2@csperkins.org> <41793590.6020904@ericsson.com> <20041027183455.GA7564@osiris.mauzo.dyndns.org> Message-ID: <0ED3517A-2861-11D9-AFD3-000A957FC5F2@csperkins.org> On 27 Oct 2004, at 19:34, Ben Morrow wrote: > At 4pm on 27/10/04 you (Colin Perkins) wrote: >> I'd also like to see a resolution of this, since we have new RTP >> payload formats under development that need MIME types to be assigned, >> and it's clear there are different understandings of the rules. > > What would people think about standardising the suffix '+rtp' for RTP > media types that differ from their on-disk format? Then we could > unabiguously have two types video/foo and video/foo+rtp, with a clear > relationship between them. This raises the issue of whether it's worth sharing the namespace between RTP and other users, but yes. > FWIW, I would agree that having incompatible formats given the same > type > but 'in different domains' is a very bad idea. Data has a nasty habit > of > leaking between 'domains' :) Sure, I have no problem with that. I'm just looking for clarification in the draft on what makes formats incompatible, since the boundary doesn't seem to be well defined (especially if the concept of framed data formats is accepted). This discussion came about since there are existing formats sharing a name which some consider to be compatible, but others consider incompatible. Colin From: ben at morrow.me.uk (Ben Morrow) Date: Tue Jan 3 16:22:50 2006 Subject: Comments on draft-freed-media-types-reg-01.txt In-Reply-To: References: <01LF8MCCIOM400005R@mauve.mrochek.com> <01LFATFLKFG600005R@mauve.mrochek.com> <01LFLB1HN9SU00005R@mauve.mrochek.com> <4C2DF04E-1587-11D9-B636-000A957FC5F2@csperkins.org> <01LFLM83HHTG00005R@mauve.mrochek.com> <6E33DC8A-1597-11D9-B636-000A957FC5F2@csperkins.org> <41793590.6020904@ericsson.com> Message-ID: <20041027183455.GA7564@osiris.mauzo.dyndns.org> At 4pm on 27/10/04 you (Colin Perkins) wrote: > I'd also like to see a resolution of this, since we have new RTP > payload formats under development that need MIME types to be assigned, > and it's clear there are different understandings of the rules. What would people think about standardising the suffix '+rtp' for RTP media types that differ from their on-disk format? Then we could unabiguously have two types video/foo and video/foo+rtp, with a clear relationship between them. FWIW, I would agree that having incompatible formats given the same type but 'in different domains' is a very bad idea. Data has a nasty habit of leaking between 'domains' :) Ben -- The cosmos, at best, is like a rubbish heap scattered at random. - Heraclitus ben@morrow.me.uk From: csp at csperkins.org (Colin Perkins) Date: Tue Jan 3 16:22:50 2006 Subject: Comments on draft-freed-media-types-reg-01.txt In-Reply-To: <41793590.6020904@ericsson.com> References: <413DC83F.7070807@ericsson.com> <01LEKW44X2UM00005R@mauve.mrochek.com> <413F03BF.5040407@ericsson.com> <01LEM6VYBBDE00005R@mauve.mrochek.com> <4CDCE53A-03DE-11D9-A048-000A957FC5F2@csperkins.org> <01LEQL2HYS4000005R@mauve.mrochek.com> <01LF8MCCIOM400005R@mauve.mrochek.com> <01LFATFLKFG600005R@mauve.mrochek.com> <01LFLB1HN9SU00005R@mauve.mrochek.com> <4C2DF04E-1587-11D9-B636-000A957FC5F2@csperkins.org> <01LFLM83HHTG00005R@mauve.mrochek.com> <6E33DC8A-1597-11D9-B636-000A957FC5F2@csperkins.org> <41793590.6020904@ericsson.com> Message-ID: I'd also like to see a resolution of this, since we have new RTP payload formats under development that need MIME types to be assigned, and it's clear there are different understandings of the rules. We have two proposed standard RFCs (RFCs 3267 and 3558) which register the same media type for the RTP Payload Format and for the File Format. At the time those RFCs were written, the AVT working group considered them to be the same format (as the data is identical between the file format and the RTP payload format, with only the framing differing). I can only assume the that the IESG agreed, since each format was registered using the same media type name for the two different framing methods. It's now clear that Ned (and others) don't regard it appropriate for a file format and an RTP payload format to use the same media type. This is a conflict which needs to be resolved, both to clarify the status of the existing registrations and to make sure that we do the right thing with the many new RTP payload formats under development. I don't care which way it's resolved* but the fact that we have this discussion (and existing practice which conflicts with some interpretations of the rules) implies that the registration rules need clarification, and is the reason for my questions. Colin * to be clear: I'm not an author on RFC 3267 or 3558, nor do I sell product based on either, nor am I trying to register a new media type. I am however the person stuck with having to resolve the conflict between those two RFCs and the interpretation of the rules I'm hearing on this list. On 22 Oct 2004, at 17:30, Magnus Westerlund wrote: > Hi Ned, > > We need to resolve this. And I do not consider it resolved as long as > it is not sufficient motivated and way of handling the already > approved specifications is indicated. > > I can understand the need for caution if registering different > parameters for different applicability. How does one clarify what is > acceptable, and what is not? Thus please answer Colin's questions > below in attempt to define some borders. > > Is your point that if you need a different piece of software to > correctly handle the data, then it is another type. Like the fact that > you need to have a handler of RTP timestamp that sorts frame correctly > for AMR RTP payload format, while the file format only needs to be > able to read the frames in sequence to get the order? > > Secondly how does we handle the already registered types? They are > almost impossible to change due to the deployed base of at least some > of the types. The file format for AMR is deployed in a couple of > millions mobile phones that support MMS. Do we only leave them in as > anomalies in the system? > > > Cheers > > Magnus > > > Colin Perkins wrote: >>> >>> File header/magic number != framing in my book. >> So, what do you mean by framing? In the examples I'm quoting, the >> media >> data format is bitwise identical in both cases. The difference is >> that >> it's framed in a file (and hence has a file header) rather than a >> series >> of RTP packets (and hence has an RTP header); once you strip the >> framing >> there is no difference in format. >>> And this will be my last message on this topic. >> Which doesn't resolve the conflict between draft-freed-media-types-reg >> -01.txt and existing practice. Much as you may dislike it, there are >> two >> proposed standards (RFC 3267 and 3558) which register formats in the >> way >> I describe. The change you propose is problematic for a significant >> user >> community, which has previously registered these types in good faith, >> according to IETF procedures. >> Colin > > > -- > > Magnus Westerlund > > Multimedia Technologies, Ericsson Research EAB/TVA/A > ---------------------------------------------------------------------- > Ericsson AB | Phone +46 8 4048287 > Torshamsgatan 23 | Fax +46 8 7575550 > S-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com From: magnus.westerlund at ericsson.com (Magnus Westerlund) Date: Tue Jan 3 16:22:50 2006 Subject: Pre review of 3GPP MIME type for RTP payload format In-Reply-To: <411B666A.1070509@ericsson.com> References: <411B666A.1070509@ericsson.com> Message-ID: <417F8915.1040305@ericsson.com> Hi, U have a question about the usage of "." in the subtype name. Is this usage okay, as it can/should be interpret as belonging to a tree named RTP? Magnus Westerlund wrote: > MIME media type name: audio, video, text, application, image > > MIME subtype name: rtp.enc.aescm128 > Please advice Cheers Magnus Westerlund Multimedia Technologies, Ericsson Research EAB/TVA/A ---------------------------------------------------------------------- Ericsson AB | Phone +46 8 4048287 Torshamsgatan 23 | Fax +46 8 7575550 S-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com From: blilly at erols.com (Bruce Lilly) Date: Tue Jan 3 16:22:50 2006 Subject: Post-facto reporting of media type security considerations In-Reply-To: <01LGAD309GE600005R@mauve.mrochek.com> References: <200410181008.03466.blilly@erols.com> <200410202024.45343.blilly@erols.com> <01LGAD309GE600005R@mauve.mrochek.com> Message-ID: <200410231046.51608.blilly@erols.com> On Thu October 21 2004 11:47, ned.freed@mrochek.com wrote: > The IANA is no more capable or incapable than anyone else to write an RFC > commenting on something. Whether or not such an RFC would get published is > another matter, of course - such documents have been published in the past, but > the practice of writing "commentary" RFCs has become less common in recent > years, perhaps because the initial vetting and approval process has been > improved to the point where it isn't nearly as useful to create such things. Agreed about IANA's capability for additional commentary RFCs, which is a somewhat different matter from superseding or obsoleting an RFC which is in need of an update. Some problems with commentary RFCs are that it becomes difficult to keep track of exactly what has been modified and in what way, and that they tend to scatter related information through multiple non-consecutive documents, with little clue to the reader of the original document that something has been changed. That, coupled with the relative ease with with documents can now be revised probably also account for the decline in the number of pure commentary RFCs. > Again, since the comments mechanism has never been used, whereas the ability to > revise registrations has been used on quite a few occasions, I think this is a > case of worrying about a purely hypothetical problem that seems unlikely to > become real. We have a backlog of pernicious problems causing us considerable > grief that need to be solved; I simply cannot see the point in spending time on > this. My initial queries were intended to gauge whether or not the mechanisms were considered current and useful before making use of those mechanisms. I gather that the brief answer is that they are believed to be largely current and useful, but have not been tested. Initially I had one media type in mind, defined in the core MIME RFCs. While subsequently looking for an indication that the commentary mechanism might have been used, I found a rather obvious case of another media type in the standard tree, registered via a text form rather than an RFC, which is in need of an update. I plan to make use of the commentary mechanism for those two types. In the case of the text registration, I plan to request IANA to attach comments to the registration. I do not plan to do so for the core MIME RFC type under consideration, and I do plan to copy the RFC authors (that would be you Ned, and Nat Borenstein; I have already had some initial correspondence with Nat regarding the media type in question, for which the relevant issues are touched upon in RFC 1344, which has not kept pace with other MIME RFC updates). For the record, my queries and comments regarding commentary vs. RFCs and RFC updates are not intended to indicate any expectation of problems or to reflect on you or Nat, but instead arise out of past experience regarding RFC updates (non-security-related and not media type related) where authors have declined to consider revisions due to discontinued interest in the subject matter; to reiterate, I do not expect that to be the case with the issue at hand. From: magnus.westerlund at ericsson.com (Magnus Westerlund) Date: Tue Jan 3 16:22:50 2006 Subject: [AVT] Re: Comments on draft-freed-media-types-reg-01.txt In-Reply-To: <6E33DC8A-1597-11D9-B636-000A957FC5F2@csperkins.org> References: <413DC83F.7070807@ericsson.com> <01LEKW44X2UM00005R@mauve.mrochek.com> <413F03BF.5040407@ericsson.com> <01LEM6VYBBDE00005R@mauve.mrochek.com> <4CDCE53A-03DE-11D9-A048-000A957FC5F2@csperkins.org> <01LEQL2HYS4000005R@mauve.mrochek.com> <01LF8MCCIOM400005R@mauve.mrochek.com> <01LFATFLKFG600005R@mauve.mrochek.com> <01LFLB1HN9SU00005R@mauve.mrochek.com> <4C2DF04E-1587-11D9-B636-000A957FC5F2@csperkins.org> <01LFLM83HHTG00005R@mauve.mrochek.com> <6E33DC8A-1597-11D9-B636-000A957FC5F2@csperkins.org> Message-ID: <41793590.6020904@ericsson.com> Hi Ned, We need to resolve this. And I do not consider it resolved as long as it is not sufficient motivated and way of handling the already approved specifications is indicated. I can understand the need for caution if registering different parameters for different applicability. How does one clarify what is acceptable, and what is not? Thus please answer Colin's questions below in attempt to define some borders. Is your point that if you need a different piece of software to correctly handle the data, then it is another type. Like the fact that you need to have a handler of RTP timestamp that sorts frame correctly for AMR RTP payload format, while the file format only needs to be able to read the frames in sequence to get the order? Secondly how does we handle the already registered types? They are almost impossible to change due to the deployed base of at least some of the types. The file format for AMR is deployed in a couple of millions mobile phones that support MMS. Do we only leave them in as anomalies in the system? Cheers Magnus Colin Perkins wrote: >> >> File header/magic number != framing in my book. > > > So, what do you mean by framing? In the examples I'm quoting, the media > data format is bitwise identical in both cases. The difference is that > it's framed in a file (and hence has a file header) rather than a series > of RTP packets (and hence has an RTP header); once you strip the framing > there is no difference in format. > >> And this will be my last message on this topic. > > > Which doesn't resolve the conflict between draft-freed-media-types-reg > -01.txt and existing practice. Much as you may dislike it, there are two > proposed standards (RFC 3267 and 3558) which register formats in the way > I describe. The change you propose is problematic for a significant user > community, which has previously registered these types in good faith, > according to IETF procedures. > > Colin > -- Magnus Westerlund Multimedia Technologies, Ericsson Research EAB/TVA/A ---------------------------------------------------------------------- Ericsson AB | Phone +46 8 4048287 Torshamsgatan 23 | Fax +46 8 7575550 S-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com From: ned.freed at mrochek.com (ned.freed@mrochek.com) Date: Thu Oct 21 17:57:11 2004 Subject: Post-facto reporting of media type security considerations In-Reply-To: "Your message dated Wed, 20 Oct 2004 20:24:45 -0400" <200410202024.45343.blilly@erols.com> References: <200410181008.03466.blilly@erols.com> <01LG8A2JGHCW00005R@mauve.mrochek.com> <200410202024.45343.blilly@erols.com> Message-ID: <01LGAD309GE600005R@mauve.mrochek.com> > On Wed October 20 2004 00:02, ned.freed@mrochek.com wrote: > > > 2. Media types can be registered via a textual form alone, or in an RFC. > > > It seems unlikely that IANA can attach comments to an RFC, as RFCs > > > are supposed to remain unchanged once published. There is a > > > somewhat obscure errata page, but that's managed by the RFC > > > Editor, not IANA. I therefore believe that the RFC 2048 procedure > > > as written is not entirely adequate. Comments? > > > > I disagree. The process for revising an RFC is to issue a revised RFC. I see no > > reason to create yet another process to put this information elsewhere. > I'm not suggesting putting the information elsewhere; merely that > IANA may lack the ability to issue a revised RFC (e.g. if the author > is unable or unwilling to make a revision). The IANA is no more capable or incapable than anyone else to write an RFC commenting on something. Whether or not such an RFC would get published is another matter, of course - such documents have been published in the past, but the practice of writing "commentary" RFCs has become less common in recent years, perhaps because the initial vetting and approval process has been improved to the point where it isn't nearly as useful to create such things. Again, since the comments mechanism has never been used, whereas the ability to revise registrations has been used on quite a few occasions, I think this is a case of worrying about a purely hypothetical problem that seems unlikely to become real. We have a backlog of pernicious problems causing us considerable grief that need to be solved; I simply cannot see the point in spending time on this. I'd feel differently if the comments mechanism had been used and found to be lacking in some way. But it (vacuously) hasn't. Ned >From magnus.westerlund@ericsson.com Fri Oct 22 18:30:08 2004 From: magnus.westerlund at ericsson.com (Magnus Westerlund) Date: Fri Oct 22 18:30:22 2004 Subject: [AVT] Re: Comments on draft-freed-media-types-reg-01.txt In-Reply-To: <6E33DC8A-1597-11D9-B636-000A957FC5F2@csperkins.org> References: <413DC83F.7070807@ericsson.com> <01LEKW44X2UM00005R@mauve.mrochek.com> <413F03BF.5040407@ericsson.com> <01LEM6VYBBDE00005R@mauve.mrochek.com> <4CDCE53A-03DE-11D9-A048-000A957FC5F2@csperkins.org> <01LEQL2HYS4000005R@mauve.mrochek.com> <01LF8MCCIOM400005R@mauve.mrochek.com> <01LFATFLKFG600005R@mauve.mrochek.com> <01LFLB1HN9SU00005R@mauve.mrochek.com> <4C2DF04E-1587-11D9-B636-000A957FC5F2@csperkins.org> <01LFLM83HHTG00005R@mauve.mrochek.com> <6E33DC8A-1597-11D9-B636-000A957FC5F2@csperkins.org> Message-ID: <41793590.6020904@ericsson.com> Hi Ned, We need to resolve this. And I do not consider it resolved as long as it is not sufficient motivated and way of handling the already approved specifications is indicated. I can understand the need for caution if registering different parameters for different applicability. How does one clarify what is acceptable, and what is not? Thus please answer Colin's questions below in attempt to define some borders. Is your point that if you need a different piece of software to correctly handle the data, then it is another type. Like the fact that you need to have a handler of RTP timestamp that sorts frame correctly for AMR RTP payload format, while the file format only needs to be able to read the frames in sequence to get the order? Secondly how does we handle the already registered types? They are almost impossible to change due to the deployed base of at least some of the types. The file format for AMR is deployed in a couple of millions mobile phones that support MMS. Do we only leave them in as anomalies in the system? Cheers Magnus Colin Perkins wrote: >> >> File header/magic number != framing in my book. > > > So, what do you mean by framing? In the examples I'm quoting, the media > data format is bitwise identical in both cases. The difference is that > it's framed in a file (and hence has a file header) rather than a series > of RTP packets (and hence has an RTP header); once you strip the framing > there is no difference in format. > >> And this will be my last message on this topic. > > > Which doesn't resolve the conflict between draft-freed-media-types-reg > -01.txt and existing practice. Much as you may dislike it, there are two > proposed standards (RFC 3267 and 3558) which register formats in the way > I describe. The change you propose is problematic for a significant user > community, which has previously registered these types in good faith, > according to IETF procedures. > > Colin > -- Magnus Westerlund Multimedia Technologies, Ericsson Research EAB/TVA/A ---------------------------------------------------------------------- Ericsson AB | Phone +46 8 4048287 Torshamsgatan 23 | Fax +46 8 7575550 S-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com >From blilly@erols.com Sat Oct 23 16:46:50 2004 From: blilly at erols.com (Bruce Lilly) Date: Sat Oct 23 21:08:15 2004 Subject: Post-facto reporting of media type security considerations In-Reply-To: <01LGAD309GE600005R@mauve.mrochek.com> References: <200410181008.03466.blilly@erols.com> <200410202024.45343.blilly@erols.com> <01LGAD309GE600005R@mauve.mrochek.com> Message-ID: <200410231046.51608.blilly@erols.com> On Thu October 21 2004 11:47, ned.freed@mrochek.com wrote: > The IANA is no more capable or incapable than anyone else to write an RFC > commenting on something. Whether or not such an RFC would get published is > another matter, of course - such documents have been published in the past, but > the practice of writing "commentary" RFCs has become less common in recent > years, perhaps because the initial vetting and approval process has been > improved to the point where it isn't nearly as useful to create such things. Agreed about IANA's capability for additional commentary RFCs, which is a somewhat different matter from superseding or obsoleting an RFC which is in need of an update. Some problems with commentary RFCs are that it becomes difficult to keep track of exactly what has been modified and in what way, and that they tend to scatter related information through multiple non-consecutive documents, with little clue to the reader of the original document that something has been changed. That, coupled with the relative ease with with documents can now be revised probably also account for the decline in the number of pure commentary RFCs. > Again, since the comments mechanism has never been used, whereas the ability to > revise registrations has been used on quite a few occasions, I think this is a > case of worrying about a purely hypothetical problem that seems unlikely to > become real. We have a backlog of pernicious problems causing us considerable > grief that need to be solved; I simply cannot see the point in spending time on > this. My initial queries were intended to gauge whether or not the mechanisms were considered current and useful before making use of those mechanisms. I gather that the brief answer is that they are believed to be largely current and useful, but have not been tested. Initially I had one media type in mind, defined in the core MIME RFCs. While subsequently looking for an indication that the commentary mechanism might have been used, I found a rather obvious case of another media type in the standard tree, registered via a text form rather than an RFC, which is in need of an update. I plan to make use of the commentary mechanism for those two types. In the case of the text registration, I plan to request IANA to attach comments to the registration. I do not plan to do so for the core MIME RFC type under consideration, and I do plan to copy the RFC authors (that would be you Ned, and Nat Borenstein; I have already had some initial correspondence with Nat regarding the media type in question, for which the relevant issues are touched upon in RFC 1344, which has not kept pace with other MIME RFC updates). For the record, my queries and comments regarding commentary vs. RFCs and RFC updates are not intended to indicate any expectation of problems or to reflect on you or Nat, but instead arise out of past experience regarding RFC updates (non-security-related and not media type related) where authors have declined to consider revisions due to discontinued interest in the subject matter; to reiterate, I do not expect that to be the case with the issue at hand. >From magnus.westerlund@ericsson.com Wed Oct 27 13:40:05 2004 From: magnus.westerlund at ericsson.com (Magnus Westerlund) Date: Wed Oct 27 13:40:12 2004 Subject: Pre review of 3GPP MIME type for RTP payload format In-Reply-To: <411B666A.1070509@ericsson.com> References: <411B666A.1070509@ericsson.com> Message-ID: <417F8915.1040305@ericsson.com> Hi, U have a question about the usage of "." in the subtype name. Is this usage okay, as it can/should be interpret as belonging to a tree named RTP? Magnus Westerlund wrote: > MIME media type name: audio, video, text, application, image > > MIME subtype name: rtp.enc.aescm128 > Please advice Cheers Magnus Westerlund Multimedia Technologies, Ericsson Research EAB/TVA/A ---------------------------------------------------------------------- Ericsson AB | Phone +46 8 4048287 Torshamsgatan 23 | Fax +46 8 7575550 S-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com >From csp@csperkins.org Wed Oct 27 17:28:41 2004 From: csp at csperkins.org (Colin Perkins) Date: Wed Oct 27 17:28:59 2004 Subject: Comments on draft-freed-media-types-reg-01.txt In-Reply-To: <41793590.6020904@ericsson.com> References: <413DC83F.7070807@ericsson.com> <01LEKW44X2UM00005R@mauve.mrochek.com> <413F03BF.5040407@ericsson.com> <01LEM6VYBBDE00005R@mauve.mrochek.com> <4CDCE53A-03DE-11D9-A048-000A957FC5F2@csperkins.org> <01LEQL2HYS4000005R@mauve.mrochek.com> <01LF8MCCIOM400005R@mauve.mrochek.com> <01LFATFLKFG600005R@mauve.mrochek.com> <01LFLB1HN9SU00005R@mauve.mrochek.com> <4C2DF04E-1587-11D9-B636-000A957FC5F2@csperkins.org> <01LFLM83HHTG00005R@mauve.mrochek.com> <6E33DC8A-1597-11D9-B636-000A957FC5F2@csperkins.org> <41793590.6020904@ericsson.com> Message-ID: I'd also like to see a resolution of this, since we have new RTP payload formats under development that need MIME types to be assigned, and it's clear there are different understandings of the rules. We have two proposed standard RFCs (RFCs 3267 and 3558) which register the same media type for the RTP Payload Format and for the File Format. At the time those RFCs were written, the AVT working group considered them to be the same format (as the data is identical between the file format and the RTP payload format, with only the framing differing). I can only assume the that the IESG agreed, since each format was registered using the same media type name for the two different framing methods. It's now clear that Ned (and others) don't regard it appropriate for a file format and an RTP payload format to use the same media type. This is a conflict which needs to be resolved, both to clarify the status of the existing registrations and to make sure that we do the right thing with the many new RTP payload formats under development. I don't care which way it's resolved* but the fact that we have this discussion (and existing practice which conflicts with some interpretations of the rules) implies that the registration rules need clarification, and is the reason for my questions. Colin * to be clear: I'm not an author on RFC 3267 or 3558, nor do I sell product based on either, nor am I trying to register a new media type. I am however the person stuck with having to resolve the conflict between those two RFCs and the interpretation of the rules I'm hearing on this list. On 22 Oct 2004, at 17:30, Magnus Westerlund wrote: > Hi Ned, > > We need to resolve this. And I do not consider it resolved as long as > it is not sufficient motivated and way of handling the already > approved specifications is indicated. > > I can understand the need for caution if registering different > parameters for different applicability. How does one clarify what is > acceptable, and what is not? Thus please answer Colin's questions > below in attempt to define some borders. > > Is your point that if you need a different piece of software to > correctly handle the data, then it is another type. Like the fact that > you need to have a handler of RTP timestamp that sorts frame correctly > for AMR RTP payload format, while the file format only needs to be > able to read the frames in sequence to get the order? > > Secondly how does we handle the already registered types? They are > almost impossible to change due to the deployed base of at least some > of the types. The file format for AMR is deployed in a couple of > millions mobile phones that support MMS. Do we only leave them in as > anomalies in the system? > > > Cheers > > Magnus > > > Colin Perkins wrote: >>> >>> File header/magic number != framing in my book. >> So, what do you mean by framing? In the examples I'm quoting, the >> media >> data format is bitwise identical in both cases. The difference is >> that >> it's framed in a file (and hence has a file header) rather than a >> series >> of RTP packets (and hence has an RTP header); once you strip the >> framing >> there is no difference in format. >>> And this will be my last message on this topic. >> Which doesn't resolve the conflict between draft-freed-media-types-reg >> -01.txt and existing practice. Much as you may dislike it, there are >> two >> proposed standards (RFC 3267 and 3558) which register formats in the >> way >> I describe. The change you propose is problematic for a significant >> user >> community, which has previously registered these types in good faith, >> according to IETF procedures. >> Colin > > > -- > > Magnus Westerlund > > Multimedia Technologies, Ericsson Research EAB/TVA/A > ---------------------------------------------------------------------- > Ericsson AB | Phone +46 8 4048287 > Torshamsgatan 23 | Fax +46 8 7575550 > S-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com From: ned.freed at mrochek.com (ned.freed@mrochek.com) Date: Tue Jan 3 16:22:50 2006 Subject: Post-facto reporting of media type security considerations In-Reply-To: "Your message dated Wed, 20 Oct 2004 20:24:45 -0400" <200410202024.45343.blilly@erols.com> References: <200410181008.03466.blilly@erols.com> <01LG8A2JGHCW00005R@mauve.mrochek.com> <200410202024.45343.blilly@erols.com> Message-ID: <01LGAD309GE600005R@mauve.mrochek.com> > On Wed October 20 2004 00:02, ned.freed@mrochek.com wrote: > > > 2. Media types can be registered via a textual form alone, or in an RFC. > > > It seems unlikely that IANA can attach comments to an RFC, as RFCs > > > are supposed to remain unchanged once published. There is a > > > somewhat obscure errata page, but that's managed by the RFC > > > Editor, not IANA. I therefore believe that the RFC 2048 procedure > > > as written is not entirely adequate. Comments? > > > > I disagree. The process for revising an RFC is to issue a revised RFC. I see no > > reason to create yet another process to put this information elsewhere. > I'm not suggesting putting the information elsewhere; merely that > IANA may lack the ability to issue a revised RFC (e.g. if the author > is unable or unwilling to make a revision). The IANA is no more capable or incapable than anyone else to write an RFC commenting on something. Whether or not such an RFC would get published is another matter, of course - such documents have been published in the past, but the practice of writing "commentary" RFCs has become less common in recent years, perhaps because the initial vetting and approval process has been improved to the point where it isn't nearly as useful to create such things. Again, since the comments mechanism has never been used, whereas the ability to revise registrations has been used on quite a few occasions, I think this is a case of worrying about a purely hypothetical problem that seems unlikely to become real. We have a backlog of pernicious problems causing us considerable grief that need to be solved; I simply cannot see the point in spending time on this. I'd feel differently if the comments mechanism had been used and found to be lacking in some way. But it (vacuously) hasn't. Ned From: duerst at w3.org (Martin Duerst) Date: Tue Jan 3 16:22:50 2006 Subject: Post-facto reporting of media type security considerations In-Reply-To: <200410202024.45343.blilly@erols.com> References: <200410181008.03466.blilly@erols.com> <01LG8A2JGHCW00005R@mauve.mrochek.com> <200410202024.45343.blilly@erols.com> Message-ID: <6.0.0.20.2.20041021112404.063983e0@localhost> At 09:24 04/10/21, Bruce Lilly wrote: >I'm not suggesting putting the information elsewhere; merely that >IANA may lack the ability to issue a revised RFC (e.g. if the author >is unable or unwilling to make a revision). It wouldn't necessarily have to be the original author who would put out a revised RFC. If it were seen really necessary, somebody else could do it. Of course, it wouldn't be IANA but a tird-party volunteer, so in some sense, you are still right. Regards, Martin. From: blilly at erols.com (Bruce Lilly) Date: Tue Jan 3 16:22:50 2006 Subject: Post-facto reporting of media type security considerations In-Reply-To: <01LG8A2JGHCW00005R@mauve.mrochek.com> References: <200410181008.03466.blilly@erols.com> <01LG8A2JGHCW00005R@mauve.mrochek.com> Message-ID: <200410202024.45343.blilly@erols.com> On Wed October 20 2004 00:02, ned.freed@mrochek.com wrote: > > 2. Media types can be registered via a textual form alone, or in an RFC. > > It seems unlikely that IANA can attach comments to an RFC, as RFCs > > are supposed to remain unchanged once published. There is a > > somewhat obscure errata page, but that's managed by the RFC > > Editor, not IANA. I therefore believe that the RFC 2048 procedure > > as written is not entirely adequate. Comments? > > I disagree. The process for revising an RFC is to issue a revised RFC. I see no > reason to create yet another process to put this information elsewhere. I'm not suggesting putting the information elsewhere; merely that IANA may lack the ability to issue a revised RFC (e.g. if the author is unable or unwilling to make a revision). From: blilly at erols.com (Bruce Lilly) Date: Tue Jan 3 16:22:50 2006 Subject: Post-facto reporting of media type security considerations In-Reply-To: <6.0.0.20.2.20041019120002.05e47b00@localhost> References: <200410181008.03466.blilly@erols.com> <6.0.0.20.2.20041019120002.05e47b00@localhost> Message-ID: <200410201043.03377.blilly@erols.com> On Mon October 18 2004 23:17, Martin Duerst wrote: > The new registration procedure for mime types is at > http://www.ietf.org/internet-drafts/draft-freed-media-type-reg-01.txt. Thanks, Martin; I'll take a look at it. > P.S.: It seems that our setting of the 'Reply-To' header has > prompted the IANA anti-spam system to send its message to > the list rather than to you only. Any way, on either your > or IANAs side, to avoid that? Setting Reply-To to point to the list expander mailbox (in accordance with RFC 822 section 4.4.2) enables responses to the list w/o requiring respondents to use a reply-to-all function which would have the effect of sending copies of responses to IANA (setting Reply-To doesn't prevent anybody from sending copies anywhere though). It appears that IANA sends its automated confirmation notices to the mailbox list in the Reply-To field rather than to the sender envelope address as recommended by RFC 3834 (section 4). It would be nice if IANA would update its automatic responder to comply with the RFC 3834 recommendations. [I'll remail a separate copy of this to IANA] From: ned.freed at mrochek.com (ned.freed@mrochek.com) Date: Wed Oct 20 06:08:57 2004 Subject: Post-facto reporting of media type security considerations In-Reply-To: "Your message dated Mon, 18 Oct 2004 10:08:02 -0400" <200410181008.03466.blilly@erols.com> References: <200410181008.03466.blilly@erols.com> Message-ID: <01LG8A2JGHCW00005R@mauve.mrochek.com> > [This message has been sent to the ietf-types mailing list with a courtesy > copy to IANA (as IANA issues are raised); I have suggested responses > be directed to the ietf-types list] > There are some media types for which security issues have become known > since the original type registrations. RFC 2048 has a provision for reporting > such issues: > 2.2.6. Security Requirements > [...] > The security considerations section of all registrations is subject > to continuing evaluation and modification, and in particular may be > extended by use of the "comments on media types" mechanism described > in subsequent sections. > and > 2.4. Comments on Media Type Registrations > Comments on registered media types may be submitted by members of the > community to IANA. These comments will be passed on to the "owner" > of the media type if possible. Submitters of comments may request > that their comment be attached to the media type registration itself, > and if IANA approves of this the comment will be made accessible in > conjunction with the type registration itself. > RFC 2048 was issued nearly eight years ago, so I wonder if the procedure > listed there is still considered appropriate. In particular, I have several > questions that members of this list might be qualified to answer: > 1. Has this mechanism ever been used? [I have scanned several dozen > media registrations, but could find no example of anything that > looks like commentary attached to the media type registration] AFAIK nobody has ever used the commentary mechanism. Media type registrations have been revised on several occasions, however, without incident or undue fuss. > 2. Media types can be registered via a textual form alone, or in an RFC. > It seems unlikely that IANA can attach comments to an RFC, as RFCs > are supposed to remain unchanged once published. There is a > somewhat obscure errata page, but that's managed by the RFC > Editor, not IANA. I therefore believe that the RFC 2048 procedure > as written is not entirely adequate. Comments? I disagree. The process for revising an RFC is to issue a revised RFC. I see no reason to create yet another process to put this information elsewhere. > 3. Does IANA itself currently have the expertise to evaluate accuracy > and applicability of submitted comments? If not, who will IANA > turn to for advice, and would it be prudent/advisable/acceptable > for "submitters of comments" to copy them (assuming that > submission of comments to IANA is still considered the applicable > procedure)? The IANA has the good sense to appoint expert reviewers as needed. There are literally dozens of examples of this "running code". > 4. The RFC 2048 text mentions that comments will be forwarded to the > media type "owner", and mentions IANA approval of comments. > What procedures exist for conflict resolution? Conflict resolution mechanism are practically impossible to define and get right in the absencce of experience with actual conflict. And since this particular mechanism hasn't even been used once in the past 8 years I view it as highly inappropriate to specify such a mechanism at this time. > For example, suppose > that the submitter of a textual registration which claimed "no > known security issues" believes in security through obscurity (or > is constrained by such a corporate employer's policy) and objects > to having security comments attached to the registration (assume > that substantial third-party corroboration of real security issues > is provided with the comments); does the type "owner" have > final say in the matter, does IANA have the authority to override > such non-substantive objections, is there provision for IETF AD or > IESG review if necessary, etc.? The IANA gets to decide, and if necessary the decision could be appealed using the normal appeals process. Again, there's no need to create additional process and formalism. Ned >From blilly@erols.com Wed Oct 20 16:43:02 2004 From: blilly at erols.com (Bruce Lilly) Date: Wed Oct 20 16:43:10 2004 Subject: Post-facto reporting of media type security considerations In-Reply-To: <6.0.0.20.2.20041019120002.05e47b00@localhost> References: <200410181008.03466.blilly@erols.com> <6.0.0.20.2.20041019120002.05e47b00@localhost> Message-ID: <200410201043.03377.blilly@erols.com> On Mon October 18 2004 23:17, Martin Duerst wrote: > The new registration procedure for mime types is at > http://www.ietf.org/internet-drafts/draft-freed-media-type-reg-01.txt. Thanks, Martin; I'll take a look at it. > P.S.: It seems that our setting of the 'Reply-To' header has > prompted the IANA anti-spam system to send its message to > the list rather than to you only. Any way, on either your > or IANAs side, to avoid that? Setting Reply-To to point to the list expander mailbox (in accordance with RFC 822 section 4.4.2) enables responses to the list w/o requiring respondents to use a reply-to-all function which would have the effect of sending copies of responses to IANA (setting Reply-To doesn't prevent anybody from sending copies anywhere though). It appears that IANA sends its automated confirmation notices to the mailbox list in the Reply-To field rather than to the sender envelope address as recommended by RFC 3834 (section 4). It would be nice if IANA would update its automatic responder to comply with the RFC 3834 recommendations. [I'll remail a separate copy of this to IANA] >From blilly@erols.com Thu Oct 21 02:24:45 2004 From: blilly at erols.com (Bruce Lilly) Date: Thu Oct 21 02:26:23 2004 Subject: Post-facto reporting of media type security considerations In-Reply-To: <01LG8A2JGHCW00005R@mauve.mrochek.com> References: <200410181008.03466.blilly@erols.com> <01LG8A2JGHCW00005R@mauve.mrochek.com> Message-ID: <200410202024.45343.blilly@erols.com> On Wed October 20 2004 00:02, ned.freed@mrochek.com wrote: > > 2. Media types can be registered via a textual form alone, or in an RFC. > > It seems unlikely that IANA can attach comments to an RFC, as RFCs > > are supposed to remain unchanged once published. There is a > > somewhat obscure errata page, but that's managed by the RFC > > Editor, not IANA. I therefore believe that the RFC 2048 procedure > > as written is not entirely adequate. Comments? > > I disagree. The process for revising an RFC is to issue a revised RFC. I see no > reason to create yet another process to put this information elsewhere. I'm not suggesting putting the information elsewhere; merely that IANA may lack the ability to issue a revised RFC (e.g. if the author is unable or unwilling to make a revision). >From duerst@w3.org Thu Oct 21 04:25:52 2004 From: duerst at w3.org (Martin Duerst) Date: Thu Oct 21 05:09:30 2004 Subject: Post-facto reporting of media type security considerations In-Reply-To: <200410202024.45343.blilly@erols.com> References: <200410181008.03466.blilly@erols.com> <01LG8A2JGHCW00005R@mauve.mrochek.com> <200410202024.45343.blilly@erols.com> Message-ID: <6.0.0.20.2.20041021112404.063983e0@localhost> At 09:24 04/10/21, Bruce Lilly wrote: >I'm not suggesting putting the information elsewhere; merely that >IANA may lack the ability to issue a revised RFC (e.g. if the author >is unable or unwilling to make a revision). It wouldn't necessarily have to be the original author who would put out a revised RFC. If it were seen really necessary, somebody else could do it. Of course, it wouldn't be IANA but a tird-party volunteer, so in some sense, you are still right. Regards, Martin. From: ned.freed at mrochek.com (ned.freed@mrochek.com) Date: Tue Jan 3 16:22:50 2006 Subject: Post-facto reporting of media type security considerations In-Reply-To: "Your message dated Mon, 18 Oct 2004 10:08:02 -0400" <200410181008.03466.blilly@erols.com> References: <200410181008.03466.blilly@erols.com> Message-ID: <01LG8A2JGHCW00005R@mauve.mrochek.com> > [This message has been sent to the ietf-types mailing list with a courtesy > copy to IANA (as IANA issues are raised); I have suggested responses > be directed to the ietf-types list] > There are some media types for which security issues have become known > since the original type registrations. RFC 2048 has a provision for reporting > such issues: > 2.2.6. Security Requirements > [...] > The security considerations section of all registrations is subject > to continuing evaluation and modification, and in particular may be > extended by use of the "comments on media types" mechanism described > in subsequent sections. > and > 2.4. Comments on Media Type Registrations > Comments on registered media types may be submitted by members of the > community to IANA. These comments will be passed on to the "owner" > of the media type if possible. Submitters of comments may request > that their comment be attached to the media type registration itself, > and if IANA approves of this the comment will be made accessible in > conjunction with the type registration itself. > RFC 2048 was issued nearly eight years ago, so I wonder if the procedure > listed there is still considered appropriate. In particular, I have several > questions that members of this list might be qualified to answer: > 1. Has this mechanism ever been used? [I have scanned several dozen > media registrations, but could find no example of anything that > looks like commentary attached to the media type registration] AFAIK nobody has ever used the commentary mechanism. Media type registrations have been revised on several occasions, however, without incident or undue fuss. > 2. Media types can be registered via a textual form alone, or in an RFC. > It seems unlikely that IANA can attach comments to an RFC, as RFCs > are supposed to remain unchanged once published. There is a > somewhat obscure errata page, but that's managed by the RFC > Editor, not IANA. I therefore believe that the RFC 2048 procedure > as written is not entirely adequate. Comments? I disagree. The process for revising an RFC is to issue a revised RFC. I see no reason to create yet another process to put this information elsewhere. > 3. Does IANA itself currently have the expertise to evaluate accuracy > and applicability of submitted comments? If not, who will IANA > turn to for advice, and would it be prudent/advisable/acceptable > for "submitters of comments" to copy them (assuming that > submission of comments to IANA is still considered the applicable > procedure)? The IANA has the good sense to appoint expert reviewers as needed. There are literally dozens of examples of this "running code". > 4. The RFC 2048 text mentions that comments will be forwarded to the > media type "owner", and mentions IANA approval of comments. > What procedures exist for conflict resolution? Conflict resolution mechanism are practically impossible to define and get right in the absencce of experience with actual conflict. And since this particular mechanism hasn't even been used once in the past 8 years I view it as highly inappropriate to specify such a mechanism at this time. > For example, suppose > that the submitter of a textual registration which claimed "no > known security issues" believes in security through obscurity (or > is constrained by such a corporate employer's policy) and objects > to having security comments attached to the registration (assume > that substantial third-party corroboration of real security issues > is provided with the comments); does the type "owner" have > final say in the matter, does IANA have the authority to override > such non-substantive objections, is there provision for IETF AD or > IESG review if necessary, etc.? The IANA gets to decide, and if necessary the decision could be appealed using the normal appeals process. Again, there's no need to create additional process and formalism. Ned From: duerst at w3.org (Martin Duerst) Date: Tue Oct 19 05:32:51 2004 Subject: Post-facto reporting of media type security considerations In-Reply-To: <200410181008.03466.blilly@erols.com> References: <200410181008.03466.blilly@erols.com> Message-ID: <6.0.0.20.2.20041019120002.05e47b00@localhost> The new registration procedure for mime types is at http://www.ietf.org/internet-drafts/draft-freed-media-type-reg-01.txt. That doesn't seem to do away with the "Comments on Media Type Registrations". I agree that this section has some problems. The new registration process also allows registrations directly from standards bodies outside the IETF (with IESG approval). While for example the W3C has a better working system for dealing with errata (there is a link to an errata page from each W3C Recommendation, and there is even a direct link for the TR page (http://www.w3.org/TR/#Recommendations)), that may be different for other standards organizations. Also, there is not necessarily a guarantee that a request from IANA for an erratum would be honored, or that the IANA would know how to go about notifying the right place if they received a comment. Regards, Martin. P.S.: It seems that our setting of the 'Reply-To' header has prompted the IANA anti-spam system to send its message to the list rather than to you only. Any way, on either your or IANAs side, to avoid that? At 23:08 04/10/18, Bruce Lilly wrote: >[This message has been sent to the ietf-types mailing list with a courtesy >copy to IANA (as IANA issues are raised); I have suggested responses >be directed to the ietf-types list] > >There are some media types for which security issues have become known >since the original type registrations. RFC 2048 has a provision for reporting >such issues: > >2.2.6. Security Requirements >[...] > The security considerations section of all registrations is subject > to continuing evaluation and modification, and in particular may be > extended by use of the "comments on media types" mechanism described > in subsequent sections. > >and > >2.4. Comments on Media Type Registrations > > Comments on registered media types may be submitted by members of the > community to IANA. These comments will be passed on to the "owner" > of the media type if possible. Submitters of comments may request > that their comment be attached to the media type registration itself, > and if IANA approves of this the comment will be made accessible in > conjunction with the type registration itself. > >RFC 2048 was issued nearly eight years ago, so I wonder if the procedure >listed there is still considered appropriate. In particular, I have several >questions that members of this list might be qualified to answer: > >1. Has this mechanism ever been used? [I have scanned several dozen > media registrations, but could find no example of anything that > looks like commentary attached to the media type registration] > >2. Media types can be registered via a textual form alone, or in an RFC. > It seems unlikely that IANA can attach comments to an RFC, as RFCs > are supposed to remain unchanged once published. There is a > somewhat obscure errata page, but that's managed by the RFC > Editor, not IANA. I therefore believe that the RFC 2048 procedure > as written is not entirely adequate. Comments? > >3. Does IANA itself currently have the expertise to evaluate accuracy > and applicability of submitted comments? If not, who will IANA > turn to for advice, and would it be prudent/advisable/acceptable > for "submitters of comments" to copy them (assuming that > submission of comments to IANA is still considered the applicable > procedure)? > >4. The RFC 2048 text mentions that comments will be forwarded to the > media type "owner", and mentions IANA approval of comments. > What procedures exist for conflict resolution? For example, suppose > that the submitter of a textual registration which claimed "no > known security issues" believes in security through obscurity (or > is constrained by such a corporate employer's policy) and objects > to having security comments attached to the registration (assume > that substantial third-party corroboration of real security issues > is provided with the comments); does the type "owner" have > final say in the matter, does IANA have the authority to override > such non-substantive objections, is there provision for IETF AD or > IESG review if necessary, etc.? From: duerst at w3.org (Martin Duerst) Date: Tue Jan 3 16:22:50 2006 Subject: Post-facto reporting of media type security considerations In-Reply-To: <200410181008.03466.blilly@erols.com> References: <200410181008.03466.blilly@erols.com> Message-ID: <6.0.0.20.2.20041019120002.05e47b00@localhost> The new registration procedure for mime types is at http://www.ietf.org/internet-drafts/draft-freed-media-type-reg-01.txt. That doesn't seem to do away with the "Comments on Media Type Registrations". I agree that this section has some problems. The new registration process also allows registrations directly from standards bodies outside the IETF (with IESG approval). While for example the W3C has a better working system for dealing with errata (there is a link to an errata page from each W3C Recommendation, and there is even a direct link for the TR page (http://www.w3.org/TR/#Recommendations)), that may be different for other standards organizations. Also, there is not necessarily a guarantee that a request from IANA for an erratum would be honored, or that the IANA would know how to go about notifying the right place if they received a comment. Regards, Martin. P.S.: It seems that our setting of the 'Reply-To' header has prompted the IANA anti-spam system to send its message to the list rather than to you only. Any way, on either your or IANAs side, to avoid that? At 23:08 04/10/18, Bruce Lilly wrote: >[This message has been sent to the ietf-types mailing list with a courtesy >copy to IANA (as IANA issues are raised); I have suggested responses >be directed to the ietf-types list] > >There are some media types for which security issues have become known >since the original type registrations. RFC 2048 has a provision for reporting >such issues: > >2.2.6. Security Requirements >[...] > The security considerations section of all registrations is subject > to continuing evaluation and modification, and in particular may be > extended by use of the "comments on media types" mechanism described > in subsequent sections. > >and > >2.4. Comments on Media Type Registrations > > Comments on registered media types may be submitted by members of the > community to IANA. These comments will be passed on to the "owner" > of the media type if possible. Submitters of comments may request > that their comment be attached to the media type registration itself, > and if IANA approves of this the comment will be made accessible in > conjunction with the type registration itself. > >RFC 2048 was issued nearly eight years ago, so I wonder if the procedure >listed there is still considered appropriate. In particular, I have several >questions that members of this list might be qualified to answer: > >1. Has this mechanism ever been used? [I have scanned several dozen > media registrations, but could find no example of anything that > looks like commentary attached to the media type registration] > >2. Media types can be registered via a textual form alone, or in an RFC. > It seems unlikely that IANA can attach comments to an RFC, as RFCs > are supposed to remain unchanged once published. There is a > somewhat obscure errata page, but that's managed by the RFC > Editor, not IANA. I therefore believe that the RFC 2048 procedure > as written is not entirely adequate. Comments? > >3. Does IANA itself currently have the expertise to evaluate accuracy > and applicability of submitted comments? If not, who will IANA > turn to for advice, and would it be prudent/advisable/acceptable > for "submitters of comments" to copy them (assuming that > submission of comments to IANA is still considered the applicable > procedure)? > >4. The RFC 2048 text mentions that comments will be forwarded to the > media type "owner", and mentions IANA approval of comments. > What procedures exist for conflict resolution? For example, suppose > that the submitter of a textual registration which claimed "no > known security issues" believes in security through obscurity (or > is constrained by such a corporate employer's policy) and objects > to having security comments attached to the registration (assume > that substantial third-party corroboration of real security issues > is provided with the comments); does the type "owner" have > final say in the matter, does IANA have the authority to override > such non-substantive objections, is there provision for IETF AD or > IESG review if necessary, etc.? From: iana at iana.org (iana@iana.org) Date: Mon Oct 18 17:59:27 2004 Subject: ConfirmSystem: iana@icann.org [[a92b5906721e8790]] Message-ID: <200410181459.i9IExXs13442@santee.icann.org> Thank you for your message. The iana@iana.org address collects a tremendous amount of spam, and we have been forced to implement protective measures. In order to process your message we need to confirm that it came from a real email address. To confirm your message, you can either: 1) Reply to this message, without altering the subject line The "Re: " added by many mail clients is OK, but please note that this method is *not* foolproof. or 2) Visit the URL If you want to be very sure that your message gets through, do both steps above -- it does no harm to confirm more than once. For your reference, the subject of the message you sent was: "Post-facto reporting of media type security considerations" and it arrived at IANA approximately at Mon Oct 18 07:59:33 2004. --------------------------------------------------------------- ConfirmSystem: iana@icann.org [[a92b5906721e8790]] 1 From: iana at iana.org (iana@iana.org) Date: Tue Jan 3 16:22:50 2006 Subject: ConfirmSystem: iana@icann.org [[a92b5906721e8790]] Message-ID: <200410181459.i9IExXs13442@santee.icann.org> Thank you for your message. The iana@iana.org address collects a tremendous amount of spam, and we have been forced to implement protective measures. In order to process your message we need to confirm that it came from a real email address. To confirm your message, you can either: 1) Reply to this message, without altering the subject line The "Re: " added by many mail clients is OK, but please note that this method is *not* foolproof. or 2) Visit the URL If you want to be very sure that your message gets through, do both steps above -- it does no harm to confirm more than once. For your reference, the subject of the message you sent was: "Post-facto reporting of media type security considerations" and it arrived at IANA approximately at Mon Oct 18 07:59:33 2004. --------------------------------------------------------------- ConfirmSystem: iana@icann.org [[a92b5906721e8790]] 1 From: blilly at erols.com (Bruce Lilly) Date: Mon Oct 18 16:59:39 2004 Subject: Post-facto reporting of media type security considerations Message-ID: <200410181008.03466.blilly@erols.com> [This message has been sent to the ietf-types mailing list with a courtesy copy to IANA (as IANA issues are raised); I have suggested responses be directed to the ietf-types list] There are some media types for which security issues have become known since the original type registrations. RFC 2048 has a provision for reporting such issues: 2.2.6. Security Requirements [...] The security considerations section of all registrations is subject to continuing evaluation and modification, and in particular may be extended by use of the "comments on media types" mechanism described in subsequent sections. and 2.4. Comments on Media Type Registrations Comments on registered media types may be submitted by members of the community to IANA. These comments will be passed on to the "owner" of the media type if possible. Submitters of comments may request that their comment be attached to the media type registration itself, and if IANA approves of this the comment will be made accessible in conjunction with the type registration itself. RFC 2048 was issued nearly eight years ago, so I wonder if the procedure listed there is still considered appropriate. In particular, I have several questions that members of this list might be qualified to answer: 1. Has this mechanism ever been used? [I have scanned several dozen media registrations, but could find no example of anything that looks like commentary attached to the media type registration] 2. Media types can be registered via a textual form alone, or in an RFC. It seems unlikely that IANA can attach comments to an RFC, as RFCs are supposed to remain unchanged once published. There is a somewhat obscure errata page, but that's managed by the RFC Editor, not IANA. I therefore believe that the RFC 2048 procedure as written is not entirely adequate. Comments? 3. Does IANA itself currently have the expertise to evaluate accuracy and applicability of submitted comments? If not, who will IANA turn to for advice, and would it be prudent/advisable/acceptable for "submitters of comments" to copy them (assuming that submission of comments to IANA is still considered the applicable procedure)? 4. The RFC 2048 text mentions that comments will be forwarded to the media type "owner", and mentions IANA approval of comments. What procedures exist for conflict resolution? For example, suppose that the submitter of a textual registration which claimed "no known security issues" believes in security through obscurity (or is constrained by such a corporate employer's policy) and objects to having security comments attached to the registration (assume that substantial third-party corroboration of real security issues is provided with the comments); does the type "owner" have final say in the matter, does IANA have the authority to override such non-substantive objections, is there provision for IETF AD or IESG review if necessary, etc.? From: blilly at erols.com (Bruce Lilly) Date: Tue Jan 3 16:22:50 2006 Subject: Post-facto reporting of media type security considerations Message-ID: <200410181008.03466.blilly@erols.com> [This message has been sent to the ietf-types mailing list with a courtesy copy to IANA (as IANA issues are raised); I have suggested responses be directed to the ietf-types list] There are some media types for which security issues have become known since the original type registrations. RFC 2048 has a provision for reporting such issues: 2.2.6. Security Requirements [...] The security considerations section of all registrations is subject to continuing evaluation and modification, and in particular may be extended by use of the "comments on media types" mechanism described in subsequent sections. and 2.4. Comments on Media Type Registrations Comments on registered media types may be submitted by members of the community to IANA. These comments will be passed on to the "owner" of the media type if possible. Submitters of comments may request that their comment be attached to the media type registration itself, and if IANA approves of this the comment will be made accessible in conjunction with the type registration itself. RFC 2048 was issued nearly eight years ago, so I wonder if the procedure listed there is still considered appropriate. In particular, I have several questions that members of this list might be qualified to answer: 1. Has this mechanism ever been used? [I have scanned several dozen media registrations, but could find no example of anything that looks like commentary attached to the media type registration] 2. Media types can be registered via a textual form alone, or in an RFC. It seems unlikely that IANA can attach comments to an RFC, as RFCs are supposed to remain unchanged once published. There is a somewhat obscure errata page, but that's managed by the RFC Editor, not IANA. I therefore believe that the RFC 2048 procedure as written is not entirely adequate. Comments? 3. Does IANA itself currently have the expertise to evaluate accuracy and applicability of submitted comments? If not, who will IANA turn to for advice, and would it be prudent/advisable/acceptable for "submitters of comments" to copy them (assuming that submission of comments to IANA is still considered the applicable procedure)? 4. The RFC 2048 text mentions that comments will be forwarded to the media type "owner", and mentions IANA approval of comments. What procedures exist for conflict resolution? For example, suppose that the submitter of a textual registration which claimed "no known security issues" believes in security through obscurity (or is constrained by such a corporate employer's policy) and objects to having security comments attached to the registration (assume that substantial third-party corroboration of real security issues is provided with the comments); does the type "owner" have final say in the matter, does IANA have the authority to override such non-substantive objections, is there provision for IETF AD or IESG review if necessary, etc.? From: csp at csperkins.org (Colin Perkins) Date: Tue Jan 3 16:22:50 2006 Subject: Registration of media type text/3gpp-tt In-Reply-To: <01LFU3U1D1EI00005R@mauve.mrochek.com> References: <9D277E44D6EF0942B928C6F0DE99BB313308E1@lan-ex-01.panasonic.de> <01LFTN0HK2Z200005Q@mauve.mrochek.com> <3C8315D0-1A1B-11D9-8A20-000A957FC5F2@csperkins.org> <01LFU3U1D1EI00005R@mauve.mrochek.com> Message-ID: On 10 Oct 2004, at 01:38, ned.freed@mrochek.com wrote: >> On 9 Oct 2004, at 17:27, ned.freed@mrochek.com wrote: >> ... >> > It isn't clear to me that this actually refers to the ietf-types >> list, >> > but perhaps that was stated in some other message. In any case, an >> > process that relies on someone on the ietf-types list saying >> something >> > is inherently broken and needs to be fixed. > >> My original message to the AVT mailing list said: > >> In future, as new RTP payload formats are developed, we will require >> expert review of the media type registration as part of the working >> group last call process. Please contact the chairs for guidance on >> the >> procedure for this review, when you believe your draft is ready for >> working group last call. We will not forward drafts to the IESG for >> publication unless they have received such review. >> [http://www1.ietf.org/mail-archive/web/avt/current/msg04287.html] > >> Several weeks later, when Jose asked for guidance on how the review >> should be conducted, and if it should occur before or in parallel with >> the working group last call, I respond: > >> Before the working group last call. You should send a note to the >> mailing list (which was cc'd on much of the >> previous discussion) asking for review of the MIME registration, to >> ensure there are no objections. >> [http://www1.ietf.org/mail-archive/web/avt/current/msg04520.html] > >> This is consistent with section 5.1 of >> draft-freed-media-type-reg-01.txt, which states that the list is >> appropriate for initial community review of media types: > >> In all cases notice of a potential media type registration MAY be >> sent to the "ietf-types@iana.org" mailing list for review. This >> mailing list has been established for the purpose of reviewing >> proposed media and access types. > >> The intent of the public posting is to solicit comments and >> feedback >> on the choice of type/subtype name, the unambiguity of the >> references >> with respect to versions and external profiling information, and a >> review of any interoperability or security considerations. The >> submitter may submit a revised registration, or abandon the >> registration completely, at any time. > >> We place no greater requirement or obligation on this list than does >> your document, and as I said in my reply to Jose (and this list) >> yesterday "If no comments result after a reasonable time period, so be >> it". > > Again, that's fine as long as it is understood that nobody is > obliged to comment. The entire point of my message was to explain what has been said in AVT and to clarify that -- as should be obvious to anyone who attends IETF meetings -- nobody is obliged to comment. Colin From: ned.freed at mrochek.com (ned.freed@mrochek.com) Date: Sun Oct 10 02:40:00 2004 Subject: Registration of media type text/3gpp-tt In-Reply-To: "Your message dated Sat, 09 Oct 2004 18:47:06 +0100" <3C8315D0-1A1B-11D9-8A20-000A957FC5F2@csperkins.org> References: <9D277E44D6EF0942B928C6F0DE99BB313308E1@lan-ex-01.panasonic.de> <01LFTN0HK2Z200005Q@mauve.mrochek.com> <3C8315D0-1A1B-11D9-8A20-000A957FC5F2@csperkins.org> Message-ID: <01LFU3U1D1EI00005R@mauve.mrochek.com> > On 9 Oct 2004, at 17:27, ned.freed@mrochek.com wrote: > ... > > It isn't clear to me that this actually refers to the ietf-types list, > > but perhaps that was stated in some other message. In any case, an > > process that relies on someone on the ietf-types list saying something > > is inherently broken and needs to be fixed. > My original message to the AVT mailing list said: > In future, as new RTP payload formats are developed, we will require > expert review of the media type registration as part of the working > group last call process. Please contact the chairs for guidance on the > procedure for this review, when you believe your draft is ready for > working group last call. We will not forward drafts to the IESG for > publication unless they have received such review. > [http://www1.ietf.org/mail-archive/web/avt/current/msg04287.html] > Several weeks later, when Jose asked for guidance on how the review > should be conducted, and if it should occur before or in parallel with > the working group last call, I respond: > Before the working group last call. You should send a note to the > mailing list (which was cc'd on much of the > previous discussion) asking for review of the MIME registration, to > ensure there are no objections. > [http://www1.ietf.org/mail-archive/web/avt/current/msg04520.html] > This is consistent with section 5.1 of > draft-freed-media-type-reg-01.txt, which states that the list is > appropriate for initial community review of media types: > In all cases notice of a potential media type registration MAY be > sent to the "ietf-types@iana.org" mailing list for review. This > mailing list has been established for the purpose of reviewing > proposed media and access types. > The intent of the public posting is to solicit comments and feedback > on the choice of type/subtype name, the unambiguity of the references > with respect to versions and external profiling information, and a > review of any interoperability or security considerations. The > submitter may submit a revised registration, or abandon the > registration completely, at any time. > We place no greater requirement or obligation on this list than does > your document, and as I said in my reply to Jose (and this list) > yesterday "If no comments result after a reasonable time period, so be > it". Again, that's fine as long as it is understood that nobody is obliged to comment. Ned >From csp@csperkins.org Sun Oct 10 11:01:04 2004 From: csp at csperkins.org (Colin Perkins) Date: Sun Oct 10 11:01:23 2004 Subject: Registration of media type text/3gpp-tt In-Reply-To: <01LFU3U1D1EI00005R@mauve.mrochek.com> References: <9D277E44D6EF0942B928C6F0DE99BB313308E1@lan-ex-01.panasonic.de> <01LFTN0HK2Z200005Q@mauve.mrochek.com> <3C8315D0-1A1B-11D9-8A20-000A957FC5F2@csperkins.org> <01LFU3U1D1EI00005R@mauve.mrochek.com> Message-ID: On 10 Oct 2004, at 01:38, ned.freed@mrochek.com wrote: >> On 9 Oct 2004, at 17:27, ned.freed@mrochek.com wrote: >> ... >> > It isn't clear to me that this actually refers to the ietf-types >> list, >> > but perhaps that was stated in some other message. In any case, an >> > process that relies on someone on the ietf-types list saying >> something >> > is inherently broken and needs to be fixed. > >> My original message to the AVT mailing list said: > >> In future, as new RTP payload formats are developed, we will require >> expert review of the media type registration as part of the working >> group last call process. Please contact the chairs for guidance on >> the >> procedure for this review, when you believe your draft is ready for >> working group last call. We will not forward drafts to the IESG for >> publication unless they have received such review. >> [http://www1.ietf.org/mail-archive/web/avt/current/msg04287.html] > >> Several weeks later, when Jose asked for guidance on how the review >> should be conducted, and if it should occur before or in parallel with >> the working group last call, I respond: > >> Before the working group last call. You should send a note to the >> mailing list (which was cc'd on much of the >> previous discussion) asking for review of the MIME registration, to >> ensure there are no objections. >> [http://www1.ietf.org/mail-archive/web/avt/current/msg04520.html] > >> This is consistent with section 5.1 of >> draft-freed-media-type-reg-01.txt, which states that the list is >> appropriate for initial community review of media types: > >> In all cases notice of a potential media type registration MAY be >> sent to the "ietf-types@iana.org" mailing list for review. This >> mailing list has been established for the purpose of reviewing >> proposed media and access types. > >> The intent of the public posting is to solicit comments and >> feedback >> on the choice of type/subtype name, the unambiguity of the >> references >> with respect to versions and external profiling information, and a >> review of any interoperability or security considerations. The >> submitter may submit a revised registration, or abandon the >> registration completely, at any time. > >> We place no greater requirement or obligation on this list than does >> your document, and as I said in my reply to Jose (and this list) >> yesterday "If no comments result after a reasonable time period, so be >> it". > > Again, that's fine as long as it is understood that nobody is > obliged to comment. The entire point of my message was to explain what has been said in AVT and to clarify that -- as should be obvious to anyone who attends IETF meetings -- nobody is obliged to comment. Colin From: ned.freed at mrochek.com (ned.freed@mrochek.com) Date: Tue Jan 3 16:22:50 2006 Subject: Registration of media type text/3gpp-tt In-Reply-To: "Your message dated Sat, 09 Oct 2004 18:47:06 +0100" <3C8315D0-1A1B-11D9-8A20-000A957FC5F2@csperkins.org> References: <9D277E44D6EF0942B928C6F0DE99BB313308E1@lan-ex-01.panasonic.de> <01LFTN0HK2Z200005Q@mauve.mrochek.com> <3C8315D0-1A1B-11D9-8A20-000A957FC5F2@csperkins.org> Message-ID: <01LFU3U1D1EI00005R@mauve.mrochek.com> > On 9 Oct 2004, at 17:27, ned.freed@mrochek.com wrote: > ... > > It isn't clear to me that this actually refers to the ietf-types list, > > but perhaps that was stated in some other message. In any case, an > > process that relies on someone on the ietf-types list saying something > > is inherently broken and needs to be fixed. > My original message to the AVT mailing list said: > In future, as new RTP payload formats are developed, we will require > expert review of the media type registration as part of the working > group last call process. Please contact the chairs for guidance on the > procedure for this review, when you believe your draft is ready for > working group last call. We will not forward drafts to the IESG for > publication unless they have received such review. > [http://www1.ietf.org/mail-archive/web/avt/current/msg04287.html] > Several weeks later, when Jose asked for guidance on how the review > should be conducted, and if it should occur before or in parallel with > the working group last call, I respond: > Before the working group last call. You should send a note to the > mailing list (which was cc'd on much of the > previous discussion) asking for review of the MIME registration, to > ensure there are no objections. > [http://www1.ietf.org/mail-archive/web/avt/current/msg04520.html] > This is consistent with section 5.1 of > draft-freed-media-type-reg-01.txt, which states that the list is > appropriate for initial community review of media types: > In all cases notice of a potential media type registration MAY be > sent to the "ietf-types@iana.org" mailing list for review. This > mailing list has been established for the purpose of reviewing > proposed media and access types. > The intent of the public posting is to solicit comments and feedback > on the choice of type/subtype name, the unambiguity of the references > with respect to versions and external profiling information, and a > review of any interoperability or security considerations. The > submitter may submit a revised registration, or abandon the > registration completely, at any time. > We place no greater requirement or obligation on this list than does > your document, and as I said in my reply to Jose (and this list) > yesterday "If no comments result after a reasonable time period, so be > it". Again, that's fine as long as it is understood that nobody is obliged to comment. Ned From: csp at csperkins.org (Colin Perkins) Date: Tue Jan 3 16:22:50 2006 Subject: Registration of media type text/3gpp-tt In-Reply-To: <01LFTN0HK2Z200005Q@mauve.mrochek.com> References: <9D277E44D6EF0942B928C6F0DE99BB313308E1@lan-ex-01.panasonic.de> <01LFTN0HK2Z200005Q@mauve.mrochek.com> Message-ID: <3C8315D0-1A1B-11D9-8A20-000A957FC5F2@csperkins.org> On 9 Oct 2004, at 17:27, ned.freed@mrochek.com wrote: ... > It isn't clear to me that this actually refers to the ietf-types list, > but perhaps that was stated in some other message. In any case, an > process that relies on someone on the ietf-types list saying something > is inherently broken and needs to be fixed. My original message to the AVT mailing list said: In future, as new RTP payload formats are developed, we will require expert review of the media type registration as part of the working group last call process. Please contact the chairs for guidance on the procedure for this review, when you believe your draft is ready for working group last call. We will not forward drafts to the IESG for publication unless they have received such review. [http://www1.ietf.org/mail-archive/web/avt/current/msg04287.html] Several weeks later, when Jose asked for guidance on how the review should be conducted, and if it should occur before or in parallel with the working group last call, I respond: Before the working group last call. You should send a note to the mailing list (which was cc'd on much of the previous discussion) asking for review of the MIME registration, to ensure there are no objections. [http://www1.ietf.org/mail-archive/web/avt/current/msg04520.html] This is consistent with section 5.1 of draft-freed-media-type-reg-01.txt, which states that the list is appropriate for initial community review of media types: In all cases notice of a potential media type registration MAY be sent to the "ietf-types@iana.org" mailing list for review. This mailing list has been established for the purpose of reviewing proposed media and access types. The intent of the public posting is to solicit comments and feedback on the choice of type/subtype name, the unambiguity of the references with respect to versions and external profiling information, and a review of any interoperability or security considerations. The submitter may submit a revised registration, or abandon the registration completely, at any time. We place no greater requirement or obligation on this list than does your document, and as I said in my reply to Jose (and this list) yesterday "If no comments result after a reasonable time period, so be it". Colin From: ned.freed at mrochek.com (ned.freed@mrochek.com) Date: Sat Oct 9 18:38:01 2004 Subject: Registration of media type text/3gpp-tt In-Reply-To: "Your message dated Fri, 08 Oct 2004 11:44:26 +0200" <9D277E44D6EF0942B928C6F0DE99BB313308E1@lan-ex-01.panasonic.de> References: <9D277E44D6EF0942B928C6F0DE99BB313308E1@lan-ex-01.panasonic.de> Message-ID: <01LFTN0HK2Z200005Q@mauve.mrochek.com> > > > It is more than 2 weeks since I sent this in for consideration. Could > > > you please inform me about the status? I would like to proceed ASAP > > > with WGLC in AVT but cannot without passing this review. > > The ietf-types list is for informal media type reviews only. > > It is not where types are "considered" or "approved". > > Somtimes people comment on registrations, other times they don't. > Yes, you are right, "review" is the correct term. > However, reading the attached email from Colin, I understand that this review > is 'required' for WGLC. I'm reminded of an exchange from, I believe, Farmer's _The Riders of the Purple Wage_: Man to God: Sir, I exist! God to Man: Quite true, but that creates in me no sense of obligation. Having a requirement that some other group review something before it can be passed only makes sense if that other group is in some way obliged to actually do a review. No such obligation exists in this case, and past experience has been that such arrangement work badly or not at all in the IETF. This means that either (a) The absence of any comments needs to be construed as something akin to a neutral revew or (b) The requirement is specious and needs to be replaced or abandoned. > This means that whether this review is "no comments" or there are in fact > comments, I (we) have to know in order to progress the document. Specially > this part (original attached): > "In future, as new RTP payload formats are developed, we will require expert > review of the media type registration as part of the working group last call > process. Please contact the chairs for guidance on the procedure for this > review, when you believe your draft is ready for working group last call. We > will not forward drafts to the IESG for publication **unless they have received > such review.**" It isn't clear to me that this actually refers to the ietf-types list, but perhaps that was stated in some other message. In any case, an process that relies on someone on the ietf-types list saying something is inherently broken and needs to be fixed. Ned >From csp@csperkins.org Sat Oct 9 19:47:06 2004 From: csp at csperkins.org (Colin Perkins) Date: Sat Oct 9 19:47:24 2004 Subject: Registration of media type text/3gpp-tt In-Reply-To: <01LFTN0HK2Z200005Q@mauve.mrochek.com> References: <9D277E44D6EF0942B928C6F0DE99BB313308E1@lan-ex-01.panasonic.de> <01LFTN0HK2Z200005Q@mauve.mrochek.com> Message-ID: <3C8315D0-1A1B-11D9-8A20-000A957FC5F2@csperkins.org> On 9 Oct 2004, at 17:27, ned.freed@mrochek.com wrote: ... > It isn't clear to me that this actually refers to the ietf-types list, > but perhaps that was stated in some other message. In any case, an > process that relies on someone on the ietf-types list saying something > is inherently broken and needs to be fixed. My original message to the AVT mailing list said: In future, as new RTP payload formats are developed, we will require expert review of the media type registration as part of the working group last call process. Please contact the chairs for guidance on the procedure for this review, when you believe your draft is ready for working group last call. We will not forward drafts to the IESG for publication unless they have received such review. [http://www1.ietf.org/mail-archive/web/avt/current/msg04287.html] Several weeks later, when Jose asked for guidance on how the review should be conducted, and if it should occur before or in parallel with the working group last call, I respond: Before the working group last call. You should send a note to the mailing list (which was cc'd on much of the previous discussion) asking for review of the MIME registration, to ensure there are no objections. [http://www1.ietf.org/mail-archive/web/avt/current/msg04520.html] This is consistent with section 5.1 of draft-freed-media-type-reg-01.txt, which states that the list is appropriate for initial community review of media types: In all cases notice of a potential media type registration MAY be sent to the "ietf-types@iana.org" mailing list for review. This mailing list has been established for the purpose of reviewing proposed media and access types. The intent of the public posting is to solicit comments and feedback on the choice of type/subtype name, the unambiguity of the references with respect to versions and external profiling information, and a review of any interoperability or security considerations. The submitter may submit a revised registration, or abandon the registration completely, at any time. We place no greater requirement or obligation on this list than does your document, and as I said in my reply to Jose (and this list) yesterday "If no comments result after a reasonable time period, so be it". Colin From: ned.freed at mrochek.com (ned.freed@mrochek.com) Date: Tue Jan 3 16:22:50 2006 Subject: Registration of media type text/3gpp-tt In-Reply-To: "Your message dated Fri, 08 Oct 2004 11:44:26 +0200" <9D277E44D6EF0942B928C6F0DE99BB313308E1@lan-ex-01.panasonic.de> References: <9D277E44D6EF0942B928C6F0DE99BB313308E1@lan-ex-01.panasonic.de> Message-ID: <01LFTN0HK2Z200005Q@mauve.mrochek.com> > > > It is more than 2 weeks since I sent this in for consideration. Could > > > you please inform me about the status? I would like to proceed ASAP > > > with WGLC in AVT but cannot without passing this review. > > The ietf-types list is for informal media type reviews only. > > It is not where types are "considered" or "approved". > > Somtimes people comment on registrations, other times they don't. > Yes, you are right, "review" is the correct term. > However, reading the attached email from Colin, I understand that this review > is 'required' for WGLC. I'm reminded of an exchange from, I believe, Farmer's _The Riders of the Purple Wage_: Man to God: Sir, I exist! God to Man: Quite true, but that creates in me no sense of obligation. Having a requirement that some other group review something before it can be passed only makes sense if that other group is in some way obliged to actually do a review. No such obligation exists in this case, and past experience has been that such arrangement work badly or not at all in the IETF. This means that either (a) The absence of any comments needs to be construed as something akin to a neutral revew or (b) The requirement is specious and needs to be replaced or abandoned. > This means that whether this review is "no comments" or there are in fact > comments, I (we) have to know in order to progress the document. Specially > this part (original attached): > "In future, as new RTP payload formats are developed, we will require expert > review of the media type registration as part of the working group last call > process. Please contact the chairs for guidance on the procedure for this > review, when you believe your draft is ready for working group last call. We > will not forward drafts to the IESG for publication **unless they have received > such review.**" It isn't clear to me that this actually refers to the ietf-types list, but perhaps that was stated in some other message. In any case, an process that relies on someone on the ietf-types list saying something is inherently broken and needs to be fixed. Ned From: Rey at panasonic.de (Rey Jose) Date: Fri Oct 8 12:17:18 2004 Subject: Registration of media type text/3gpp-tt Message-ID: <9D277E44D6EF0942B928C6F0DE99BB313308E3@lan-ex-01.panasonic.de> --snip-- > > However, reading the attached email from Colin, I > understand that this > > review is 'required' for WGLC. This means that whether > this review is > > "no comments" or there are in fact comments, I (we) have to know in > > order to progress the document. Specially this part (original > > attached): > > > > "In future, as new RTP payload formats are developed, we > will require > > expert review of the media type registration as part of the working > > group last call process. Please contact the chairs for > guidance on the > > procedure for this review, when you believe your draft is ready for > > working group last call. We will not forward drafts to the IESG for > > publication **unless they have received such review.**" > > This is an AVT policy, to avoid last minute confusion and > problems such as we had with the RTP payload format for text > conversation; it's not a wider IETF requirement. If no > comments result after a reasonable time period, so be it. > Oops! my mistake, I really had "AVT" written while drafting the email, must have deleted it... I understand that these rules are restricted to AVT, but from your email it is not clear that no response from the IETF-TYPES after a "reasonable time period" (whatever that is, probably >= 2 weeks) is also fine for proceeding with WGLC. Anyhow, Martin Duerst did have a comment which I answered. So I'll wait for that to be solved. Jos? > Colin > > > From: Rey at panasonic.de (Rey Jose) Date: Tue Jan 3 16:22:50 2006 Subject: Registration of media type text/3gpp-tt Message-ID: <9D277E44D6EF0942B928C6F0DE99BB313308E3@lan-ex-01.panasonic.de> --snip-- > > However, reading the attached email from Colin, I > understand that this > > review is 'required' for WGLC. This means that whether > this review is > > "no comments" or there are in fact comments, I (we) have to know in > > order to progress the document. Specially this part (original > > attached): > > > > "In future, as new RTP payload formats are developed, we > will require > > expert review of the media type registration as part of the working > > group last call process. Please contact the chairs for > guidance on the > > procedure for this review, when you believe your draft is ready for > > working group last call. We will not forward drafts to the IESG for > > publication **unless they have received such review.**" > > This is an AVT policy, to avoid last minute confusion and > problems such as we had with the RTP payload format for text > conversation; it's not a wider IETF requirement. If no > comments result after a reasonable time period, so be it. > Oops! my mistake, I really had "AVT" written while drafting the email, must have deleted it... I understand that these rules are restricted to AVT, but from your email it is not clear that no response from the IETF-TYPES after a "reasonable time period" (whatever that is, probably >= 2 weeks) is also fine for proceeding with WGLC. Anyhow, Martin Duerst did have a comment which I answered. So I'll wait for that to be solved. Jos? > Colin > > > From: Rey at panasonic.de (Rey Jose) Date: Fri Oct 8 11:44:45 2004 Subject: Registration of media type text/3gpp-tt Message-ID: <9D277E44D6EF0942B928C6F0DE99BB313308E1@lan-ex-01.panasonic.de> > -----Original Message----- > From: ned.freed@mrochek.com [mailto:ned.freed@mrochek.com] > Sent: Friday, October 08, 2004 4:43 AM > To: Rey Jose > Cc: IETF-Types; Colin Perkins > Subject: RE: Registration of media type text/3gpp-tt > > > It is more than 2 weeks since I sent this in for > consideration. Could > > you please inform me about the status? I would like to > proceed ASAP > > with WGLC in AVT but cannot without passing this review. > > The ietf-types list is for informal media type reviews only. > It is not where types are "considered" or "approved". > Somtimes people comment on registrations, other times they don't. > Yes, you are right, "review" is the correct term. However, reading the attached email from Colin, I understand that this review is 'required' for WGLC. This means that whether this review is "no comments" or there are in fact comments, I (we) have to know in order to progress the document. Specially this part (original attached): "In future, as new RTP payload formats are developed, we will require expert review of the media type registration as part of the working group last call process. Please contact the chairs for guidance on the procedure for this review, when you believe your draft is ready for working group last call. We will not forward drafts to the IESG for publication **unless they have received such review.**" Thanks, Jos? > This type appears to be specified in an internet-draft that > is destined to become an RFC. If that's the case, the media > type will be reviewed as part of the IESG review and RFC > publication process. > > Ned > > -------------- next part -------------- An embedded message was scrubbed... From: "Colin Perkins" Subject: [AVT] RTP and Media Types Date: Thu, 5 Aug 2004 19:08:35 +0200 Size: 5895 Url: http://eikenes.alvestrand.no/pipermail/ietf-types/attachments/20041008/20092f2d/attachment-0001.eml >From csp@csperkins.org Fri Oct 8 11:52:02 2004 From: csp at csperkins.org (Colin Perkins) Date: Fri Oct 8 11:52:19 2004 Subject: Registration of media type text/3gpp-tt In-Reply-To: <9D277E44D6EF0942B928C6F0DE99BB313308E1@lan-ex-01.panasonic.de> References: <9D277E44D6EF0942B928C6F0DE99BB313308E1@lan-ex-01.panasonic.de> Message-ID: Jose, On 8 Oct 2004, at 10:44, Rey Jose wrote: ... >> The ietf-types list is for informal media type reviews only. >> It is not where types are "considered" or "approved". >> Somtimes people comment on registrations, other times they don't. >> > > Yes, you are right, "review" is the correct term. > > However, reading the attached email from Colin, I understand that this > review is 'required' for WGLC. This means that whether this review is > "no comments" or there are in fact comments, I (we) have to know in > order to progress the document. Specially this part (original > attached): > > "In future, as new RTP payload formats are developed, we will require > expert review of the media type registration as part of the working > group last call process. Please contact the chairs for guidance on the > procedure for this review, when you believe your draft is ready for > working group last call. We will not forward drafts to the IESG for > publication **unless they have received such review.**" This is an AVT policy, to avoid last minute confusion and problems such as we had with the RTP payload format for text conversation; it's not a wider IETF requirement. If no comments result after a reasonable time period, so be it. Colin From: Rey at panasonic.de (Rey Jose) Date: Tue Jan 3 16:22:50 2006 Subject: Registration of media type text/3gpp-tt Message-ID: <9D277E44D6EF0942B928C6F0DE99BB313308E1@lan-ex-01.panasonic.de> > -----Original Message----- > From: ned.freed@mrochek.com [mailto:ned.freed@mrochek.com] > Sent: Friday, October 08, 2004 4:43 AM > To: Rey Jose > Cc: IETF-Types; Colin Perkins > Subject: RE: Registration of media type text/3gpp-tt > > > It is more than 2 weeks since I sent this in for > consideration. Could > > you please inform me about the status? I would like to > proceed ASAP > > with WGLC in AVT but cannot without passing this review. > > The ietf-types list is for informal media type reviews only. > It is not where types are "considered" or "approved". > Somtimes people comment on registrations, other times they don't. > Yes, you are right, "review" is the correct term. However, reading the attached email from Colin, I understand that this review is 'required' for WGLC. This means that whether this review is "no comments" or there are in fact comments, I (we) have to know in order to progress the document. Specially this part (original attached): "In future, as new RTP payload formats are developed, we will require expert review of the media type registration as part of the working group last call process. Please contact the chairs for guidance on the procedure for this review, when you believe your draft is ready for working group last call. We will not forward drafts to the IESG for publication **unless they have received such review.**" Thanks, Jos? > This type appears to be specified in an internet-draft that > is destined to become an RFC. If that's the case, the media > type will be reviewed as part of the IESG review and RFC > publication process. > > Ned > > -------------- next part -------------- An embedded message was scrubbed... From: "Colin Perkins" Subject: [AVT] RTP and Media Types Date: Thu, 5 Aug 2004 19:08:35 +0200 Size: 5895 Url: http://www.alvestrand.no/pipermail/ietf-types/attachments/20041008/20092f2d/attachment.mht >From csp@csperkins.org Fri Oct 8 11:52:02 2004 From: csp at csperkins.org (Colin Perkins) Date: Tue Jan 3 16:22:50 2006 Subject: Registration of media type text/3gpp-tt In-Reply-To: <9D277E44D6EF0942B928C6F0DE99BB313308E1@lan-ex-01.panasonic.de> References: <9D277E44D6EF0942B928C6F0DE99BB313308E1@lan-ex-01.panasonic.de> Message-ID: Jose, On 8 Oct 2004, at 10:44, Rey Jose wrote: ... >> The ietf-types list is for informal media type reviews only. >> It is not where types are "considered" or "approved". >> Somtimes people comment on registrations, other times they don't. >> > > Yes, you are right, "review" is the correct term. > > However, reading the attached email from Colin, I understand that this > review is 'required' for WGLC. This means that whether this review is > "no comments" or there are in fact comments, I (we) have to know in > order to progress the document. Specially this part (original > attached): > > "In future, as new RTP payload formats are developed, we will require > expert review of the media type registration as part of the working > group last call process. Please contact the chairs for guidance on the > procedure for this review, when you believe your draft is ready for > working group last call. We will not forward drafts to the IESG for > publication **unless they have received such review.**" This is an AVT policy, to avoid last minute confusion and problems such as we had with the RTP payload format for text conversation; it's not a wider IETF requirement. If no comments result after a reasonable time period, so be it. Colin From: Rey at panasonic.de (Rey Jose) Date: Fri Oct 8 10:24:35 2004 Subject: Registration of media type text/3gpp-tt Message-ID: <9D277E44D6EF0942B928C6F0DE99BB313308DB@lan-ex-01.panasonic.de> Hi Thanks for the answer. > -----Original Message----- > From: Martin Duerst [mailto:duerst@w3.org] > Sent: Friday, October 08, 2004 7:05 AM > To: Rey Jose; IETF-Types > Cc: Colin Perkins > Subject: RE: Registration of media type text/3gpp-tt > > Quickly looking at this, I see that it deals with text, but > there is no mention about how this text is encoded. Text is encoded using UTF-8 or UTF-16. But there is not only text in the payload; there is also modifiers, which are binary. Modifiers are information pieces that allow, e.g., to make karaoke. As I understand from draft-freed-media-type-reg-01 the "Encoding Considerations"section only takes a value. In this case I think "binary" is appropriate since both UTF-8/-16s strings and the binary modifiers are mixed in the payload. I don't think it is needed to explain this again in the registration since a client accepting this media type already knows this. Looking forward to your comments, Jose > This is usually (but not always!) a sign that something may > have been overlooked. > > > Regards, Martin. > > At 10:27 04/10/07 +0200, Rey Jose wrote: > > > >Hello, > > > >It is more than 2 weeks since I sent this in for > consideration. Could > >you please inform me about the status? I would like to proceed ASAP > >with WGLC in AVT but cannot without passing this review. > > > >Thanks, > > > >Jos? > > > -----Original Message----- > > > From: Jose Rey [mailto:rey@panasonic.de] > > > Sent: Monday, September 13, 2004 10:30 AM > > > To: IETF-Types > > > Cc: Yoshinori Matsui; Dave Singer; Jan van der Meer; > Colin Perkins; > > > Magnus Westerlund (KI/EAB) > > > Subject: Registration of media type text/3gpp-tt > > > > > > > > > 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-ti > > > med-text-06.txt. > > > > > > 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@panasonic.de > > > Yoshinori Matsui, matsui.yoshinori@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@panasonic.de > > > Web: www.prdcg.panasonic.de > > > --------------------------------- > > > > > > From: Rey at panasonic.de (Rey Jose) Date: Tue Jan 3 16:22:50 2006 Subject: Registration of media type text/3gpp-tt Message-ID: <9D277E44D6EF0942B928C6F0DE99BB313308DB@lan-ex-01.panasonic.de> Hi Thanks for the answer. > -----Original Message----- > From: Martin Duerst [mailto:duerst@w3.org] > Sent: Friday, October 08, 2004 7:05 AM > To: Rey Jose; IETF-Types > Cc: Colin Perkins > Subject: RE: Registration of media type text/3gpp-tt > > Quickly looking at this, I see that it deals with text, but > there is no mention about how this text is encoded. Text is encoded using UTF-8 or UTF-16. But there is not only text in the payload; there is also modifiers, which are binary. Modifiers are information pieces that allow, e.g., to make karaoke. As I understand from draft-freed-media-type-reg-01 the "Encoding Considerations"section only takes a value. In this case I think "binary" is appropriate since both UTF-8/-16s strings and the binary modifiers are mixed in the payload. I don't think it is needed to explain this again in the registration since a client accepting this media type already knows this. Looking forward to your comments, Jose > This is usually (but not always!) a sign that something may > have been overlooked. > > > Regards, Martin. > > At 10:27 04/10/07 +0200, Rey Jose wrote: > > > >Hello, > > > >It is more than 2 weeks since I sent this in for > consideration. Could > >you please inform me about the status? I would like to proceed ASAP > >with WGLC in AVT but cannot without passing this review. > > > >Thanks, > > > >Jos? > > > -----Original Message----- > > > From: Jose Rey [mailto:rey@panasonic.de] > > > Sent: Monday, September 13, 2004 10:30 AM > > > To: IETF-Types > > > Cc: Yoshinori Matsui; Dave Singer; Jan van der Meer; > Colin Perkins; > > > Magnus Westerlund (KI/EAB) > > > Subject: Registration of media type text/3gpp-tt > > > > > > > > > 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-ti > > > med-text-06.txt. > > > > > > 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@panasonic.de > > > Yoshinori Matsui, matsui.yoshinori@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@panasonic.de > > > Web: www.prdcg.panasonic.de > > > --------------------------------- > > > > > > From: duerst at w3.org (Martin Duerst) Date: Tue Jan 3 16:22:50 2006 Subject: Registration of media type text/3gpp-tt In-Reply-To: <9D277E44D6EF0942B928C6F0DE99BB31330888@lan-ex-01.panasonic .de> Message-ID: <4.2.0.58.J.20041008140332.05917e20@localhost> Quickly looking at this, I see that it deals with text, but there is no mention about how this text is encoded. This is usually (but not always!) a sign that something may have been overlooked. Regards, Martin. At 10:27 04/10/07 +0200, Rey Jose wrote: > >Hello, > >It is more than 2 weeks since I sent this in for consideration. Could you >please inform me about the status? I would like to proceed ASAP with WGLC >in AVT but cannot without passing this review. > >Thanks, > >Jos? > > -----Original Message----- > > From: Jose Rey [mailto:rey@panasonic.de] > > Sent: Monday, September 13, 2004 10:30 AM > > To: IETF-Types > > Cc: Yoshinori Matsui; Dave Singer; Jan van der Meer; Colin > > Perkins; Magnus Westerlund (KI/EAB) > > Subject: Registration of media type text/3gpp-tt > > > > > > 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-ti > > med-text-06.txt. > > > > 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@panasonic.de > > Yoshinori Matsui, matsui.yoshinori@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@panasonic.de > > Web: www.prdcg.panasonic.de > > --------------------------------- > > From: Rey at panasonic.de (Rey Jose) Date: Thu Oct 7 10:27:50 2004 Subject: Registration of media type text/3gpp-tt Message-ID: <9D277E44D6EF0942B928C6F0DE99BB31330888@lan-ex-01.panasonic.de> Hello, It is more than 2 weeks since I sent this in for consideration. Could you please inform me about the status? I would like to proceed ASAP with WGLC in AVT but cannot without passing this review. Thanks, Jos? > -----Original Message----- > From: Jose Rey [mailto:rey@panasonic.de] > Sent: Monday, September 13, 2004 10:30 AM > To: IETF-Types > Cc: Yoshinori Matsui; Dave Singer; Jan van der Meer; Colin > Perkins; Magnus Westerlund (KI/EAB) > Subject: Registration of media type text/3gpp-tt > > > 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-ti > med-text-06.txt. > > 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@panasonic.de > Yoshinori Matsui, matsui.yoshinori@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@panasonic.de > Web: www.prdcg.panasonic.de > --------------------------------- > -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/ms-tnef Size: 5944 bytes Desc: not available Url : http://eikenes.alvestrand.no/pipermail/ietf-types/attachments/20041007/153ad662/attachment.bin >From ned.freed@mrochek.com Fri Oct 8 04:43:11 2004 From: ned.freed at mrochek.com (ned.freed@mrochek.com) Date: Fri Oct 8 04:51:49 2004 Subject: Registration of media type text/3gpp-tt In-Reply-To: "Your message dated Thu, 07 Oct 2004 10:27:31 +0200" <9D277E44D6EF0942B928C6F0DE99BB31330888@lan-ex-01.panasonic.de> Message-ID: <01LFRFUR7C2C00005R@mauve.mrochek.com> > It is more than 2 weeks since I sent this in for consideration. Could you > please inform me about the status? I would like to proceed ASAP with WGLC in > AVT but cannot without passing this review. The ietf-types list is for informal media type reviews only. It is not where types are "considered" or "approved". Somtimes people comment on registrations, other times they don't. This type appears to be specified in an internet-draft that is destined to become an RFC. If that's the case, the media type will be reviewed as part of the IESG review and RFC publication process. Ned >From duerst@w3.org Fri Oct 8 07:04:39 2004 From: duerst at w3.org (Martin Duerst) Date: Fri Oct 8 08:45:53 2004 Subject: Registration of media type text/3gpp-tt In-Reply-To: <9D277E44D6EF0942B928C6F0DE99BB31330888@lan-ex-01.panasonic .de> Message-ID: <4.2.0.58.J.20041008140332.05917e20@localhost> Quickly looking at this, I see that it deals with text, but there is no mention about how this text is encoded. This is usually (but not always!) a sign that something may have been overlooked. Regards, Martin. At 10:27 04/10/07 +0200, Rey Jose wrote: > >Hello, > >It is more than 2 weeks since I sent this in for consideration. Could you >please inform me about the status? I would like to proceed ASAP with WGLC >in AVT but cannot without passing this review. > >Thanks, > >Jos? > > -----Original Message----- > > From: Jose Rey [mailto:rey@panasonic.de] > > Sent: Monday, September 13, 2004 10:30 AM > > To: IETF-Types > > Cc: Yoshinori Matsui; Dave Singer; Jan van der Meer; Colin > > Perkins; Magnus Westerlund (KI/EAB) > > Subject: Registration of media type text/3gpp-tt > > > > > > 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-ti > > med-text-06.txt. > > > > 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@panasonic.de > > Yoshinori Matsui, matsui.yoshinori@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@panasonic.de > > Web: www.prdcg.panasonic.de > > --------------------------------- > > From: Rey at panasonic.de (Rey Jose) Date: Tue Jan 3 16:22:50 2006 Subject: Registration of media type text/3gpp-tt Message-ID: <9D277E44D6EF0942B928C6F0DE99BB31330888@lan-ex-01.panasonic.de> Hello, It is more than 2 weeks since I sent this in for consideration. Could you please inform me about the status? I would like to proceed ASAP with WGLC in AVT but cannot without passing this review. Thanks, Jos? > -----Original Message----- > From: Jose Rey [mailto:rey@panasonic.de] > Sent: Monday, September 13, 2004 10:30 AM > To: IETF-Types > Cc: Yoshinori Matsui; Dave Singer; Jan van der Meer; Colin > Perkins; Magnus Westerlund (KI/EAB) > Subject: Registration of media type text/3gpp-tt > > > 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-ti > med-text-06.txt. > > 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@panasonic.de > Yoshinori Matsui, matsui.yoshinori@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@panasonic.de > Web: www.prdcg.panasonic.de > --------------------------------- > -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/ms-tnef Size: 5944 bytes Desc: not available Url : http://www.alvestrand.no/pipermail/ietf-types/attachments/20041007/153ad662/attachment-0002.bin >From ned.freed@mrochek.com Fri Oct 8 04:43:11 2004 From: ned.freed at mrochek.com (ned.freed@mrochek.com) Date: Tue Jan 3 16:22:50 2006 Subject: Registration of media type text/3gpp-tt In-Reply-To: "Your message dated Thu, 07 Oct 2004 10:27:31 +0200" <9D277E44D6EF0942B928C6F0DE99BB31330888@lan-ex-01.panasonic.de> Message-ID: <01LFRFUR7C2C00005R@mauve.mrochek.com> > It is more than 2 weeks since I sent this in for consideration. Could you > please inform me about the status? I would like to proceed ASAP with WGLC in > AVT but cannot without passing this review. The ietf-types list is for informal media type reviews only. It is not where types are "considered" or "approved". Somtimes people comment on registrations, other times they don't. This type appears to be specified in an internet-draft that is destined to become an RFC. If that's the case, the media type will be reviewed as part of the IESG review and RFC publication process. Ned From: dbooth at w3.org (David Booth) Date: Mon Oct 4 18:06:18 2004 Subject: Proposed media type registration: application/wsdl+xml Message-ID: <1096905962.3417.103.camel@nc6000.w3.org> The proposed registration below is for a media type "application/wsdl+xml" for use with WSDL 2.0 documents. The registration will be requested on behalf of the W3C Web Services Description Working Group. WSDL 2.0 documents are used to describe Web services. The specification of the WSDL 2.0 language itself is available at http://www.w3.org/TR/wsdl20 . This media type definition appears in http://www.w3.org/TR/wsdl20#ietf-draft , which will be updated as necessary. (The version below is the most recent.) This proposed registration is for community review and will be submitted to the IESG for review, approval, and registration with IANA at a later stage. The Last Call period for WSDL 2.0 ends 4 October 2004. However, because of this late notification, the deadline for comments on the media type registration has been extended to 18 October 2004. ======================================================= To: ietf-types@iana.org Subject: Registration of media type application/wsdl+xml Type name: application Subtype name: wsdl+xml Required parameters: none Optional parameters: charset This parameter has identical semantics to the charset parameter of the "application/xml" media type as specified in [RFC 3023] ( http://www.ietf.org/rfc/rfc3023.txt ). Encoding considerations: Identical to those of "application/xml" as described in [RFC 3023] ( http://www.ietf.org/rfc/rfc3023.txt ) section 3.2, as applied to the WSDL document infoset. Restrictions on usage: none Security considerations: This media type uses the "+xml" convention. It shares the same security considerations as described in [RFC 3023] ( http://www.ietf.org/rfc/rfc3023.txt ) section 10. Interoperability considerations: There are no known interoperability issues. Published specification: [WSDL 2.0 Core Language] ( http://www.w3.org/TR/wsdl20 ), [WSDL 2.0 Predefined Extensions] ( http://www.w3.org/TR/wsdl20-extensions ), and [WSDL 2.0 Bindings] ( http://www.w3.org/TR/wsdl20-bindings ). Applications which use this media type: No known applications currently use this media type. Additional information: Magic number(s): In general, the same as for application/xml [RFC 3023] ( http://www.ietf.org/rfc/rfc3023.txt ). In particular, the XML root element of the returned object will be , where "wsdl" as any namespace prefix that maps to a WSDL 2.0 namespace URI, as defined in [WSDL 2.0 Core Language] ( http://www.w3.org/TR/wsdl20 ). File extension(s): wsdl Macintosh File Type Code(s): WSDL Base URI: As specified in [RFC 3023] ( http://www.ietf.org/rfc/rfc3023.txt ) section 6. Fragment identifiers: As specified in [WSDL 2.0 FragIDs]. Person & email address to contact for further information: David Booth Intended usage: COMMON Author/Change controller: The WSDL 2.0 specification set is a work product of the World Wide Web Consortium's Web Service Description Working Group [WSDL 2.0 WG]. The W3C has change control over these specifications. References: [RFC 3023] IETF "RFC 3023: XML Media Types", M. Murata, S. St. Laurent, D. Kohn, July 1998. (See http://www.ietf.org/rfc/rfc3023.txt .) [WSDL 2.0 Core Language] Web Services Description Language (WSDL) Version 2.0 Part 1: Core Language, R. Chinnici, M. Gudgin, J-J. Moreau, S. Weerawarana, Editors. World Wide Web Consortium, 3 August 2004. This version of the "Web Services Description Language (WSDL) Version 2.0 Part 1: Core Language" Specification is available is available at http://www.w3.org/TR/2004/WD-wsdl20-20040803 . The latest version of "Web Services Description Language (WSDL) Version 2.0 Part 1: Core Language" is available at http://www.w3.org/TR/wsdl20 . [WSDL 2.0 FragIDs] WSDL 2.0 Fragment Identifiers. This is a subsection of [WSDL 2.0 Core Language] above. The latest version is available at http://www.w3.org/TR/wsdl20/#frag-ids [WSDL 2.0 Predefined Extensions] Web Services Description Language (WSDL) Version 2.0 Part 2: Predefined Extensions, M. Gudgin, A. Lewis, and J. Schlimmer, Editors. World Wide Web Consortium, 3 August 2004. This version of the "Web Services Description Language (WSDL) Version 2.0 Part 2: Predefined Extensions" Specification is available at http://www.w3.org/TR/2004/WD-wsdl20-extensions-20040803 . The latest version of "Web Services Description Language (WSDL) Version 2.0 Part 2: Predefined Extensions" is available at http://www.w3.org/TR/wsdl20-extensions . [WSDL 2.0 Bindings] Web Services Description Language (WSDL) Version 2.0 Part 3: Bindings, H. Haas, P. Le H?garet, J-J. Moreau, D. Orchard, J. Schlimmer, Editors. World Wide Web Consortium, 3 August 2004. This version of the "Web Services Description Language (WSDL) Version 2.0 Part 3: Bindings" Specification is available at http://www.w3.org/TR/2004/WD-wsdl20-bindings-20040803 . The latest version of "Web Services Description Language (WSDL) Version 2.0 Part 3: Bindings" is available at http://www.w3.org/TR/wsdl20-bindings . [WSDL 2.0 WG] The W3C Web Services Description Working Group. Information about this Working Group is available at http://www.w3.org/2002/ws/desc/ [XML 1.0] Extensible Markup Language (XML) 1.0 (Second Edition), T. Bray, J. Paoli, C. M. Sperberg-McQueen, and E. Maler, Editors. World Wide Web Consortium, 10 February 1998, revised 6 October 2000. This version of the XML 1.0 Recommendation is http://www.w3.org/TR/2000/REC-xml-20001006 . The latest version of XML 1.0 is available at http://www.w3.org/TR/REC-xml . -------------------- The proposal above was prepared following instructions at http://www.ietf.org/internet-drafts/draft-freed-media-type-reg-01.txt , and further instructions at http://www.w3.org/2002/06/registering-mediatype.html , since this is a media type from W3C. -- David Booth W3C Fellow / Hewlett-Packard From: dbooth at w3.org (David Booth) Date: Tue Jan 3 16:22:50 2006 Subject: Proposed media type registration: application/wsdl+xml Message-ID: <1096905962.3417.103.camel@nc6000.w3.org> The proposed registration below is for a media type "application/wsdl+xml" for use with WSDL 2.0 documents. The registration will be requested on behalf of the W3C Web Services Description Working Group. WSDL 2.0 documents are used to describe Web services. The specification of the WSDL 2.0 language itself is available at http://www.w3.org/TR/wsdl20 . This media type definition appears in http://www.w3.org/TR/wsdl20#ietf-draft , which will be updated as necessary. (The version below is the most recent.) This proposed registration is for community review and will be submitted to the IESG for review, approval, and registration with IANA at a later stage. The Last Call period for WSDL 2.0 ends 4 October 2004. However, because of this late notification, the deadline for comments on the media type registration has been extended to 18 October 2004. ======================================================= To: ietf-types@iana.org Subject: Registration of media type application/wsdl+xml Type name: application Subtype name: wsdl+xml Required parameters: none Optional parameters: charset This parameter has identical semantics to the charset parameter of the "application/xml" media type as specified in [RFC 3023] ( http://www.ietf.org/rfc/rfc3023.txt ). Encoding considerations: Identical to those of "application/xml" as described in [RFC 3023] ( http://www.ietf.org/rfc/rfc3023.txt ) section 3.2, as applied to the WSDL document infoset. Restrictions on usage: none Security considerations: This media type uses the "+xml" convention. It shares the same security considerations as described in [RFC 3023] ( http://www.ietf.org/rfc/rfc3023.txt ) section 10. Interoperability considerations: There are no known interoperability issues. Published specification: [WSDL 2.0 Core Language] ( http://www.w3.org/TR/wsdl20 ), [WSDL 2.0 Predefined Extensions] ( http://www.w3.org/TR/wsdl20-extensions ), and [WSDL 2.0 Bindings] ( http://www.w3.org/TR/wsdl20-bindings ). Applications which use this media type: No known applications currently use this media type. Additional information: Magic number(s): In general, the same as for application/xml [RFC 3023] ( http://www.ietf.org/rfc/rfc3023.txt ). In particular, the XML root element of the returned object will be , where "wsdl" as any namespace prefix that maps to a WSDL 2.0 namespace URI, as defined in [WSDL 2.0 Core Language] ( http://www.w3.org/TR/wsdl20 ). File extension(s): wsdl Macintosh File Type Code(s): WSDL Base URI: As specified in [RFC 3023] ( http://www.ietf.org/rfc/rfc3023.txt ) section 6. Fragment identifiers: As specified in [WSDL 2.0 FragIDs]. Person & email address to contact for further information: David Booth Intended usage: COMMON Author/Change controller: The WSDL 2.0 specification set is a work product of the World Wide Web Consortium's Web Service Description Working Group [WSDL 2.0 WG]. The W3C has change control over these specifications. References: [RFC 3023] IETF "RFC 3023: XML Media Types", M. Murata, S. St. Laurent, D. Kohn, July 1998. (See http://www.ietf.org/rfc/rfc3023.txt .) [WSDL 2.0 Core Language] Web Services Description Language (WSDL) Version 2.0 Part 1: Core Language, R. Chinnici, M. Gudgin, J-J. Moreau, S. Weerawarana, Editors. World Wide Web Consortium, 3 August 2004. This version of the "Web Services Description Language (WSDL) Version 2.0 Part 1: Core Language" Specification is available is available at http://www.w3.org/TR/2004/WD-wsdl20-20040803 . The latest version of "Web Services Description Language (WSDL) Version 2.0 Part 1: Core Language" is available at http://www.w3.org/TR/wsdl20 . [WSDL 2.0 FragIDs] WSDL 2.0 Fragment Identifiers. This is a subsection of [WSDL 2.0 Core Language] above. The latest version is available at http://www.w3.org/TR/wsdl20/#frag-ids [WSDL 2.0 Predefined Extensions] Web Services Description Language (WSDL) Version 2.0 Part 2: Predefined Extensions, M. Gudgin, A. Lewis, and J. Schlimmer, Editors. World Wide Web Consortium, 3 August 2004. This version of the "Web Services Description Language (WSDL) Version 2.0 Part 2: Predefined Extensions" Specification is available at http://www.w3.org/TR/2004/WD-wsdl20-extensions-20040803 . The latest version of "Web Services Description Language (WSDL) Version 2.0 Part 2: Predefined Extensions" is available at http://www.w3.org/TR/wsdl20-extensions . [WSDL 2.0 Bindings] Web Services Description Language (WSDL) Version 2.0 Part 3: Bindings, H. Haas, P. Le H?garet, J-J. Moreau, D. Orchard, J. Schlimmer, Editors. World Wide Web Consortium, 3 August 2004. This version of the "Web Services Description Language (WSDL) Version 2.0 Part 3: Bindings" Specification is available at http://www.w3.org/TR/2004/WD-wsdl20-bindings-20040803 . The latest version of "Web Services Description Language (WSDL) Version 2.0 Part 3: Bindings" is available at http://www.w3.org/TR/wsdl20-bindings . [WSDL 2.0 WG] The W3C Web Services Description Working Group. Information about this Working Group is available at http://www.w3.org/2002/ws/desc/ [XML 1.0] Extensible Markup Language (XML) 1.0 (Second Edition), T. Bray, J. Paoli, C. M. Sperberg-McQueen, and E. Maler, Editors. World Wide Web Consortium, 10 February 1998, revised 6 October 2000. This version of the XML 1.0 Recommendation is http://www.w3.org/TR/2000/REC-xml-20001006 . The latest version of XML 1.0 is available at http://www.w3.org/TR/REC-xml . -------------------- The proposal above was prepared following instructions at http://www.ietf.org/internet-drafts/draft-freed-media-type-reg-01.txt , and further instructions at http://www.w3.org/2002/06/registering-mediatype.html , since this is a media type from W3C. -- David Booth W3C Fellow / Hewlett-Packard From: csp at csperkins.org (Colin Perkins) Date: Tue Jan 3 16:22:50 2006 Subject: [AVT] Re: Comments on draft-freed-media-types-reg-01.txt In-Reply-To: <01LFLM83HHTG00005R@mauve.mrochek.com> References: <413DC83F.7070807@ericsson.com> <01LEKW44X2UM00005R@mauve.mrochek.com> <413F03BF.5040407@ericsson.com> <01LEM6VYBBDE00005R@mauve.mrochek.com> <4CDCE53A-03DE-11D9-A048-000A957FC5F2@csperkins.org> <01LEQL2HYS4000005R@mauve.mrochek.com> <01LF8MCCIOM400005R@mauve.mrochek.com> <01LFATFLKFG600005R@mauve.mrochek.com> <01LFLB1HN9SU00005R@mauve.mrochek.com> <4C2DF04E-1587-11D9-B636-000A957FC5F2@csperkins.org> <01LFLM83HHTG00005R@mauve.mrochek.com> Message-ID: <6E33DC8A-1597-11D9-B636-000A957FC5F2@csperkins.org> On 3 Oct 2004, at 23:40, ned.freed@mrochek.com wrote: >> > > I don't see this as realistic, >> > > since the entire reasoning behind specifying domains of >> applicability >> > > for media types is to allow for different framing and parameters. > >> > I do not regard fundamental differences in what goes in the content >> > as a framing detail. Again, the metric needs to be based on >> > interoperability. > >> > Look, this discussion has become pointless. I find your proposal to >> > use the same media type name to identify different formats in >> > different domains to be completely unacceptable, so much so that I >> > will not be party to any draft that incorporates this concept. > >> THAT IS NOT MY PROPOSAL! > > On the contrary, that's exactly your proposal. Quoting your own > original > message on this thread: > > I'm a little concerned about the strength of this rule. I agree when > the parameter space is separate, but I can certainly envisage cases > when the parameter space and data format for two different domains > have a very high degree of overlap, and where it makes sense for them > to use the same media type. > > For example, there are several audio codecs where the RTP payload > format can be summarised as "put frames into RTP packets in order" and > the file format is "put frames into the file in order, following an > initial magic number". In both cases there are common parameters: > sampling rate, frame duration, and number of channels. However the RTP > payload format needs an additional parameter: maximum frame duration > (RTP packets have a size limit due to the path MTU, but the file > format supports any frame size). I'm not sure it makes sense to > require these to use different media types, since they're clearly the > same format applied to different domains, yet the above rule would > seem to require it. > > I have stated repeatedly that I regard data with and without some sort > of header as constituting different formats that require different > media types. And as I have repeatedly argued, this prevents use of the media type registry for different domains of applicability, since those domains will have different headers due to the framing. >> What I have been arguing for is to allow the >> framing and framing specific parameters to vary for different domains >> of applicability, yet have received nothing but push back on this. Go >> read RFC 3267; only the framing differs. > > File header/magic number != framing in my book. So, what do you mean by framing? In the examples I'm quoting, the media data format is bitwise identical in both cases. The difference is that it's framed in a file (and hence has a file header) rather than a series of RTP packets (and hence has an RTP header); once you strip the framing there is no difference in format. > And this will be my last message on this topic. Which doesn't resolve the conflict between draft-freed-media-types-reg -01.txt and existing practice. Much as you may dislike it, there are two proposed standards (RFC 3267 and 3558) which register formats in the way I describe. The change you propose is problematic for a significant user community, which has previously registered these types in good faith, according to IETF procedures. Colin From: ned.freed at mrochek.com (ned.freed@mrochek.com) Date: Mon Oct 4 00:48:47 2004 Subject: [AVT] Re: Comments on draft-freed-media-types-reg-01.txt In-Reply-To: "Your message dated Sun, 03 Oct 2004 22:58:02 +0100" <4C2DF04E-1587-11D9-B636-000A957FC5F2@csperkins.org> References: <413DC83F.7070807@ericsson.com> <01LEKW44X2UM00005R@mauve.mrochek.com> <413F03BF.5040407@ericsson.com> <01LEM6VYBBDE00005R@mauve.mrochek.com> <4CDCE53A-03DE-11D9-A048-000A957FC5F2@csperkins.org> <01LEQL2HYS4000005R@mauve.mrochek.com> <01LF8MCCIOM400005R@mauve.mrochek.com> <01LFATFLKFG600005R@mauve.mrochek.com> <01LFLB1HN9SU00005R@mauve.mrochek.com> <4C2DF04E-1587-11D9-B636-000A957FC5F2@csperkins.org> Message-ID: <01LFLM83HHTG00005R@mauve.mrochek.com> > > > I don't see this as realistic, > > > since the entire reasoning behind specifying domains of applicability > > > for media types is to allow for different framing and parameters. > > I do not regard fundamental differences in what goes in the content > > as a framing detail. Again, the metric needs to be based on > > interoperability. > > Look, this discussion has become pointless. I find your proposal to > > use the same media type name to identify different formats in > > different domains to be completely unacceptable, so much so that I > > will not be party to any draft that incorporates this concept. > THAT IS NOT MY PROPOSAL! On the contrary, that's exactly your proposal. Quoting your own original message on this thread: I'm a little concerned about the strength of this rule. I agree when the parameter space is separate, but I can certainly envisage cases when the parameter space and data format for two different domains have a very high degree of overlap, and where it makes sense for them to use the same media type. For example, there are several audio codecs where the RTP payload format can be summarised as "put frames into RTP packets in order" and the file format is "put frames into the file in order, following an initial magic number". In both cases there are common parameters: sampling rate, frame duration, and number of channels. However the RTP payload format needs an additional parameter: maximum frame duration (RTP packets have a size limit due to the path MTU, but the file format supports any frame size). I'm not sure it makes sense to require these to use different media types, since they're clearly the same format applied to different domains, yet the above rule would seem to require it. I have stated repeatedly that I regard data with and without some sort of header as constituting different formats that require different media types. > What I have been arguing for is to allow the > framing and framing specific parameters to vary for different domains > of applicability, yet have received nothing but push back on this. Go > read RFC 3267; only the framing differs. File header/magic number != framing in my book. And this will be my last message on this topic. Ned >From csp@csperkins.org Mon Oct 4 01:53:31 2004 From: csp at csperkins.org (Colin Perkins) Date: Mon Oct 4 01:53:48 2004 Subject: [AVT] Re: Comments on draft-freed-media-types-reg-01.txt In-Reply-To: <01LFLM83HHTG00005R@mauve.mrochek.com> References: <413DC83F.7070807@ericsson.com> <01LEKW44X2UM00005R@mauve.mrochek.com> <413F03BF.5040407@ericsson.com> <01LEM6VYBBDE00005R@mauve.mrochek.com> <4CDCE53A-03DE-11D9-A048-000A957FC5F2@csperkins.org> <01LEQL2HYS4000005R@mauve.mrochek.com> <01LF8MCCIOM400005R@mauve.mrochek.com> <01LFATFLKFG600005R@mauve.mrochek.com> <01LFLB1HN9SU00005R@mauve.mrochek.com> <4C2DF04E-1587-11D9-B636-000A957FC5F2@csperkins.org> <01LFLM83HHTG00005R@mauve.mrochek.com> Message-ID: <6E33DC8A-1597-11D9-B636-000A957FC5F2@csperkins.org> On 3 Oct 2004, at 23:40, ned.freed@mrochek.com wrote: >> > > I don't see this as realistic, >> > > since the entire reasoning behind specifying domains of >> applicability >> > > for media types is to allow for different framing and parameters. > >> > I do not regard fundamental differences in what goes in the content >> > as a framing detail. Again, the metric needs to be based on >> > interoperability. > >> > Look, this discussion has become pointless. I find your proposal to >> > use the same media type name to identify different formats in >> > different domains to be completely unacceptable, so much so that I >> > will not be party to any draft that incorporates this concept. > >> THAT IS NOT MY PROPOSAL! > > On the contrary, that's exactly your proposal. Quoting your own > original > message on this thread: > > I'm a little concerned about the strength of this rule. I agree when > the parameter space is separate, but I can certainly envisage cases > when the parameter space and data format for two different domains > have a very high degree of overlap, and where it makes sense for them > to use the same media type. > > For example, there are several audio codecs where the RTP payload > format can be summarised as "put frames into RTP packets in order" and > the file format is "put frames into the file in order, following an > initial magic number". In both cases there are common parameters: > sampling rate, frame duration, and number of channels. However the RTP > payload format needs an additional parameter: maximum frame duration > (RTP packets have a size limit due to the path MTU, but the file > format supports any frame size). I'm not sure it makes sense to > require these to use different media types, since they're clearly the > same format applied to different domains, yet the above rule would > seem to require it. > > I have stated repeatedly that I regard data with and without some sort > of header as constituting different formats that require different > media types. And as I have repeatedly argued, this prevents use of the media type registry for different domains of applicability, since those domains will have different headers due to the framing. >> What I have been arguing for is to allow the >> framing and framing specific parameters to vary for different domains >> of applicability, yet have received nothing but push back on this. Go >> read RFC 3267; only the framing differs. > > File header/magic number != framing in my book. So, what do you mean by framing? In the examples I'm quoting, the media data format is bitwise identical in both cases. The difference is that it's framed in a file (and hence has a file header) rather than a series of RTP packets (and hence has an RTP header); once you strip the framing there is no difference in format. > And this will be my last message on this topic. Which doesn't resolve the conflict between draft-freed-media-types-reg -01.txt and existing practice. Much as you may dislike it, there are two proposed standards (RFC 3267 and 3558) which register formats in the way I describe. The change you propose is problematic for a significant user community, which has previously registered these types in good faith, according to IETF procedures. Colin From: ned.freed at mrochek.com (ned.freed@mrochek.com) Date: Tue Jan 3 16:22:50 2006 Subject: [AVT] Re: Comments on draft-freed-media-types-reg-01.txt In-Reply-To: "Your message dated Sun, 03 Oct 2004 22:58:02 +0100" <4C2DF04E-1587-11D9-B636-000A957FC5F2@csperkins.org> References: <413DC83F.7070807@ericsson.com> <01LEKW44X2UM00005R@mauve.mrochek.com> <413F03BF.5040407@ericsson.com> <01LEM6VYBBDE00005R@mauve.mrochek.com> <4CDCE53A-03DE-11D9-A048-000A957FC5F2@csperkins.org> <01LEQL2HYS4000005R@mauve.mrochek.com> <01LF8MCCIOM400005R@mauve.mrochek.com> <01LFATFLKFG600005R@mauve.mrochek.com> <01LFLB1HN9SU00005R@mauve.mrochek.com> <4C2DF04E-1587-11D9-B636-000A957FC5F2@csperkins.org> Message-ID: <01LFLM83HHTG00005R@mauve.mrochek.com> > > > I don't see this as realistic, > > > since the entire reasoning behind specifying domains of applicability > > > for media types is to allow for different framing and parameters. > > I do not regard fundamental differences in what goes in the content > > as a framing detail. Again, the metric needs to be based on > > interoperability. > > Look, this discussion has become pointless. I find your proposal to > > use the same media type name to identify different formats in > > different domains to be completely unacceptable, so much so that I > > will not be party to any draft that incorporates this concept. > THAT IS NOT MY PROPOSAL! On the contrary, that's exactly your proposal. Quoting your own original message on this thread: I'm a little concerned about the strength of this rule. I agree when the parameter space is separate, but I can certainly envisage cases when the parameter space and data format for two different domains have a very high degree of overlap, and where it makes sense for them to use the same media type. For example, there are several audio codecs where the RTP payload format can be summarised as "put frames into RTP packets in order" and the file format is "put frames into the file in order, following an initial magic number". In both cases there are common parameters: sampling rate, frame duration, and number of channels. However the RTP payload format needs an additional parameter: maximum frame duration (RTP packets have a size limit due to the path MTU, but the file format supports any frame size). I'm not sure it makes sense to require these to use different media types, since they're clearly the same format applied to different domains, yet the above rule would seem to require it. I have stated repeatedly that I regard data with and without some sort of header as constituting different formats that require different media types. > What I have been arguing for is to allow the > framing and framing specific parameters to vary for different domains > of applicability, yet have received nothing but push back on this. Go > read RFC 3267; only the framing differs. File header/magic number != framing in my book. And this will be my last message on this topic. Ned From: csp at csperkins.org (Colin Perkins) Date: Tue Jan 3 16:22:49 2006 Subject: [AVT] Re: Comments on draft-freed-media-types-reg-01.txt In-Reply-To: <01LFLB1HN9SU00005R@mauve.mrochek.com> References: <413DC83F.7070807@ericsson.com> <01LEKW44X2UM00005R@mauve.mrochek.com> <413F03BF.5040407@ericsson.com> <01LEM6VYBBDE00005R@mauve.mrochek.com> <4CDCE53A-03DE-11D9-A048-000A957FC5F2@csperkins.org> <01LEQL2HYS4000005R@mauve.mrochek.com> <01LF8MCCIOM400005R@mauve.mrochek.com> <01LFATFLKFG600005R@mauve.mrochek.com> <01LFLB1HN9SU00005R@mauve.mrochek.com> Message-ID: <4C2DF04E-1587-11D9-B636-000A957FC5F2@csperkins.org> On 3 Oct 2004, at 18:22, ned.freed@mrochek.com wrote: >> On 26 Sep 2004, at 06:13, ned.freed@mrochek.com wrote: >> >> On 24 Sep 2004, at 16:29, ned.freed@mrochek.com wrote: >> ... >> >> > This admits the possibility of two conformant pieces of software >> >> > failing to interoperate, and that's not good. >> >> > >> >> >> > Now, nothing says you cannot use a naming convention of some >> sort >> >> >> to link the >> >> >> > two types in some way. But IMO they really need to be two >> >> different >> >> >> types. >> >> > >> >> >> In which case we have two different and separate namespaces, >> >> trying to >> >> >> share the same registry. This, IMHO, doesn't make sense. >> >> > >> >> > No, what we have is a single registry for specific formats and a >> >> way to >> >> > link formats that are in some way related. >> > >> >> But that link is the media type name, with the domain of >> applicability >> >> to prevent interoperability problems. This is done in RFCs 3267 and >> >> 3558, for example, and doesn't appear to have caused problems. >> > >> > Two examples where problems haven't yet arisen in a specific domain >> > doesn't mean much. There are hundreds of media types and who knows >> how >> > many domains of applicability, and the rules have to work for all of >> > them. > >> You seem to be arguing that the media types namespace cannot be shared >> between different domains of applicability unless those domains have >> the exact same framing and parameters. > > Nope. I'm arguing that a media type name needs to uniquely identify a > specific cononical format. Various encoding details, including some > aspects of framing, can of course be domain-specific. It is also > possible for an entire media type to have a single domain of > applicability, but in such cases it is still wrong to use the same > name for something different in another domain. yes, of course. >> I don't see this as realistic, >> since the entire reasoning behind specifying domains of applicability >> for media types is to allow for different framing and parameters. > > I do not regard fundamental differences in what goes in the content > as a framing detail. Again, the metric needs to be based on > interoperability. > > Look, this discussion has become pointless. I find your proposal to > use the same media type name to identify different formats in > different domains to be completely unacceptable, so much so that I > will not be party to any draft that incorporates this concept. THAT IS NOT MY PROPOSAL! What I have been arguing for is to allow the framing and framing specific parameters to vary for different domains of applicability, yet have received nothing but push back on this. Go read RFC 3267; only the framing differs. > Additionally, I see zero support being offered for this notion from > anyone else. I therefore regard the matter as closed. > > Ned > > -- Colin Perkins http://csperkins.org/ From: ned.freed at mrochek.com (ned.freed@mrochek.com) Date: Sun Oct 3 19:28:57 2004 Subject: [AVT] Re: Comments on draft-freed-media-types-reg-01.txt In-Reply-To: "Your message dated Sun, 03 Oct 2004 16:41:59 +0100" References: <413DC83F.7070807@ericsson.com> <01LEKW44X2UM00005R@mauve.mrochek.com> <413F03BF.5040407@ericsson.com> <01LEM6VYBBDE00005R@mauve.mrochek.com> <4CDCE53A-03DE-11D9-A048-000A957FC5F2@csperkins.org> <01LEQL2HYS4000005R@mauve.mrochek.com> <01LF8MCCIOM400005R@mauve.mrochek.com> <01LFATFLKFG600005R@mauve.mrochek.com> Message-ID: <01LFLB1HN9SU00005R@mauve.mrochek.com> > On 26 Sep 2004, at 06:13, ned.freed@mrochek.com wrote: > >> On 24 Sep 2004, at 16:29, ned.freed@mrochek.com wrote: > ... > >> > This admits the possibility of two conformant pieces of software > >> > failing to interoperate, and that's not good. > >> > > >> >> > Now, nothing says you cannot use a naming convention of some sort > >> >> to link the > >> >> > two types in some way. But IMO they really need to be two > >> different > >> >> types. > >> > > >> >> In which case we have two different and separate namespaces, > >> trying to > >> >> share the same registry. This, IMHO, doesn't make sense. > >> > > >> > No, what we have is a single registry for specific formats and a > >> way to > >> > link formats that are in some way related. > > > >> But that link is the media type name, with the domain of applicability > >> to prevent interoperability problems. This is done in RFCs 3267 and > >> 3558, for example, and doesn't appear to have caused problems. > > > > Two examples where problems haven't yet arisen in a specific domain > > doesn't mean much. There are hundreds of media types and who knows how > > many domains of applicability, and the rules have to work for all of > > them. > You seem to be arguing that the media types namespace cannot be shared > between different domains of applicability unless those domains have > the exact same framing and parameters. Nope. I'm arguing that a media type name needs to uniquely identify a specific cononical format. Various encoding details, including some aspects of framing, can of course be domain-specific. It is also possible for an entire media type to have a single domain of applicability, but in such cases it is still wrong to use the same name for something different in another domain. > I don't see this as realistic, > since the entire reasoning behind specifying domains of applicability > for media types is to allow for different framing and parameters. I do not regard fundamental differences in what goes in the content as a framing detail. Again, the metric needs to be based on interoperability. Look, this discussion has become pointless. I find your proposal to use the same media type name to identify different formats in different domains to be completely unacceptable, so much so that I will not be party to any draft that incorporates this concept. Additionally, I see zero support being offered for this notion from anyone else. I therefore regard the matter as closed. Ned >From csp@csperkins.org Sun Oct 3 23:58:02 2004 From: csp at csperkins.org (Colin Perkins) Date: Sun Oct 3 23:58:20 2004 Subject: [AVT] Re: Comments on draft-freed-media-types-reg-01.txt In-Reply-To: <01LFLB1HN9SU00005R@mauve.mrochek.com> References: <413DC83F.7070807@ericsson.com> <01LEKW44X2UM00005R@mauve.mrochek.com> <413F03BF.5040407@ericsson.com> <01LEM6VYBBDE00005R@mauve.mrochek.com> <4CDCE53A-03DE-11D9-A048-000A957FC5F2@csperkins.org> <01LEQL2HYS4000005R@mauve.mrochek.com> <01LF8MCCIOM400005R@mauve.mrochek.com> <01LFATFLKFG600005R@mauve.mrochek.com> <01LFLB1HN9SU00005R@mauve.mrochek.com> Message-ID: <4C2DF04E-1587-11D9-B636-000A957FC5F2@csperkins.org> On 3 Oct 2004, at 18:22, ned.freed@mrochek.com wrote: >> On 26 Sep 2004, at 06:13, ned.freed@mrochek.com wrote: >> >> On 24 Sep 2004, at 16:29, ned.freed@mrochek.com wrote: >> ... >> >> > This admits the possibility of two conformant pieces of software >> >> > failing to interoperate, and that's not good. >> >> > >> >> >> > Now, nothing says you cannot use a naming convention of some >> sort >> >> >> to link the >> >> >> > two types in some way. But IMO they really need to be two >> >> different >> >> >> types. >> >> > >> >> >> In which case we have two different and separate namespaces, >> >> trying to >> >> >> share the same registry. This, IMHO, doesn't make sense. >> >> > >> >> > No, what we have is a single registry for specific formats and a >> >> way to >> >> > link formats that are in some way related. >> > >> >> But that link is the media type name, with the domain of >> applicability >> >> to prevent interoperability problems. This is done in RFCs 3267 and >> >> 3558, for example, and doesn't appear to have caused problems. >> > >> > Two examples where problems haven't yet arisen in a specific domain >> > doesn't mean much. There are hundreds of media types and who knows >> how >> > many domains of applicability, and the rules have to work for all of >> > them. > >> You seem to be arguing that the media types namespace cannot be shared >> between different domains of applicability unless those domains have >> the exact same framing and parameters. > > Nope. I'm arguing that a media type name needs to uniquely identify a > specific cononical format. Various encoding details, including some > aspects of framing, can of course be domain-specific. It is also > possible for an entire media type to have a single domain of > applicability, but in such cases it is still wrong to use the same > name for something different in another domain. yes, of course. >> I don't see this as realistic, >> since the entire reasoning behind specifying domains of applicability >> for media types is to allow for different framing and parameters. > > I do not regard fundamental differences in what goes in the content > as a framing detail. Again, the metric needs to be based on > interoperability. > > Look, this discussion has become pointless. I find your proposal to > use the same media type name to identify different formats in > different domains to be completely unacceptable, so much so that I > will not be party to any draft that incorporates this concept. THAT IS NOT MY PROPOSAL! What I have been arguing for is to allow the framing and framing specific parameters to vary for different domains of applicability, yet have received nothing but push back on this. Go read RFC 3267; only the framing differs. > Additionally, I see zero support being offered for this notion from > anyone else. I therefore regard the matter as closed. > > Ned > > -- Colin Perkins http://csperkins.org/ From: ned.freed at mrochek.com (ned.freed@mrochek.com) Date: Tue Jan 3 16:22:49 2006 Subject: [AVT] Re: Comments on draft-freed-media-types-reg-01.txt In-Reply-To: "Your message dated Sun, 03 Oct 2004 16:41:59 +0100" References: <413DC83F.7070807@ericsson.com> <01LEKW44X2UM00005R@mauve.mrochek.com> <413F03BF.5040407@ericsson.com> <01LEM6VYBBDE00005R@mauve.mrochek.com> <4CDCE53A-03DE-11D9-A048-000A957FC5F2@csperkins.org> <01LEQL2HYS4000005R@mauve.mrochek.com> <01LF8MCCIOM400005R@mauve.mrochek.com> <01LFATFLKFG600005R@mauve.mrochek.com> Message-ID: <01LFLB1HN9SU00005R@mauve.mrochek.com> > On 26 Sep 2004, at 06:13, ned.freed@mrochek.com wrote: > >> On 24 Sep 2004, at 16:29, ned.freed@mrochek.com wrote: > ... > >> > This admits the possibility of two conformant pieces of software > >> > failing to interoperate, and that's not good. > >> > > >> >> > Now, nothing says you cannot use a naming convention of some sort > >> >> to link the > >> >> > two types in some way. But IMO they really need to be two > >> different > >> >> types. > >> > > >> >> In which case we have two different and separate namespaces, > >> trying to > >> >> share the same registry. This, IMHO, doesn't make sense. > >> > > >> > No, what we have is a single registry for specific formats and a > >> way to > >> > link formats that are in some way related. > > > >> But that link is the media type name, with the domain of applicability > >> to prevent interoperability problems. This is done in RFCs 3267 and > >> 3558, for example, and doesn't appear to have caused problems. > > > > Two examples where problems haven't yet arisen in a specific domain > > doesn't mean much. There are hundreds of media types and who knows how > > many domains of applicability, and the rules have to work for all of > > them. > You seem to be arguing that the media types namespace cannot be shared > between different domains of applicability unless those domains have > the exact same framing and parameters. Nope. I'm arguing that a media type name needs to uniquely identify a specific cononical format. Various encoding details, including some aspects of framing, can of course be domain-specific. It is also possible for an entire media type to have a single domain of applicability, but in such cases it is still wrong to use the same name for something different in another domain. > I don't see this as realistic, > since the entire reasoning behind specifying domains of applicability > for media types is to allow for different framing and parameters. I do not regard fundamental differences in what goes in the content as a framing detail. Again, the metric needs to be based on interoperability. Look, this discussion has become pointless. I find your proposal to use the same media type name to identify different formats in different domains to be completely unacceptable, so much so that I will not be party to any draft that incorporates this concept. Additionally, I see zero support being offered for this notion from anyone else. I therefore regard the matter as closed. Ned From: csp at csperkins.org (Colin Perkins) Date: Sun Oct 3 18:11:22 2004 Subject: [AVT] Re: Comments on draft-freed-media-types-reg-01.txt In-Reply-To: <01LFATFLKFG600005R@mauve.mrochek.com> References: <413DC83F.7070807@ericsson.com> <01LEKW44X2UM00005R@mauve.mrochek.com> <413F03BF.5040407@ericsson.com> <01LEM6VYBBDE00005R@mauve.mrochek.com> <4CDCE53A-03DE-11D9-A048-000A957FC5F2@csperkins.org> <01LEQL2HYS4000005R@mauve.mrochek.com> <01LF8MCCIOM400005R@mauve.mrochek.com> <01LFATFLKFG600005R@mauve.mrochek.com> Message-ID: On 26 Sep 2004, at 06:13, ned.freed@mrochek.com wrote: >> On 24 Sep 2004, at 16:29, ned.freed@mrochek.com wrote: ... >> > This admits the possibility of two conformant pieces of software >> > failing to interoperate, and that's not good. >> > >> >> > Now, nothing says you cannot use a naming convention of some sort >> >> to link the >> >> > two types in some way. But IMO they really need to be two >> different >> >> types. >> > >> >> In which case we have two different and separate namespaces, >> trying to >> >> share the same registry. This, IMHO, doesn't make sense. >> > >> > No, what we have is a single registry for specific formats and a >> way to >> > link formats that are in some way related. > >> But that link is the media type name, with the domain of applicability >> to prevent interoperability problems. This is done in RFCs 3267 and >> 3558, for example, and doesn't appear to have caused problems. > > Two examples where problems haven't yet arisen in a specific domain > doesn't mean much. There are hundreds of media types and who knows how > many domains of applicability, and the rules have to work for all of > them. You seem to be arguing that the media types namespace cannot be shared between different domains of applicability unless those domains have the exact same framing and parameters. I don't see this as realistic, since the entire reasoning behind specifying domains of applicability for media types is to allow for different framing and parameters. Colin From: csp at csperkins.org (Colin Perkins) Date: Tue Jan 3 16:22:49 2006 Subject: [AVT] Re: Comments on draft-freed-media-types-reg-01.txt In-Reply-To: <01LFATFLKFG600005R@mauve.mrochek.com> References: <413DC83F.7070807@ericsson.com> <01LEKW44X2UM00005R@mauve.mrochek.com> <413F03BF.5040407@ericsson.com> <01LEM6VYBBDE00005R@mauve.mrochek.com> <4CDCE53A-03DE-11D9-A048-000A957FC5F2@csperkins.org> <01LEQL2HYS4000005R@mauve.mrochek.com> <01LF8MCCIOM400005R@mauve.mrochek.com> <01LFATFLKFG600005R@mauve.mrochek.com> Message-ID: On 26 Sep 2004, at 06:13, ned.freed@mrochek.com wrote: >> On 24 Sep 2004, at 16:29, ned.freed@mrochek.com wrote: ... >> > This admits the possibility of two conformant pieces of software >> > failing to interoperate, and that's not good. >> > >> >> > Now, nothing says you cannot use a naming convention of some sort >> >> to link the >> >> > two types in some way. But IMO they really need to be two >> different >> >> types. >> > >> >> In which case we have two different and separate namespaces, >> trying to >> >> share the same registry. This, IMHO, doesn't make sense. >> > >> > No, what we have is a single registry for specific formats and a >> way to >> > link formats that are in some way related. > >> But that link is the media type name, with the domain of applicability >> to prevent interoperability problems. This is done in RFCs 3267 and >> 3558, for example, and doesn't appear to have caused problems. > > Two examples where problems haven't yet arisen in a specific domain > doesn't mean much. There are hundreds of media types and who knows how > many domains of applicability, and the rules have to work for all of > them. You seem to be arguing that the media types namespace cannot be shared between different domains of applicability unless those domains have the exact same framing and parameters. I don't see this as realistic, since the entire reasoning behind specifying domains of applicability for media types is to allow for different framing and parameters. Colin From: iana at iana.org (iana@iana.org) Date: Fri Oct 1 18:36:49 2004 Subject: ConfirmSystem: iana@icann.org [[62df9086ba93e1e1]] Message-ID: <200410011636.i91Gah509635@santee.icann.org> Thank you for your message. The iana@iana.org address collects a tremendous amount of spam, and we have been forced to implement protective measures. In order to process your message we need to confirm that it came from a real email address. To confirm your message, you can either: 1) Reply to this message, without altering the subject line The "Re: " added by many mail clients is OK, but please note that this method is *not* foolproof. or 2) Visit the URL If you want to be very sure that your message gets through, do both steps above -- it does no harm to confirm more than once. For your reference, the subject of the message you sent was: "Re: Hello" and it arrived at IANA approximately at Fri Oct 1 09:36:43 2004. --------------------------------------------------------------- ConfirmSystem: iana@icann.org [[62df9086ba93e1e1]] 3 From: iana at iana.org (iana@iana.org) Date: Tue Jan 3 16:22:49 2006 Subject: ConfirmSystem: iana@icann.org [[62df9086ba93e1e1]] Message-ID: <200410011636.i91Gah509635@santee.icann.org> Thank you for your message. The iana@iana.org address collects a tremendous amount of spam, and we have been forced to implement protective measures. In order to process your message we need to confirm that it came from a real email address. To confirm your message, you can either: 1) Reply to this message, without altering the subject line The "Re: " added by many mail clients is OK, but please note that this method is *not* foolproof. or 2) Visit the URL If you want to be very sure that your message gets through, do both steps above -- it does no harm to confirm more than once. For your reference, the subject of the message you sent was: "Re: Hello" and it arrived at IANA approximately at Fri Oct 1 09:36:43 2004. --------------------------------------------------------------- ConfirmSystem: iana@icann.org [[62df9086ba93e1e1]] 3 From: iana at iana.org (iana@iana.org) Date: Fri Oct 1 16:57:51 2004 Subject: ConfirmSystem: iana@icann.org [[005e59cd98639366]] Message-ID: <200410011457.i91Evhq05876@santee.icann.org> Thank you for your message. The iana@iana.org address collects a tremendous amount of spam, and we have been forced to implement protective measures. In order to process your message we need to confirm that it came from a real email address. To confirm your message, you can either: 1) Reply to this message, without altering the subject line The "Re: " added by many mail clients is OK, but please note that this method is *not* foolproof. or 2) Visit the URL If you want to be very sure that your message gets through, do both steps above -- it does no harm to confirm more than once. For your reference, the subject of the message you sent was: "Re:" and it arrived at IANA approximately at Fri Oct 1 07:57:43 2004. --------------------------------------------------------------- ConfirmSystem: iana@icann.org [[005e59cd98639366]] 2 From: iana at iana.org (iana@iana.org) Date: Tue Jan 3 16:22:49 2006 Subject: ConfirmSystem: iana@icann.org [[005e59cd98639366]] Message-ID: <200410011457.i91Evhq05876@santee.icann.org> Thank you for your message. The iana@iana.org address collects a tremendous amount of spam, and we have been forced to implement protective measures. In order to process your message we need to confirm that it came from a real email address. To confirm your message, you can either: 1) Reply to this message, without altering the subject line The "Re: " added by many mail clients is OK, but please note that this method is *not* foolproof. or 2) Visit the URL If you want to be very sure that your message gets through, do both steps above -- it does no harm to confirm more than once. For your reference, the subject of the message you sent was: "Re:" and it arrived at IANA approximately at Fri Oct 1 07:57:43 2004. --------------------------------------------------------------- ConfirmSystem: iana@icann.org [[005e59cd98639366]] 2 From: iana at iana.org (iana@iana.org) Date: Fri Oct 1 10:22:52 2004 Subject: ConfirmSystem: iana@icann.org [[5ab5bc5a9723fa72]] Message-ID: <200410010822.i918Mhf22995@santee.icann.org> Thank you for your message. The iana@iana.org address collects a tremendous amount of spam, and we have been forced to implement protective measures. In order to process your message we need to confirm that it came from a real email address. To confirm your message, you can either: 1) Reply to this message, without altering the subject line The "Re: " added by many mail clients is OK, but please note that this method is *not* foolproof. or 2) Visit the URL If you want to be very sure that your message gets through, do both steps above -- it does no harm to confirm more than once. For your reference, the subject of the message you sent was: "Re: Hello" and it arrived at IANA approximately at Fri Oct 1 01:22:43 2004. --------------------------------------------------------------- ConfirmSystem: iana@icann.org [[5ab5bc5a9723fa72]] 1 From: iana at iana.org (iana@iana.org) Date: Tue Jan 3 16:22:49 2006 Subject: ConfirmSystem: iana@icann.org [[5ab5bc5a9723fa72]] Message-ID: <200410010822.i918Mhf22995@santee.icann.org> Thank you for your message. The iana@iana.org address collects a tremendous amount of spam, and we have been forced to implement protective measures. In order to process your message we need to confirm that it came from a real email address. To confirm your message, you can either: 1) Reply to this message, without altering the subject line The "Re: " added by many mail clients is OK, but please note that this method is *not* foolproof. or 2) Visit the URL If you want to be very sure that your message gets through, do both steps above -- it does no harm to confirm more than once. For your reference, the subject of the message you sent was: "Re: Hello" and it arrived at IANA approximately at Fri Oct 1 01:22:43 2004. --------------------------------------------------------------- ConfirmSystem: iana@icann.org [[5ab5bc5a9723fa72]] 1