Subject: ConfirmSystem: [email-masked] [[b8cff28327f85e7c]]
From: iana at iana.org ([email-masked])
Date: Fri Oct 29 13:03:59 2004

Thank you for your message.

The [email-masked] 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
        <http://confirm.icann.org/?s=b8cff28327f85e7c&l=[email-masked]>

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: [email-masked] [[b8cff28327f85e7c]]
4

From: iana at iana.org ([email-masked])
Date: Tue Jan  3 16:22:51 2006
Subject: ConfirmSystem: [email-masked] [[b8cff28327f85e7c]]
Message-ID: <[email-masked]>

Thank you for your message.

The [email-masked] 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
        <http://confirm.icann.org/?s=b8cff28327f85e7c&l=[email-masked]>

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: [email-masked] [[b8cff28327f85e7c]]
4

From: iana at iana.org ([email-masked])
Date: Fri Oct 29 12:37:45 2004
Subject: ConfirmSystem: [email-masked] [[c1bcd9ea4cb39927]]
Message-ID: <[email-masked]>

Thank you for your message.

The [email-masked] 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
        <http://confirm.icann.org/?s=c1bcd9ea4cb39927&l=[email-masked]>

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: [email-masked] [[c1bcd9ea4cb39927]]
3

From: iana at iana.org ([email-masked])
Date: Tue Jan  3 16:22:51 2006
Subject: ConfirmSystem: [email-masked] [[c1bcd9ea4cb39927]]
Message-ID: <[email-masked]>

Thank you for your message.

The [email-masked] 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
        <http://confirm.icann.org/?s=c1bcd9ea4cb39927&l=[email-masked]>

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: [email-masked] [[c1bcd9ea4cb39927]]
3

From: iana at iana.org ([email-masked])
Date: Fri Oct 29 12:27:46 2004
Subject: ConfirmSystem: [email-masked] [[83f3d701c0925134]]
Message-ID: <[email-masked]>

Thank you for your message.

The [email-masked] 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
        <http://confirm.icann.org/?s=83f3d701c0925134&l=[email-masked]>

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: [email-masked] [[83f3d701c0925134]]
2

From: iana at iana.org ([email-masked])
Date: Tue Jan  3 16:22:51 2006
Subject: ConfirmSystem: [email-masked] [[83f3d701c0925134]]
Message-ID: <[email-masked]>

Thank you for your message.

The [email-masked] 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
        <http://confirm.icann.org/?s=83f3d701c0925134&l=[email-masked]>

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: [email-masked] [[83f3d701c0925134]]
2

From: iana at iana.org ([email-masked])
Date: Tue Jan  3 16:22:51 2006
Subject: ConfirmSystem: [email-masked] [[f27213adb9130923]]
Message-ID: <[email-masked]>

Thank you for your message.

The [email-masked] 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
        <http://confirm.icann.org/?s=f27213adb9130923&l=[email-masked]>

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: [email-masked] [[f27213adb9130923]]
1

From: ned.freed at mrochek.com ([email-masked])
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" <[email-masked]>
References: <[email-masked]> <[email-masked]>
Message-ID: <[email-masked]>

> 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 [email-masked]  Fri Oct 29 10:05:37 2004
From: iana at iana.org ([email-masked])
Date: Fri Oct 29 10:05:47 2004
Subject: ConfirmSystem: [email-masked] [[f27213adb9130923]]
Message-ID: <[email-masked]>

Thank you for your message.

The [email-masked] 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
        <http://confirm.icann.org/?s=f27213adb9130923&l=[email-masked]>

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: [email-masked] [[f27213adb9130923]]
1

From: ned.freed at mrochek.com ([email-masked])
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" <[email-masked]>
References: <[email-masked]> <[email-masked]>
Message-ID: <[email-masked]>

> 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: <[email-masked]>
References: <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]>
Message-ID: <[email-masked]>

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: <[email-masked]>
References: <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]>
Message-ID: <[email-masked]>

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
  [email-masked]
>From [email-masked]  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: <[email-masked]>
References: <[email-masked]>
	<[email-masked]>
	<[email-masked]>
	<[email-masked]>
	<[email-masked]>
	<[email-masked]>
	<[email-masked]>
	<[email-masked]>
	<[email-masked]>
	<[email-masked]>
	<[email-masked]>
Message-ID: <[email-masked]>

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: <[email-masked]>
References: <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]>
Message-ID: <[email-masked]>

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
  [email-masked]

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: <[email-masked]>
References: <[email-masked]>	<[email-masked]>	<[email-masked]>	<[email-masked]>	<[email-masked]>	<[email-masked]>	<[email-masked]>	<[email-masked]>	<[email-masked]>	<[email-masked]>	<[email-masked]>	<[email-masked]>	<[email-masked]>	<[email-masked]> <[email-masked]> <[email-masked]>
Message-ID: <[email-masked]>

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: [email-masked]

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: <[email-masked]>
References: <[email-masked]>
Message-ID: <[email-masked]>

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: [email-masked]

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: <[email-masked]>
References: <[email-masked]> <[email-masked]> <[email-masked]>
Message-ID: <[email-masked]>

On Thu October 21 2004 11:47, [email-masked] 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: <[email-masked]>
References: <[email-masked]>	<[email-masked]>	<[email-masked]>	<[email-masked]>	<[email-masked]>	<[email-masked]>	<[email-masked]>	<[email-masked]>	<[email-masked]>	<[email-masked]>	<[email-masked]>	<[email-masked]>	<[email-masked]>	<[email-masked]> <[email-masked]>
Message-ID: <[email-masked]>

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: [email-masked]

From: ned.freed at mrochek.com ([email-masked])
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" <[email-masked]>
References: <[email-masked]> <[email-masked]> <[email-masked]>
Message-ID: <[email-masked]>

> On Wed October 20 2004 00:02, [email-masked] 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 [email-masked]  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: <[email-masked]>
References: <[email-masked]>	<[email-masked]>	<[email-masked]>	<[email-masked]>	<[email-masked]>	<[email-masked]>	<[email-masked]>	<[email-masked]>	<[email-masked]>	<[email-masked]>	<[email-masked]>	<[email-masked]>	<[email-masked]>	<[email-masked]>
	<[email-masked]>
Message-ID: <[email-masked]>

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: [email-masked]
>From [email-masked]  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: <[email-masked]>
References: <[email-masked]>
	<[email-masked]>
	<[email-masked]>
Message-ID: <[email-masked]>

On Thu October 21 2004 11:47, [email-masked] 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 [email-masked]  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: <[email-masked]>
References: <[email-masked]>
Message-ID: <[email-masked]>

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: [email-masked]
>From [email-masked]  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: <[email-masked]>
References: <[email-masked]>	<[email-masked]>	<[email-masked]>	<[email-masked]>	<[email-masked]>	<[email-masked]>	<[email-masked]>	<[email-masked]>	<[email-masked]>	<[email-masked]>	<[email-masked]>	<[email-masked]>	<[email-masked]>	<[email-masked]>
	<[email-masked]>
	<[email-masked]>
Message-ID: <[email-masked]>

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: [email-masked]

From: ned.freed at mrochek.com ([email-masked])
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" <[email-masked]>
References: <[email-masked]> <[email-masked]> <[email-masked]>
Message-ID: <[email-masked]>

> On Wed October 20 2004 00:02, [email-masked] 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: <[email-masked]>
References: <[email-masked]> <[email-masked]> <[email-masked]>
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: <[email-masked]>
References: <[email-masked]> <[email-masked]>
Message-ID: <[email-masked]>

On Wed October 20 2004 00:02, [email-masked] 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: <[email-masked]> <6.0.0.20.2.20041019120002.05e47b00@localhost>
Message-ID: <[email-masked]>

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 ([email-masked])
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" <[email-masked]>
References: <[email-masked]>
Message-ID: <[email-masked]>

> [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 [email-masked]  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: <[email-masked]>
	<6.0.0.20.2.20041019120002.05e47b00@localhost>
Message-ID: <[email-masked]>

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 [email-masked]  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: <[email-masked]>
References: <[email-masked]>
	<[email-masked]>
Message-ID: <[email-masked]>

On Wed October 20 2004 00:02, [email-masked] 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 [email-masked]  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: <[email-masked]>
References: <[email-masked]>
	<[email-masked]>
	<[email-masked]>
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 ([email-masked])
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" <[email-masked]>
References: <[email-masked]>
Message-ID: <[email-masked]>

> [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: <[email-masked]>
References: <[email-masked]>
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: <[email-masked]>
References: <[email-masked]>
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 ([email-masked])
Date: Mon Oct 18 17:59:27 2004
Subject: ConfirmSystem: [email-masked] [[a92b5906721e8790]]
Message-ID: <[email-masked]>

Thank you for your message.

The [email-masked] 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
        <http://confirm.icann.org/?s=a92b5906721e8790&l=[email-masked]>

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: [email-masked] [[a92b5906721e8790]]
1

From: iana at iana.org ([email-masked])
Date: Tue Jan  3 16:22:50 2006
Subject: ConfirmSystem: [email-masked] [[a92b5906721e8790]]
Message-ID: <[email-masked]>

Thank you for your message.

The [email-masked] 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
        <http://confirm.icann.org/?s=a92b5906721e8790&l=[email-masked]>

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: [email-masked] [[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: <[email-masked]>

[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: <[email-masked]>

[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: <[email-masked]>
References: <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]>
Message-ID: <[email-masked]>

On 10 Oct 2004, at 01:38, [email-masked] wrote:

>> On 9 Oct 2004, at 17:27, [email-masked] 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
>> 	<ietf-types at iana.org> 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 "[email-masked]" 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 ([email-masked])
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" <[email-masked]>
References: <[email-masked]> <[email-masked]> <[email-masked]>
Message-ID: <[email-masked]>

> On 9 Oct 2004, at 17:27, [email-masked] 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
> 	<ietf-types at iana.org> 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 "[email-masked]" 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 [email-masked]  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: <[email-masked]>
References: <[email-masked]>
	<[email-masked]>
	<[email-masked]>
	<[email-masked]>
Message-ID: <[email-masked]>

On 10 Oct 2004, at 01:38, [email-masked] wrote:

>> On 9 Oct 2004, at 17:27, [email-masked] 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
>> 	<ietf-types at iana.org> 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 "[email-masked]" 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 ([email-masked])
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" <[email-masked]>
References: <[email-masked]> <[email-masked]> <[email-masked]>
Message-ID: <[email-masked]>

> On 9 Oct 2004, at 17:27, [email-masked] 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
> 	<ietf-types at iana.org> 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 "[email-masked]" 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: <[email-masked]>
References: <[email-masked]> <[email-masked]>
Message-ID: <[email-masked]>

On 9 Oct 2004, at 17:27, [email-masked] 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
	<ietf-types at iana.org> 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 "[email-masked]" 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 ([email-masked])
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" <[email-masked]>
References: <[email-masked]>
Message-ID: <[email-masked]>

> > > 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 [email-masked]  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: <[email-masked]>
References: <[email-masked]>
	<[email-masked]>
Message-ID: <[email-masked]>

On 9 Oct 2004, at 17:27, [email-masked] 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
	<ietf-types at iana.org> 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 "[email-masked]" 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 ([email-masked])
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" <[email-masked]>
References: <[email-masked]>
Message-ID: <[email-masked]>

> > > 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: <[email-masked]>

--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: <[email-masked]>

--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: <[email-masked]>

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] 
> 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" <[email-masked]>
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 [email-masked]  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: <[email-masked]>
References: <[email-masked]>
Message-ID: <[email-masked]>

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: <[email-masked]>

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] 
> 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" <[email-masked]>
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 [email-masked]  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: <[email-masked]>
References: <[email-masked]>
Message-ID: <[email-masked]>

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: <[email-masked]>

Hi 

Thanks for the answer.

> -----Original Message-----
> From: Martin Duerst [mailto:[email-masked]] 
> 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:[email-masked]]
> > > 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, [email-masked]
> > >         Yoshinori Matsui, [email-masked]
> > >         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: [email-masked]
> > > 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: <[email-masked]>

Hi 

Thanks for the answer.

> -----Original Message-----
> From: Martin Duerst [mailto:[email-masked]] 
> 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:[email-masked]]
> > > 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, [email-masked]
> > >         Yoshinori Matsui, [email-masked]
> > >         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: [email-masked]
> > > 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: <[email-masked] .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:[email-masked]]
> > 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, [email-masked]
> >         Yoshinori Matsui, [email-masked]
> >         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: [email-masked]
> > 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: <[email-masked]>

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:[email-masked]] 
> 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, [email-masked] 
>         Yoshinori Matsui, [email-masked] 
>         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: [email-masked]
> 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 [email-masked]  Fri Oct  8 04:43:11 2004
From: ned.freed at mrochek.com ([email-masked])
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"
	<[email-masked]>
Message-ID: <[email-masked]>

> 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 [email-masked]  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: <[email-masked] .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:[email-masked]]
> > 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, [email-masked]
> >         Yoshinori Matsui, [email-masked]
> >         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: [email-masked]
> > 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: <[email-masked]>

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:[email-masked]] 
> 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, [email-masked] 
>         Yoshinori Matsui, [email-masked] 
>         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: [email-masked]
> 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 [email-masked]  Fri Oct  8 04:43:11 2004
From: ned.freed at mrochek.com ([email-masked])
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"
	<[email-masked]>
Message-ID: <[email-masked]>

> 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: <[email-masked]>

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: [email-masked] 
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
		<wsdl:description>, 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 <[email-masked]>

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: <[email-masked]>

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: [email-masked] 
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
		<wsdl:description>, 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 <[email-masked]>

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: <[email-masked]>
References: <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]>
Message-ID: <[email-masked]>

On 3 Oct 2004, at 23:40, [email-masked] 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 ([email-masked])
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" <[email-masked]>
References: <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]>
Message-ID: <[email-masked]>

> > > 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 [email-masked]  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: <[email-masked]>
References: <[email-masked]>
	<[email-masked]>
	<[email-masked]>
	<[email-masked]>
	<[email-masked]>
	<[email-masked]>
	<[email-masked]>
	<[email-masked]>
	<[email-masked]>
	<[email-masked]>
	<[email-masked]>
	<[email-masked]>
	<[email-masked]>
	<[email-masked]>
Message-ID: <[email-masked]>

On 3 Oct 2004, at 23:40, [email-masked] 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 ([email-masked])
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" <[email-masked]>
References: <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]>
Message-ID: <[email-masked]>

> > > 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: <[email-masked]>
References: <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]>
Message-ID: <[email-masked]>

On 3 Oct 2004, at 18:22, [email-masked] wrote:
>> On 26 Sep 2004, at 06:13, [email-masked] wrote:
>> >> On 24 Sep 2004, at 16:29, [email-masked] 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 ([email-masked])
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" <[email-masked]>
References: <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]>
Message-ID: <[email-masked]>

> On 26 Sep 2004, at 06:13, [email-masked] wrote:
> >> On 24 Sep 2004, at 16:29, [email-masked] 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 [email-masked]  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: <[email-masked]>
References: <[email-masked]>
	<[email-masked]>
	<[email-masked]>
	<[email-masked]>
	<[email-masked]>
	<[email-masked]>
	<[email-masked]>
	<[email-masked]>
	<[email-masked]>
	<[email-masked]>
	<[email-masked]>
	<[email-masked]>
Message-ID: <[email-masked]>

On 3 Oct 2004, at 18:22, [email-masked] wrote:
>> On 26 Sep 2004, at 06:13, [email-masked] wrote:
>> >> On 24 Sep 2004, at 16:29, [email-masked] 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 ([email-masked])
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" <[email-masked]>
References: <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]>
Message-ID: <[email-masked]>

> On 26 Sep 2004, at 06:13, [email-masked] wrote:
> >> On 24 Sep 2004, at 16:29, [email-masked] 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: <[email-masked]>
References: <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]>
Message-ID: <[email-masked]>

On 26 Sep 2004, at 06:13, [email-masked] wrote:
>> On 24 Sep 2004, at 16:29, [email-masked] 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: <[email-masked]>
References: <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]>
Message-ID: <[email-masked]>

On 26 Sep 2004, at 06:13, [email-masked] wrote:
>> On 24 Sep 2004, at 16:29, [email-masked] 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 ([email-masked])
Date: Fri Oct  1 18:36:49 2004
Subject: ConfirmSystem: [email-masked] [[62df9086ba93e1e1]]
Message-ID: <[email-masked]>

Thank you for your message.

The [email-masked] 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
        <http://confirm.icann.org/?s=62df9086ba93e1e1&l=[email-masked]>

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: [email-masked] [[62df9086ba93e1e1]]
3

From: iana at iana.org ([email-masked])
Date: Tue Jan  3 16:22:49 2006
Subject: ConfirmSystem: [email-masked] [[62df9086ba93e1e1]]
Message-ID: <[email-masked]>

Thank you for your message.

The [email-masked] 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
        <http://confirm.icann.org/?s=62df9086ba93e1e1&l=[email-masked]>

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: [email-masked] [[62df9086ba93e1e1]]
3

From: iana at iana.org ([email-masked])
Date: Fri Oct  1 16:57:51 2004
Subject: ConfirmSystem: [email-masked] [[005e59cd98639366]]
Message-ID: <[email-masked]>

Thank you for your message.

The [email-masked] 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
        <http://confirm.icann.org/?s=005e59cd98639366&l=[email-masked]>

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: [email-masked] [[005e59cd98639366]]
2

From: iana at iana.org ([email-masked])
Date: Tue Jan  3 16:22:49 2006
Subject: ConfirmSystem: [email-masked] [[005e59cd98639366]]
Message-ID: <[email-masked]>

Thank you for your message.

The [email-masked] 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
        <http://confirm.icann.org/?s=005e59cd98639366&l=[email-masked]>

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: [email-masked] [[005e59cd98639366]]
2

From: iana at iana.org ([email-masked])
Date: Fri Oct  1 10:22:52 2004
Subject: ConfirmSystem: [email-masked] [[5ab5bc5a9723fa72]]
Message-ID: <[email-masked]>

Thank you for your message.

The [email-masked] 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
        <http://confirm.icann.org/?s=5ab5bc5a9723fa72&l=[email-masked]>

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: [email-masked] [[5ab5bc5a9723fa72]]
1

From: iana at iana.org ([email-masked])
Date: Tue Jan  3 16:22:49 2006
Subject: ConfirmSystem: [email-masked] [[5ab5bc5a9723fa72]]
Message-ID: <[email-masked]>

Thank you for your message.

The [email-masked] 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
        <http://confirm.icann.org/?s=5ab5bc5a9723fa72&l=[email-masked]>

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: [email-masked] [[5ab5bc5a9723fa72]]
1