Subject: Input Needed: Media Type Registry Structure
From: derhoermi at gmx.net (Bjoern Hoehrmann)
Date: Fri Jun 24 02:09:51 2005

* Scott Hollenbeck wrote:
>Follow-up discussion within the IESG has prompted this query.  The templates
>in draft-hoehrmann-script-types use the "Intended Usage" field in the
>templates to note that two of the types are obsolete.  The reviewer is
>suggesting that this status be displayed more obviously at a higher level
>within the registry.

FWIW, <http://www.ietf.org/rfc/rfc2048.txt>, section 2.7 states:

  Media type registrations may not be deleted; media types which are
  no longer believed appropriate for use can be declared OBSOLETE by
  a change to their "intended use" field; such media types will be
  clearly marked in the lists published by IANA.

application/vnd.informix-visionary and application/iges (see the model/
iges registration) seem to be the only types that should be marked
obsolete in the registry and for the former the registration notes:
http://www.iana.org/assignments/media-types/application/vnd.informix-visionary

  Note: This registration is obsolete.  The registration 
  of vnd.visionary replaces this registration.
  Note posted: 05 February 2002

There does not seem to be a similar note for application/iges and the
lists at http://www.iana.org/assignments/media-types/application/ etc.
do not mark these types as obsolete.
-- 
Bj?rn H?hrmann ? mailto:[email-masked] ? http://bjoern.hoehrmann.de
Weinh. Str. 22 ? Telefon: +49(0)621/4309674 ? http://www.bjoernsworld.de
68309 Mannheim ? PGP Pub. KeyID: 0xA4357E78 ? http://www.websitedev.de/ 
>From [email-masked]  Wed Jun 29 09:50:38 2005
From: magnus.westerlund at ericsson.com (Magnus Westerlund)
Date: Wed Jun 29 09:50:47 2005
Subject: Request to review Media type registration in
	draft-ietf-avt-rtp-ac3-07.txt
Message-ID: <[email-masked]>

Hi,

Please review the media type registration for the AC-3 RTP payload 
format before 20th of July.
http://ietf.levkowetz.com/drafts/avt/rtp-ac3/draft-ietf-avt-rtp-ac3-07.txt

Thanks

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 (Ned Freed)
Date: Thu Jun 23 19:50:26 2005
Subject: Input Needed: Media Type Registry Structure
In-Reply-To: "Your message dated Thu, 23 Jun 2005 10:04:21 -0700" <[email-masked]>
References: <[email-masked]> <[email-masked]>
Message-ID: <[email-masked]>

> I think we should separate out questions about the schema --
> whether the "Intended Usage" field being "obsolete" means
> that the entire registration is obsolete -- from questions about
> the presentation -- how IANA media type registry information
> is made available to the community, what it looks like, what
> other tools are available for finding, reading, marking,
> downloading, interpreting.

> I suggest that the latter is more of a topic for "IETF
> tools" discussions ([email-masked]), and that
> we should look generally at making the IANA web pages
> more useful for its various audiences.

I could not agree more. Putting this sort of thing in registration
specification is entirely inappropriate IMO, if for no other reason than these
presentation issues tend to apply to mutiple, and maybe even most, IANA
registries.

There are all sorts of improvements I could envision making to many of the IANA
registries, including but not limited to:

(1) Better layout and use of things like color indicators. (The fact that
    these are of no use to some folks doesn't mean they are of no use
    to everyone.)

(2) Nail down the URL used to locate various things (this is a longstanding
    W3C request, and while I am sympathetic to the IETF view that not
    everything is a URL, there are real benefits to having some of this
    stuff in fixed locations.)

(3) Dare I suggest an ATOM/RSS feed where all IANA updates get posted?
    Perhaps even one where incoming requests get sent as well?

> As for the former, I think that using the "Intended Usage"
> field in the registration schema to note registrations
> that are "Obsolete" is a reasonable choice.

Agreed.

				Ned
>From [email-masked]  Thu Jun 23 19:50:22 2005
From: chris at w3.org (Chris Lilley)
Date: Thu Jun 23 19:50:36 2005
Subject: Input Needed: Media Type Registry Structure
In-Reply-To: <[email-masked]>
References: <[email-masked]>
	<[email-masked]> <[email-masked]>
Message-ID: <[email-masked]>

On Thursday, June 23, 2005, 5:40:46 PM, Bruce wrote:

BL> On Thu June 23 2005 10:46, Chris Lilley wrote:

>> It could be as simple as putting a class attribute in the HTML and
>> styling common, limited and obsolete in different colors.

BL> While I agree with most of Chris' other remarks, I note that color
BL> variations encoded in HTML (particularly if more complex methods
BL> such as style sheets are used) would be particularly difficult for
BL> readers with certain visual impairments.

Which was why I suggested using a class attribute and styling, rather
than say a font tag to set the color directly. This allows restyling,
alternate style sheets, automatic extraction and so forth.

BL> I'd prefer a field that indicates status explicitly in text.

Yes, that would work too, and probably be preferable.

BL> I'd rather not have to dig through actual registrations, since it
BL> is conceivable that a registration might change after initial
BL> registration (I believe that there are several such proposals in
BL> discussion).

Good point.

-- 
 Chris Lilley                    mailto:[email-masked]
 Chair, W3C SVG Working Group
 W3C Graphics Activity Lead

From: blilly at erols.com (Bruce Lilly)
Date: Thu Jun 23 17:41:06 2005
Subject: Input Needed: Media Type Registry Structure
In-Reply-To: <[email-masked]>
References: <[email-masked]> <[email-masked]>
Message-ID: <[email-masked]>

On Thu June 23 2005 10:46, Chris Lilley wrote:

> It could be as simple as putting a class attribute in the HTML and
> styling common, limited and obsolete in different colors.

While I agree with most of Chris' other remarks, I note that color
variations encoded in HTML (particularly if more complex methods
such as style sheets are used) would be particularly difficult for
readers with certain visual impairments.

I'd prefer a field that indicates status explicitly in text.

I'd rather not have to dig through actual registrations, since it
is conceivable that a registration might change after initial
registration (I believe that there are several such proposals in
discussion).
>From [email-masked]  Thu Jun 23 19:04:21 2005
From: LMM at acm.org (Larry Masinter)
Date: Thu Jun 23 19:04:51 2005
Subject: Input Needed: Media Type Registry Structure
In-Reply-To: <[email-masked]>
Message-ID: <[email-masked]>

I think we should separate out questions about the schema --
whether the "Intended Usage" field being "obsolete" means
that the entire registration is obsolete -- from questions about
the presentation -- how IANA media type registry information
is made available to the community, what it looks like, what
other tools are available for finding, reading, marking,
downloading, interpreting.

I suggest that the latter is more of a topic for "IETF
tools" discussions ([email-masked]), and that
we should look generally at making the IANA web pages
more useful for its various audiences.  

As for the former, I think that using the "Intended Usage"
field in the registration schema to note registrations
that are "Obsolete" is a reasonable choice.

Larry 

From: chris at w3.org (Chris Lilley)
Date: Thu Jun 23 16:46:30 2005
Subject: Input Needed: Media Type Registry Structure
In-Reply-To: <[email-masked]>
References: <[email-masked]>
Message-ID: <[email-masked]>

On Thursday, June 23, 2005, 2:22:48 PM, Scott wrote:

SH> Community input needed:

SH> During IESG evaluation of draft-hoehrmann-script-types, one of the General
SH> Area reviewers provided this comment:

SH> "IANA seems to have figured out that the types to be registered are MIME
SH> media types but probably should be told how to indicate that the two text/
SH> registrations are obsolete, or at least that it is important to mark these
SH> registrations as obsolete in the registry (unless the OBSOLETE intended
SH> usage field in the registration suffices, but marking the registry entry
SH> will be more effective)."

Yes, it would be more effective, but I can live with either marking it
or leaving people to read the registration documents.

SH> Follow-up discussion within the IESG has prompted this query.  The templates
SH> in draft-hoehrmann-script-types use the "Intended Usage" field in the
SH> templates to note that two of the types are obsolete.  The reviewer is
SH> suggesting that this status be displayed more obviously at a higher level
SH> within the registry.

I agree that this information is not obvious when looking at the
registry, and is useful.

SH> This isn't exactly an issue for the document being reviewed, but it might be
SH> an issue for the structure of the registry.  Should the registry structure
SH> be changed to display the status of obsolete (or any other) types more
SH> prominently?  If so, we might need a new document or a revision to
SH> draft-freed-media-type-reg to describe whatever changes are needed.

It could be as simple as putting a class attribute in the HTML and
styling common, limited and obsolete in different colors.

-- 
 Chris Lilley                    mailto:[email-masked]
 Chair, W3C SVG Working Group
 W3C Graphics Activity Lead

From: csp at csperkins.org (Colin Perkins)
Date: Tue Jun 14 13:32:19 2005
Subject: Fwd: [AVT] I-D ACTION:draft-ietf-avt-rtp-3gpp-timed-text-15.txt
References: <[email-masked]>
Message-ID: <[email-masked]>

The AVT working group requests a media types review for the updated  
3GPP timed text draft. There was much recent discussion on this  
subject, and this draft is intended to address the concerns expressed.

Colin
(AVT co-chair)

Begin forwarded message:
> From: "Jose Rey" <[email-masked]>
> Date: 14 June 2005 08:33:16 BDT
> To: <[email-masked]>
> Subject: FW: [AVT] I-D ACTION:draft-ietf-avt-rtp-3gpp-timed- 
> text-15.txt
>
> Hi all,
>
> A new version is out. This update includes some very minor  
> editorial changes as well as those changes agreed during the Media  
> Type discussions (below.)
>
> Looking forward to WGLC!
>
> Jos?
>
> ---------------------------------------------------------------------- 
> -----
>
> - Section 2.1, p.4: remove paragraph that causes confusion
>
> REMOVED:
>
>     The scope of the 3GPP PSS specification (in the following  
> referred to
>     as PSS) includes both downloading and streaming of multimedia  
> content
>     over 3G packet-switched networks.  PSS adopts multimedia codecs  
> such
>     as MPEG-4 Visual [22], AMR wide-band [23] or MPEG-4 AAC [24] for
>     encoding content.  Other protocols like RTSP [15] for session  
> set-up
>     and control, or SMIL [9] for handling presentation layouts.  For
>     transport, HTTP over TCP is used for downloading and RTP for
>     streaming.
>
>
> - Section 8:
> OLD:
>     The media subtype for the 3GPP Timed Text codec is allocated  
> from the
>     IETF tree.  The top-level media type under which this payload  
> format
>     is registered is 'text'.
>
>     The receiver MUST ignore any unrecognized parameter.
>
>     Media type: text
>
> NEW:
>     The media subtype for the 3GPP Timed Text codec is allocated  
> from the
>     standards tree.  The top-level media type under which this payload
>     format is registered is 'video'. This registration is done  
> using the
>     template defined in [31] and following RFC 3555 [30].
>
>     The receiver MUST ignore any unrecognized parameter.
>
>     Media type: video
>
>
> OLD:
>     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.
>
>
> NEW:
>     Encoding considerations:
>
>          This media type is framed (see section 4.8 in [31]) and  
> partially contains binary data.
>
>     Restrictions on usage:
>
>        This media type depends on RTP framing, and hence is only  
> defined for
>             transfer via RTP [RFC 3550]. Transport within other  
> framing protocols
>             is not defined at this time.
>
> OLD:
>     Interoperability considerations:
>
>          The 3GPP Timed Text media format and its storage 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
>          timed text media format in a backwards-compatible way,  
> e.g. new
>          modifier boxes or extensions to the sample descriptions.  The
>          payload format defined in RFCXXXX allows for such extensions.
>          For future 3GPP Releases of the Timed Text Format, the  
> parameter
>          "sver" is used to identify the exact specification used.
>
> NEW:
>     Interoperability considerations:
>
>          The 3GPP Timed Text media format and its file storage is
>          specified in Release 6 of 3GPP TS 26.245 "Transparent end- 
> to-end
>          packet switched streaming service (PSS); Timed Text Format
>          (Release 6)".  Note also that 3GPP may in future Releases
>          specify extensions or updates to the timed text media  
> format in
>          a backwards-compatible way, e.g. new modifier boxes or
>          extensions to the sample descriptions.  The payload format
>          defined in RFCXXXX allows for such extensions.  For future  
> 3GPP
>          Releases of the Timed Text Format, the parameter "sver" is  
> used
>          to identify the exact specification used.
>
>          The defined storage format for 3GPP Timed Text format is  
> the 3GPP File
>        Format (3GP) [32].  3GP files may be transferred using the  
> media type
>          video/3gpp as registered by RFC 3839 [33].  The 3GPP File  
> Format is a container
>          file that may contain, e.g., audio and video which may be  
> synchronized with the
>          3GPP Timed Text.
>
>
> - Section 12.2: New informative references
>
> REMOVED:
>
> References 22, 23 and 24
>
> NEW:
>
>     [30] Casner, S. and P. Hoschka, "MIME Type Registration of RTP
>          Payload Formats", RFC 3555, July 2003.
>
>     [31] Freed, N. and J. Klensin, "Media Type Specifications and
>          Registration Procedures", draft-freed-media-type-reg-04,
>          April 2005.
>
>     [32] Transparent end-to-end packet switched streaming service  
> (PSS);
>          3GPP file format (3GP) (Release 6), TS 26.244 V6.3. March  
> 2005.
>
>     [33] Castagno, R. and D. Singer, "MIME Type Registrations for 3rd
>          Generation Partnership Project (3GPP) Multimedia files",
>          RFC 3839, July 2004.
>
> --
>> -----Original Message-----
>> From: [email-masked] [mailto:[email-masked]] On
>> Behalf Of [email-masked]
>> Sent: Monday, June 13, 2005 9:37 PM
>> To: [email-masked]
>> Cc: [email-masked]
>> Subject: [AVT] I-D ACTION:draft-ietf-avt-rtp-3gpp-timed-text-15.txt
>>
>> A New Internet-Draft is available from the on-line
>> Internet-Drafts directories.
>> This draft is a work item of the Audio/Video Transport
>> Working Group of the IETF.
>>
>>     Title        : RTP Payload Format for 3GPP Timed Text
>>     Author(s)    : J. Rey, Y. Matsui
>>     Filename    : draft-ietf-avt-rtp-3gpp-timed-text-15.txt
>>     Pages        : 59
>>     Date        : 2005-6-13
>>
>> This document specifies an RTP payload format for the transmission of
>>    3GPP (3rd Generation Partnership Project) timed text.  3GPP timed
>>    text is a time-lined decorated text media format with
>> defined storage
>>    in a 3GP file.  Timed Text can be synchronized with audio/video
>>    contents and used in application such as captioning, titling and
>>    multimedia presentations.  In the following sections the
>> problems of
>>    streaming timed text are addressed and a payload format
>> for streaming
>>    3GPP timed text over RTP is specified.
>>
>> A URL for this Internet-Draft is:
>> http://www.ietf.org/internet-drafts/draft-ietf-avt-rtp-3gpp-timed- 
>> text-15.txt
>
>From [email-masked]  Thu Jun 23 14:22:48 2005
From: sah at 428cobrajet.net (Scott Hollenbeck)
Date: Thu Jun 23 14:23:15 2005
Subject: Input Needed: Media Type Registry Structure
Message-ID: <[email-masked]>

Community input needed:

During IESG evaluation of draft-hoehrmann-script-types, one of the General
Area reviewers provided this comment:

"IANA seems to have figured out that the types to be registered are MIME
media types but probably should be told how to indicate that the two text/
registrations are obsolete, or at least that it is important to mark these
registrations as obsolete in the registry (unless the OBSOLETE intended
usage field in the registration suffices, but marking the registry entry
will be more effective)."

Follow-up discussion within the IESG has prompted this query.  The templates
in draft-hoehrmann-script-types use the "Intended Usage" field in the
templates to note that two of the types are obsolete.  The reviewer is
suggesting that this status be displayed more obviously at a higher level
within the registry.

This isn't exactly an issue for the document being reviewed, but it might be
an issue for the structure of the registry.  Should the registry structure
be changed to display the status of obsolete (or any other) types more
prominently?  If so, we might need a new document or a revision to
draft-freed-media-type-reg to describe whatever changes are needed.

-Scott-

From: murata at hokkaido.email.ne.jp (MURATA Makoto)
Date: Sun Jun 12 00:08:25 2005
Subject: Registration of MIME media type application/rnc
In-Reply-To: <[email-masked]>
References: <[email-masked]> <[email-masked]>
Message-ID: <[email-masked]>

MURATA> Chris> Attributes on media types are generally problematic, and to be avoided.
MURATA> Chris> Duplicating information in the document is also to be avoided, as is any
MURATA> Chris> mechanism that requires parsing the document before serving it.
MURATA> 
MURATA> This is silly, since it requires content sniffing.  However, XML
MURATA> documents can always be parsed.  This is a big difference.

I am afraid I was not clear.  I was trying to respond to the following
comment.

> If a Media Type is not needed for RNG in the xml format, why is one
> needed for the compact syntax? Application/octet-stream would convey
> just as little information "this is not xml".

Cheers,
-- 
MURATA Makoto <[email-masked]>

From: murata at hokkaido.email.ne.jp (MURATA Makoto)
Date: Fri Jun 10 01:04:41 2005
Subject: The role of media types for XML content
In-Reply-To: <[email-masked]>
References: <[email-masked]> <[email-masked]>
Message-ID: <[email-masked]>

Mark,

(I do think that this topic belongs to the ietf-xml-mime ML.  I am 
ccing to the ietf-types but will not do so any more.)

I think that you have presented some requirements which are not
addressed by any of the existing mechanisms. 

> But I believe the security problem is just one manifestation of the
> layering problem inherrent in using intrinsic dispatch (of which XML
> namespace dispatch in one kind); that an extrinsic dispatch mechanism,
> like media types, cleanly separates the "what" - the raw data - from
> the "how" - the semantics with which that data is to be interpreted.

I do not think that media types are good enough for multi-namespace 
documents and that W3C should develop something different.  Although 
your example can be addressed by specialized media types, my example 
(schemas embedded within XHTML are referenced by XPointer) cannot.

Cheers,

-- 
MURATA Makoto <[email-masked]>

From: murata at hokkaido.email.ne.jp (MURATA Makoto)
Date: Fri Jun 10 00:54:59 2005
Subject: Registration of MIME media type application/rnc
In-Reply-To: <[email-masked]>
References: <[email-masked]> <[email-masked]>
Message-ID: <[email-masked]>

Larry,

Larry> > First, if you read the archive of the ietf-xml-mime ML, you will 
Larry> > find two camps.  One camp (most notably Larry Masinter) believes that 
Larry> > media types are never good enough for negotiation, dispatching, or 
Larry> > avoiding retrieval and thus specialized media types should be avoided 
Larry> > wherever possible.
Larry> 
Larry> I'm not too happy with this as a characterization of my
Larry> position. I do find myself arguing against media
Larry> type registrations, but not because they are _never_
Larry> good enough for negotiation, dispatching, or avoiding retrieval.
Larry> They're usually not enough for negotiation or avoiding
Larry> retrieval, and have a careful limited utility in dispatching.

Thanks for making your point clear and sorry for my inexact summary.

Larry> I also dislike short, abbreviated media type registrations
Larry> (like "application/rnc") when a reasonably longer ones would
Larry> help someone unfamiliar understand what it was
Larry> (like "application/relax-ng-schema").

I am happy to change the name and will do so in the next 
stage.

Cheers,

Makoto
-- 
MURATA Makoto <[email-masked]>

From: distobj at acm.org (Mark Baker)
Date: Thu Jun  9 17:12:02 2005
Subject: The role of media types for XML content
In-Reply-To: <[email-masked]>
References: <[email-masked]> <[email-masked]> <[email-masked]>
Message-ID: <[email-masked]>

(Subject change.  We might also want to take this to ietf-xml-mime at
some point)

Hi Makoto,

On Thu, Jun 09, 2005 at 09:50:56PM +0900, MURATA Makoto wrote:
> At present, we do not have specialized media types for XSLT or W3C XML Schema 
> yet.
> 
> Chris>  <schemas>
> Chris>    <schema type="application/xml" href="foo.xsd"/>
> Chris>    <schema type="application/xml" href="foo.rng"/>
> Chris>    <schema type="application/rnc" href="foo.rnc"/>
> Chris>  </schemas>
> 
> Fetch foo.xsd and foo.rng and parse them.  

Well, I think that can be dangerous in the general case (though
perhaps not for RNG) as it introduces a security vulnerability; it
becomes possible to forge an attack by crafting a document with
multiple (valid!) possible interpretations.  This can be used to
circumvent firewall policies about permitted content.

But I believe the security problem is just one manifestation of the
layering problem inherrent in using intrinsic dispatch (of which XML
namespace dispatch in one kind); that an extrinsic dispatch mechanism,
like media types, cleanly separates the "what" - the raw data - from
the "how" - the semantics with which that data is to be interpreted.
As Chris noted, an XML document can be sent with multiple media types,
including application/octet-stream, application/xml, or one specific to
the XML vocabulary.  The issue is that the resulting messages mean
something entirely different in each case.  With namespace dispatch,
that variation in meaning is lost in many cases.

Consider the following document;

  <html xsl:version="1.0"
    xmlns:xsl="http://www.w3.org/1999/XSL/Transform"
    xmlns="http://www.w3.org/1999/xhtml">
    <head>
      <title>Expense Summary</title>
    </head>
    <body>
      <p>Total Amount:
        <xsl:value-of
        select="expense/total"/></p>
    </body>
  </html>

If this were served with application/xml, and the recipient assumed
namespace dispatch, then it would be interpreted as an XHTML document.
But as you probably recognize, it's also a valid XSLT stylesheet.  There
are other examples too, where a given XML document can be valid per the
rules of more than one XML vocabulary.  Consider this document, which is
both a valid (fictitous) PersonML document, and also a valid RDF/XML
document;

 <Person xmlns="http://example.org/foofoo/">
   <name>Mark Smith</name>
   <age>55</age>
 </Person>

The principle role of media types is, as I see it, is to provide the
clean layering between data and its semantics that I mentioned above, as
this has advantages including superior security and evolvability.
Namespace dispatching has its own advantages, in particular that it
addresses the "media type explosion problem" for some XML based
languages, however those advantages come at a cost.

Mark.
-- 
Mark Baker.  Ottawa, Ontario, CANADA.          http://www.markbaker.ca
Coactus; Web-inspired integration strategies   http://www.coactus.com
>From [email-masked]  Thu Jun  9 17:55:29 2005
From: LMM at acm.org (Larry Masinter)
Date: Thu Jun  9 17:55:40 2005
Subject: Registration of MIME media type application/rnc
In-Reply-To: <[email-masked]>
Message-ID: <[email-masked]>

> First, if you read the archive of the ietf-xml-mime ML, you will 
> find two camps.  One camp (most notably Larry Masinter) believes that 
> media types are never good enough for negotiation, dispatching, or 
> avoiding retrieval and thus specialized media types should be avoided 
> wherever possible.

I'm not too happy with this as a characterization of my
position. I do find myself arguing against media
type registrations, but not because they are _never_
good enough for negotiation, dispatching, or avoiding retrieval.
They're usually not enough for negotiation or avoiding
retrieval, and have a careful limited utility in dispatching.

Usually I argue against using categories (is it type
A or B or C) to distinguish between things with attributes,
especially when multiple attributes apply (does it have an
A? Does it use B? Does it require C?).  But I also generally
argue against using media type parameters when the parameters
aren't necessary to decide interpretation, because they
tend to get lost anyway.

I don't like using media types for situations where content
isn't actually sent independently as a body in a MIME-like
context (HTTP, email, and these days, RTP).

I think protocol designers considering using
MIME types to distinguish between a very limited number
of cases ("which schema language applies?") might consider
using some other value space than "mime type" to make
that distinction.

Chris>  <schemas>
Chris>    <schema type="application/xml" href="foo.xsd"/>
Chris>    <schema type="application/xml" href="foo.rng"/>
Chris>    <schema type="application/rnc" href="foo.rnc"/>
Chris>  </schemas>

It is questionable design to use 'media type' as a way
of distinguishing between multiple schema languages.
You really have a space with a limited number of choices
which doesn't fit very well with media types -- there is
no particular reason to allow arbitrary text, html, jpeg,
pdf, flash, etc. content here -- all of the content types
are new and could be designed to be more self-descriptive,
would not otherwise need media type registratioin.

But, once you have such a context -- if you have a protocol
that distinguishes between different schema languages by
using a 'type' parameter -- then it makes sense to
register different media types for different schema
languages.

I also dislike short, abbreviated media type registrations
(like "application/rnc") when a reasonably longer ones would
help someone unfamiliar understand what it was
(like "application/relax-ng-schema"). Use a short
abbreviation only if Google turns up the meaning of
the abbreviation at the top, but
http://www.google.com/search?q=rnc tells me that rnc
stands for 'Republican National Committee'.

From: murata at hokkaido.email.ne.jp (MURATA Makoto)
Date: Thu Jun  9 16:22:49 2005
Subject: Registration of MIME media type application/rnc
In-Reply-To: <[email-masked]>
References: <[email-masked]> <[email-masked]>
Message-ID: <[email-masked]>

Chris,

Chris> Attributes on media types are generally problematic, and to be avoided.
Chris> Duplicating information in the document is also to be avoided, as is any
Chris> mechanism that requires parsing the document before serving it.

This is silly, since it requires content sniffing.  However, XML
documents can always be parsed.  This is a big difference.

Chris> Attributes on media types are generally problematic, and to be avoided.
Chris> Duplicating information in the document is also to be avoided, as is any
Chris> mechanism that requires parsing the document before serving it.

Some XML-based languages of W3C do not have specialized media types, and 
I think that this is perfectly fine.

One might want to create an XHTML document containing RELAX NG schemas
and W3C XML Schema schemad and use XPointer to referenced to embedded schemas.  
Proliferation of specialized media types hampers such multi-namespace
web.

Chris> Attributes on media types are generally problematic, and to be avoided.
Chris> Duplicating information in the document is also to be avoided, as is any
Chris> mechanism that requires parsing the document before serving it.

They are not attributes on media types but attributes of the element "schema" 
in your example.

Chris> Right. So, please add a registration of application/rng+xml to the
Chris> registration document for RNC. This will please one camp, and neither
Chris> surprise nor inconvenience the other camp.

The second camp (correctly) said that specilized media types cannot 
be prohibited.  Howeveer, nobody said that specilized media types are
encouraged.  I think that specialized media types for XML-based languagages 
are bad things in general.

Cheers,

-- 
MURATA Makoto <[email-masked]>

From: chris at w3.org (Chris Lilley)
Date: Thu Jun  9 15:02:30 2005
Subject: Registration of MIME media type application/rnc
In-Reply-To: <[email-masked]>
References: <[email-masked]> <[email-masked]> <[email-masked]>
Message-ID: <[email-masked]>

On Thursday, June 9, 2005, 2:50:56 PM, MURATA wrote:

MM> Chris and Mark,

MM> I still do not see good reasons to register application/rng+xml.

Well, as I mentioned earlier, RNC could also be transmitted as
application/octet-stream and, indeed, could everything else. That would
be silly, however.

MM> First, if you read the archive of the ietf-xml-mime ML, you will 
MM> find two camps.  One camp (most notably Larry Masinter) believes that
MM> media types are never good enough for negotiation, dispatching, or 
MM> avoiding retrieval and thus specialized media types should be avoided
MM> wherever possible.

Which is an interesting philosophical position but clearly does not fit
well with current practice.

MM>   The other camp does not deny weakness of media types
MM> (especially for multi-namespace XML documents),

I agree, especially for compound document use cases, it can be difficult
to see how to proceed.

MM>  but argues that specialized
MM> media types are often useful

yes

MM> and they cannot be prohibited anyway.

Right. So, please add a registration of application/rng+xml to the
registration document for RNC. This will please one camp, and neither
surprise nor inconvenience the other camp.

MM> At present, we do not have specialized media types for XSLT or W3C
MM> XML Schema yet.

Yes. For an illustration of the problems that causes, please see the
recent attempt to define xforms as a stylesheet language (sorry, the
details are member only, but to illustrate the problem, simply imaging
two stylesheet PIs one of which points to XSL-T (as application/xml) and
one to XForms (as application/xml).

Chris>>  <schemas>
Chris>>    <schema type="application/xml" href="foo.xsd"/>
Chris>>    <schema type="application/xml" href="foo.rng"/>
Chris>>    <schema type="application/rnc" href="foo.rnc"/>
Chris>>  </schemas>

MM> Fetch foo.xsd and foo.rng and parse them.

The entire point of the type attribute is of course as a hint to prevent
fetching something that cannot be understood. Which is why CSS has a
media type, and why media types are being registered for JavaScript and
ECMAScript.

MM>

Chris>> Separate types for W3C XML schema and for RNG (whether in the XML or
Chris>> compact form) would be preferable. Sniffing on filename extensions in a
Chris>> URI is not really a suitable alternative, nor is developing a parallel
Chris>> labelling mechanism to Media Types very attractive.

MM> If fetching is unacceptable, I would propose an attribute indicating
MM> namespaces in the referenced document.  This is more XMLish than
MM> traditional media types.

Attributes on media types are generally problematic, and to be avoided.
Duplicating information in the document is also to be avoided, as is any
mechanism that requires parsing the document before serving it.

MM> Cheers,

MM> Makoto

-- 
 Chris Lilley                    mailto:[email-masked]
 Chair, W3C SVG Working Group
 W3C Graphics Activity Lead

From: distobj at acm.org (Mark Baker)
Date: Wed Jun  8 20:36:15 2005
Subject: Registration of MIME media type application/rnc
In-Reply-To: <[email-masked]>
References: <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]>
Message-ID: <[email-masked]>

Doh!  My bad.  We're in agreement.

On Wed, Jun 08, 2005 at 08:26:21PM +0200, Chris Lilley wrote:
> Sorry. What I meant was that most of the information in the
> application/rnc registration would also apply to application/rng+xml and
> so one registration document could conveniently register both types.
> Specific differences should be called out (as you say, the security
> considerations of the application/xml type also apply, such as the
> entity expansion attack).
>From [email-masked]  Thu Jun  9 14:50:56 2005
From: murata at hokkaido.email.ne.jp (MURATA Makoto)
Date: Thu Jun  9 14:51:01 2005
Subject: Registration of MIME media type application/rnc
In-Reply-To: <[email-masked]>
References: <[email-masked]>
	<[email-masked]>
Message-ID: <[email-masked]>

Chris and Mark,

I still do not see good reasons to register application/rng+xml.

First, if you read the archive of the ietf-xml-mime ML, you will 
find two camps.  One camp (most notably Larry Masinter) believes that 
media types are never good enough for negotiation, dispatching, or 
avoiding retrieval and thus specialized media types should be avoided 
wherever possible.  The other camp does not deny weakness of media types 
(especially for multi-namespace XML documents), but argues that specialized
media types are often useful and they cannot be prohibited anyway.

At present, we do not have specialized media types for XSLT or W3C XML Schema 
yet.

Chris>  <schemas>
Chris>    <schema type="application/xml" href="foo.xsd"/>
Chris>    <schema type="application/xml" href="foo.rng"/>
Chris>    <schema type="application/rnc" href="foo.rnc"/>
Chris>  </schemas>

Fetch foo.xsd and foo.rng and parse them.  

Chris> Separate types for W3C XML schema and for RNG (whether in the XML or
Chris> compact form) would be preferable. Sniffing on filename extensions in a
Chris> URI is not really a suitable alternative, nor is developing a parallel
Chris> labelling mechanism to Media Types very attractive.

If fetching is unacceptable, I would propose an attribute indicating 
namespaces in the referenced document.  This is more XMLish than
traditional media types.

Cheers,

Makoto
-- 
MURATA Makoto <[email-masked]>

From: distobj at acm.org (Mark Baker)
Date: Wed Jun  8 19:38:37 2005
Subject: Registration of MIME media type application/rnc
In-Reply-To: <[email-masked]>
References: <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]>
Message-ID: <[email-masked]>

On Wed, Jun 08, 2005 at 07:16:42PM +0200, Chris Lilley wrote:
> On Wednesday, June 8, 2005, 7:11:19 PM, Mark wrote:
> 
> MB> I agree completely, Chris; a RNG/XML-specific media type would be
> MB> preferable to application/xml.
> 
> It would seem that most of the registration could be shared between the
> two types. Security etc are all the same.

I'd say most of those things are specializations of those specified as
part of the generic type.  For example, while application/xhtml+xml has
the security considerations of the application/xml type, it also has
some which are specific to XHTML.

I'm sure that's what you meant, Chris.  I'm just clarifying.

Cheers,

Mark.
-- 
Mark Baker.  Ottawa, Ontario, CANADA.          http://www.markbaker.ca
Coactus; Web-inspired integration strategies   http://www.coactus.com
>From [email-masked]  Wed Jun  8 20:26:21 2005
From: chris at w3.org (Chris Lilley)
Date: Wed Jun  8 20:26:34 2005
Subject: Registration of MIME media type application/rnc
In-Reply-To: <[email-masked]>
References: <[email-masked]>
	<[email-masked]>
	<[email-masked]>
	<[email-masked]> <[email-masked]>
	<[email-masked]>
	<[email-masked]>
Message-ID: <[email-masked]>

On Wednesday, June 8, 2005, 7:39:09 PM, Mark wrote:

MB> On Wed, Jun 08, 2005 at 07:16:42PM +0200, Chris Lilley wrote:
>> On Wednesday, June 8, 2005, 7:11:19 PM, Mark wrote:
>> 
>> MB> I agree completely, Chris; a RNG/XML-specific media type would be
>> MB> preferable to application/xml.
>> 
>> It would seem that most of the registration could be shared between the
>> two types. Security etc are all the same.

MB> I'd say most of those things are specializations of those specified as
MB> part of the generic type.  For example, while application/xhtml+xml has
MB> the security considerations of the application/xml type, it also has
MB> some which are specific to XHTML.

MB> I'm sure that's what you meant, Chris.  I'm just clarifying.

Sorry. What I meant was that most of the information in the
application/rnc registration would also apply to application/rng+xml and
so one registration document could conveniently register both types.
Specific differences should be called out (as you say, the security
considerations of the application/xml type also apply, such as the
entity expansion attack).

-- 
 Chris Lilley                    mailto:[email-masked]
 Chair, W3C SVG Working Group
 W3C Graphics Activity Lead

From: distobj at acm.org (Mark Baker)
Date: Wed Jun  8 19:10:49 2005
Subject: Registration of MIME media type application/rnc
In-Reply-To: <[email-masked]>
References: <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]>
Message-ID: <[email-masked]>

I agree completely, Chris; a RNG/XML-specific media type would be
preferable to application/xml.

Mark.

> On Tuesday, June 7, 2005, 6:13:34 PM, MURATA wrote:
> 
> Chris>> For the xml syntax, rather than the compact syntax, what is the
> Chris>> appropriate media type? Is application/rng+xml being registered?
> 
> MM> I do not plan to register any specialized media type for RELAX NG
> MM> schemas in the XML syntax.  I think that application/xml is good enough.
> 
> Its good enough to merely indicate that the content is xml. It is not
> sufficient if for example a document points to schemas in multiple
> languages and clarifies them with a type attribute that contains the
> media type:
> 
>  <schemas>
>    <schema type="application/xml" href="foo.xsd"/>
>    <schema type="application/xml" href="foo.rng"/>
>    <schema type="application/rnc" href="foo.rnc"/>
>  </schemas>
> 
> Separate types for W3C XML schema and for RNG (whether in the XML or
> compact form) would be preferable. Sniffing on filename extensions in a
> URI is not really a suitable alternative, nor is developing a parallel
> labelling mechanism to Media Types very attractive.
> 
> If a Media Type is not needed for RNG in the xml format, why is one
> needed for the compact syntax? Application/octet-stream would convey
> just as little information "this is not xml".
> 
> But of course, application/rnc also conveys "this is Relax NG" and "this
> uses the compact syntax". For symmetry therefore, an application/rng+xml
> would convey "this is Relax NG" and "this uses the XML syntax".
> 
> -- 
>  Chris Lilley                    mailto:[email-masked]
>  Chair, W3C SVG Working Group
>  W3C Graphics Activity Lead
> 

-- 
Mark Baker.  Ottawa, Ontario, CANADA.          http://www.markbaker.ca
Coactus; Web-inspired integration strategies   http://www.coactus.com
>From [email-masked]  Wed Jun  8 19:16:42 2005
From: chris at w3.org (Chris Lilley)
Date: Wed Jun  8 19:16:55 2005
Subject: Registration of MIME media type application/rnc
In-Reply-To: <[email-masked]>
References: <[email-masked]>
	<[email-masked]>
	<[email-masked]>
	<[email-masked]> <[email-masked]>
Message-ID: <[email-masked]>

On Wednesday, June 8, 2005, 7:11:19 PM, Mark wrote:

MB> I agree completely, Chris; a RNG/XML-specific media type would be
MB> preferable to application/xml.

It would seem that most of the registration could be shared between the
two types. Security etc are all the same. The two syntaxes are
equivalent in capabilities.

MB> Mark.

>> On Tuesday, June 7, 2005, 6:13:34 PM, MURATA wrote:
>> 
>> Chris>> For the xml syntax, rather than the compact syntax, what is the
>> Chris>> appropriate media type? Is application/rng+xml being registered?
>> 
>> MM> I do not plan to register any specialized media type for RELAX NG
>> MM> schemas in the XML syntax.  I think that application/xml is good enough.
>> 
>> Its good enough to merely indicate that the content is xml. It is not
>> sufficient if for example a document points to schemas in multiple
>> languages and clarifies them with a type attribute that contains the
>> media type:
>> 
>>  <schemas>
>>    <schema type="application/xml" href="foo.xsd"/>
>>    <schema type="application/xml" href="foo.rng"/>
>>    <schema type="application/rnc" href="foo.rnc"/>
>>  </schemas>
>> 
>> Separate types for W3C XML schema and for RNG (whether in the XML or
>> compact form) would be preferable. Sniffing on filename extensions in a
>> URI is not really a suitable alternative, nor is developing a parallel
>> labelling mechanism to Media Types very attractive.
>> 
>> If a Media Type is not needed for RNG in the xml format, why is one
>> needed for the compact syntax? Application/octet-stream would convey
>> just as little information "this is not xml".
>> 
>> But of course, application/rnc also conveys "this is Relax NG" and "this
>> uses the compact syntax". For symmetry therefore, an application/rng+xml
>> would convey "this is Relax NG" and "this uses the XML syntax".
>> 
>> -- 
>>  Chris Lilley                    mailto:[email-masked]
>>  Chair, W3C SVG Working Group
>>  W3C Graphics Activity Lead
>> 

-- 
 Chris Lilley                    mailto:[email-masked]
 Chair, W3C SVG Working Group
 W3C Graphics Activity Lead

From: chris at w3.org (Chris Lilley)
Date: Wed Jun  8 14:59:05 2005
Subject: Registration of MIME media type application/rnc
In-Reply-To: <[email-masked]>
References: <[email-masked]> <[email-masked]> <[email-masked]>
Message-ID: <[email-masked]>

On Tuesday, June 7, 2005, 6:13:34 PM, MURATA wrote:

Chris>> For the xml syntax, rather than the compact syntax, what is the
Chris>> appropriate media type? Is application/rng+xml being registered?

MM> I do not plan to register any specialized media type for RELAX NG
MM> schemas in the XML syntax.  I think that application/xml is good enough.

Its good enough to merely indicate that the content is xml. It is not
sufficient if for example a document points to schemas in multiple
languages and clarifies them with a type attribute that contains the
media type:

 <schemas>
   <schema type="application/xml" href="foo.xsd"/>
   <schema type="application/xml" href="foo.rng"/>
   <schema type="application/rnc" href="foo.rnc"/>
 </schemas>

Separate types for W3C XML schema and for RNG (whether in the XML or
compact form) would be preferable. Sniffing on filename extensions in a
URI is not really a suitable alternative, nor is developing a parallel
labelling mechanism to Media Types very attractive.

If a Media Type is not needed for RNG in the xml format, why is one
needed for the compact syntax? Application/octet-stream would convey
just as little information "this is not xml".

But of course, application/rnc also conveys "this is Relax NG" and "this
uses the compact syntax". For symmetry therefore, an application/rng+xml
would convey "this is Relax NG" and "this uses the XML syntax".

-- 
 Chris Lilley                    mailto:[email-masked]
 Chair, W3C SVG Working Group
 W3C Graphics Activity Lead

From: murata at hokkaido.email.ne.jp (MURATA Makoto)
Date: Tue Jun  7 18:27:04 2005
Subject: Registration of MIME media type application/rnc
In-Reply-To: <[email-masked]>
References: <[email-masked]> <[email-masked]>
Message-ID: <[email-masked]>

Scott> I've looked at what I think is the referenced specification [1], but it
Scott> doesn't include a copy of the registration template as described in section
Scott> 4.10 of draft-freed-media-type-reg.  Is it possible to update the
Scott> specification to include the template?  If not, is it possible to write an
Scott> Internet-Draft document to document the registration request.  Without one
Scott> of these our current procedures don't include a way to register this media
Scott> type in the standards tree.

Yes, SC34 is going to introduce the registration template as part of the
upcoming FDAM.   http://www.dsdl.org/0523.pdf is a PDAM.  Since the FDAM
is very likely to become an Amendment without any technical changes, I
would like to solicit comments from ietf-type first.

SC34 will prepare a draft of the FDAM and make it publicly available. 
Then, I will send the request to the IESG.

Cheers,

-- 
MURATA Makoto <[email-masked]>

From: murata at hokkaido.email.ne.jp (MURATA Makoto)
Date: Tue Jun  7 18:13:41 2005
Subject: Registration of MIME media type application/rnc
In-Reply-To: <[email-masked]>
References: <[email-masked]> <[email-masked]>
Message-ID: <[email-masked]>

Chris> For the xml syntax, rather than the compact syntax, what is the
Chris> appropriate media type? Is application/rng+xml being registered?

I do not plan to register any specialized media type for RELAX NG
schemas in the XML syntax.  I think that application/xml is good enough.

Cheers,
-- 
MURATA Makoto <[email-masked]>

From: sah at 428cobrajet.net (Scott Hollenbeck)
Date: Mon Jun  6 20:52:58 2005
Subject: Registration of MIME media type application/rnc
In-Reply-To: <[email-masked]>
Message-ID: <[email-masked]>

A procedural nit:

Would you please send this request to the IESG ([email-masked]) as described
in sections 4.10 and 5 of this document?:

http://www.ietf.org/internet-drafts/draft-freed-media-type-reg-04.txt

I've looked at what I think is the referenced specification [1], but it
doesn't include a copy of the registration template as described in section
4.10 of draft-freed-media-type-reg.  Is it possible to update the
specification to include the template?  If not, is it possible to write an
Internet-Draft document to document the registration request.  Without one
of these our current procedures don't include a way to register this media
type in the standards tree.

-Scott-
[1]
http://www.dsdl.org/0523.pdf

> -----Original Message-----
> From: MURATA Makoto [mailto:[email-masked]] 
> Sent: Thursday, June 02, 2005 10:29 AM
> To: [email-masked]
> Subject: Registration of MIME media type application/rnc
> 
> This is a request for registration in the standard tree.
> 
> The compact syntax for RELAX NG (a schema language for XML) will be
> published as a Final Draft Amendment (FDAM) of ISO/IEC 19757-4 soon.
> The FDAM will contain this registation information.  If this FDAM
> passes a two-month FDAM ballot, it will become an Amendment of ISO/IEC
> 197575-4.  Since this FDAM ballot does not allow any technical
> comments and many member bodies of ISO/IEC JTC1 simply say yes, the
> FDAM is extremely likely to pass the ballot.  The compact syntax 
> was first published as an OASIS committee specification.
> 
> 
>      MIME media type name: application
> 
>      MIME subtype name: rnc
> 
>      Required parameters: none
> 
>      Optional parameters: none
> 
>      Encoding considerations: UTF-8 or UTF-16 shall be used 
> for  this media type. 
> 
>      Security considerations:  When the RELAX NG validator 
> retrieves a schema 
> in the RELAX NG compact syntax, it may further retrieve 
> external schemas that 
> are referenced from the schema directly or indirectly.  
> Although the RELAX NG
> validator is required not to retrieve an infinite number of 
> schemas, a large 
> number of external schemas may be retrieved, thus wasting the 
> network, disk, and CPU 
> power.
> 
>      Interoperability considerations: 
>          RELAX NG has been widely used as an XML schema language.  
> 	  A notable example is the Open Document specification of OASIS.
> 
>      Published specification:
> 
>      ISO/IEC 19757-2, Document Schema Definition Language (DSDL) 
>      Part 2 - Regular-grammar-based validation -- RELAX NG, 
>      Amendment 1: Compact Syntax
> 
>      OASIS Committee Specification, RELAX NG Compact Syntax
>      21 November 2002
> 
>      Applications which use this media type: 
> 		   validators, schema authoring tools, and so forth
> 
>      Additional information:
> 
>        Magic number(s): none
>        File extension(s): rnc
>        Macintosh File Type Code(s): "TEXT"
> 
>      Person & email address to contact for further information:
> 
>      MURATA Makoto (FAMILY Given), International University of Japan,
>      [email-masked]
> 
>      Intended usage: COMMON
> 
>      Author/Change controller: ISO/IEC JTC1/SC34
> -- 
> MURATA Makoto <[email-masked]>
> 
> 
> 

From: chris at w3.org (Chris Lilley)
Date: Sun Jun  5 14:37:59 2005
Subject: [AVT] Re: Request to review media type in AVT working group lastcall: draft-ietf-avt-rtp-3gpp-timed-text.txt
In-Reply-To: <[email-masked]>
References: <[email-masked]> <[email-masked]> <[email-masked]>
Message-ID: <[email-masked]>

On Friday, June 3, 2005, 5:16:03 PM, Magnus wrote:

MW> Duplicating the information is mostly a recipe for confusion when it
MW> doesn't agree. Thus, I propose to leave it out.

Wise words in general.

-- 
 Chris Lilley                    mailto:[email-masked]
 Chair, W3C SVG Working Group
 W3C Graphics Activity Lead

From: ned.freed at mrochek.com (Ned Freed)
Date: Fri Jun  3 16:49:26 2005
Subject: [AVT] Re: Request to review media type in AVT working	group lastcall: draft-ietf-avt-rtp-3gpp-timed-text.txt
In-Reply-To: "Your message dated Fri, 03 Jun 2005 09:12:26 -0400" <[email-masked]>
References: <[email-masked]> <[email-masked]>
Message-ID: <[email-masked]>

> Simple question: do you expect a given session to consist of just one
> character encoding (UTF-8 or UTF-16) or do you want the possibility for
> it to contain a mixture?  If the encoding is a per-session attribute it
> makes more sense for it to be negotiated out-of-band, as a parameter of
> the MIME type (and hence as an SDP "a=fmtp" parameter).

Yes, this is what I was trying to get at when I asked if the bit appears
in the same context as the media type or not.

				Ned
>From [email-masked]  Fri Jun  3 17:16:03 2005
From: magnus.westerlund at ericsson.com (Magnus Westerlund)
Date: Fri Jun  3 17:16:14 2005
Subject: [AVT] Re: Request to review media type in AVT
 working	group	lastcall: draft-ietf-avt-rtp-3gpp-timed-text.txt
In-Reply-To: <[email-masked]>
References: <[email-masked]>
	<[email-masked]>
Message-ID: <[email-masked]>

Hi Tom,

Tom Taylor wrote:
> Simple question: do you expect a given session to consist of just one 
> character encoding (UTF-8 or UTF-16) or do you want the possibility for 
> it to contain a mixture?  If the encoding is a per-session attribute it 
> makes more sense for it to be negotiated out-of-band, as a parameter of 
> the MIME type (and hence as an SDP "a=fmtp" parameter).
> 

To my understanding a session may contain a mixture of UTF-8 and UTF-16.

Note also, that removing the bit wouldn't result in any byte savings.

So I see it as necessary to have the U bit. Duplicating the information 
is mostly a recipe for confusion when it doesn't agree. Thus, I propose 
to leave it out.

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]  Fri Jun  3 17:49:10 2005
From: ned.freed at mrochek.com (Ned Freed)
Date: Fri Jun  3 17:51:00 2005
Subject: [AVT] Re: Request to review media type in AVT working	group
	lastcall: draft-ietf-avt-rtp-3gpp-timed-text.txt
In-Reply-To: "Your message dated Fri, 03 Jun 2005 17:16:03 +0200"
	<[email-masked]>
References: <[email-masked]>
	<[email-masked]> <[email-masked]>
Message-ID: <[email-masked]>

> Hi Tom,

> Tom Taylor wrote:
> > Simple question: do you expect a given session to consist of just one
> > character encoding (UTF-8 or UTF-16) or do you want the possibility for
> > it to contain a mixture?  If the encoding is a per-session attribute it
> > makes more sense for it to be negotiated out-of-band, as a parameter of
> > the MIME type (and hence as an SDP "a=fmtp" parameter).
> >

> To my understanding a session may contain a mixture of UTF-8 and UTF-16.

That implies that the bit isn't aligned with where media types appear. And that
in turn makes it inappropriate to map to a media type parameter, irrespective
of whether or not it is used for negotiation.

				Ned
>From [email-masked]  Fri Jun  3 17:49:10 2005
From: ned.freed at mrochek.com (Ned Freed)
Date: Fri Jun  3 19:26:57 2005
Subject: [AVT] Re: Request to review media type in AVT working	group
	lastcall: draft-ietf-avt-rtp-3gpp-timed-text.txt
In-Reply-To: "Your message dated Fri, 03 Jun 2005 17:16:03 +0200"
	<[email-masked]>
References: <[email-masked]>
	<[email-masked]> <[email-masked]>
Message-ID: <[email-masked]>

> Hi Tom,

> Tom Taylor wrote:
> > Simple question: do you expect a given session to consist of just one
> > character encoding (UTF-8 or UTF-16) or do you want the possibility for
> > it to contain a mixture?  If the encoding is a per-session attribute it
> > makes more sense for it to be negotiated out-of-band, as a parameter of
> > the MIME type (and hence as an SDP "a=fmtp" parameter).
> >

> To my understanding a session may contain a mixture of UTF-8 and UTF-16.

That implies that the bit isn't aligned with where media types appear. And that
in turn makes it inappropriate to map to a media type parameter, irrespective
of whether or not it is used for negotiation.

				Ned

_______________________________________________
Audio/Video Transport Working Group
[email-masked]
https://www1.ietf.org/mailman/listinfo/avt
>From [email-masked]  Fri Jun  3 17:16:03 2005
From: magnus.westerlund at ericsson.com (Magnus Westerlund)
Date: Fri Jun  3 19:27:05 2005
Subject: [AVT] Re: Request to review media type in AVT
	working	group	lastcall: draft-ietf-avt-rtp-3gpp-timed-text.txt
In-Reply-To: <[email-masked]>
References: <[email-masked]>
	<[email-masked]>
Message-ID: <[email-masked]>

Hi Tom,

Tom Taylor wrote:
> Simple question: do you expect a given session to consist of just one 
> character encoding (UTF-8 or UTF-16) or do you want the possibility for 
> it to contain a mixture?  If the encoding is a per-session attribute it 
> makes more sense for it to be negotiated out-of-band, as a parameter of 
> the MIME type (and hence as an SDP "a=fmtp" parameter).
> 

To my understanding a session may contain a mixture of UTF-8 and UTF-16.

Note also, that removing the bit wouldn't result in any byte savings.

So I see it as necessary to have the U bit. Duplicating the information 
is mostly a recipe for confusion when it doesn't agree. Thus, I propose 
to leave it out.

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]

_______________________________________________
Audio/Video Transport Working Group
[email-masked]
https://www1.ietf.org/mailman/listinfo/avt
>From [email-masked]  Fri Jun  3 20:05:47 2005
From: Jose.Rey at eu.panasonic.com (Jose Rey)
Date: Fri Jun  3 20:49:08 2005
Subject: [AVT] Re: Request to review media type in AVT
	working	grouplastcall: draft-ietf-avt-rtp-3gpp-timed-text.txt
Message-ID: <[email-masked]>

[sorry for delay.. I am travelling]

Ned, Tom,

> 
> > Hi Tom,
> 
> > Tom Taylor wrote:
> > > Simple question: do you expect a given session to consist of just 
> > > one character encoding (UTF-8 or UTF-16) or do you want the 
> > > possibility for it to contain a mixture?  If the encoding is a 
> > > per-session attribute it makes more sense for it to be negotiated 
> > > out-of-band, as a parameter of the MIME type (and hence 
> as an SDP "a=fmtp" parameter).
> > >
> 
> > To my understanding a session may contain a mixture of 
> UTF-8 and UTF-16.

This is correct.  

> 
> That implies that the bit isn't aligned with where media 
> types appear. And that in turn makes it inappropriate to map 
> to a media type parameter, irrespective of whether or not it 
> is used for negotiation.
> 

Yes.

Since all is fine now, I will make the changes and send a new draft in the next days.

Jos?

From: Jose.Rey at eu.panasonic.com (Jose Rey)
Date: Fri Jun  3 15:19:44 2005
Subject: [AVT] Re: Request to review media type in AVT working group lastcall: draft-ietf-avt-rtp-3gpp-timed-text.txt
Message-ID: <[email-masked]>

Ned,

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On 
> Behalf Of Ned Freed
> Sent: Thursday, June 02, 2005 7:50 PM
> To: Magnus Westerlund
> Cc: Ned Freed; IETF AVT WG; Allison Mankin; Bruce Lilly; 
> Colin Perkins; [email-masked]
> Subject: Re: [AVT] Re: Request to review media type in AVT 
> working group lastcall: draft-ietf-avt-rtp-3gpp-timed-text.txt
> 
> > Ned Freed wrote:
> > >
> > > Then why do you need the U bit?
> 
> >  From TS 26.245, section 5.1:
> 
> > Text strings for display and font names are uniformly coded 
> in UTF-8, 
> > or start with a UTF-16 BYTE ORDER MARK (\uFEFF) and by that 
> indicate 
> > that the string which starts with the byte order mark is in UTF-16.
> > Terminals shall recognise the byte-order mark in this byte 
> order; they 
> > are not required to recognise byte-reversed UTF-16, indicated by a 
> > byte-reversed byte-order mark.
> 
> > However this payload format removes the Byte Order Mark and 
> requires a 
> > specific byte order. Thus to be able to provide the same 
> information 
> > that a string is encoded in UTF-8 or UTF-16, it is explicitly 
> > indicated using the U bit.
> 
> Does the U bit appear in the same context as the media type 
> itself or is it part of the payload or some other aspect of 
> the  protocol?

I don't know what exactly is meant by the latter, but the former is not the case.  Besides, apart from complicating session negotiation (O/A, as Magnus mentions) it is really not necessary because both charsets are required by the TT media format.

> It seems appropriate to define a mapping to a 
> parameter if it appears alongside the media type, but not if 
> it doesn't.
[snip]

> I'm not suggesting defining additional parameters. I'm only 
> asking if it makes sense to map and existing session 
> parameter to a media type parameter.
> 

It doesn't make sense, it is not a negotiable thing.

Cheers,

Jos?

From: rjesup at wgate.com (Randell Jesup)
Date: Fri Jun  3 15:19:43 2005
Subject: [AVT] Re: Request to review media type in AVT working group last call: draft-ietf-avt-rtp-3gpp-timed-text.txt
In-Reply-To: <[email-masked]>
References: <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]> <p06230595bec4d9ca9254@[17.202.35.52]> <[email-masked]> <p062305a3bec4e32ec5e7@[17.202.35.52]> <[email-masked]> <[email-masked]>
Message-ID: <[email-masked]>

Magnus Westerlund <[email-masked]> writes:
>You are correct it is not SDP that limits the usage, the question is what
>the right type is. 3GPP Timed text is clearly text and it is displayed as
>lines. However it also has connections to video by being specified to
>placed as an overlay in a specific part of the video display.

        Ummm.  So anything that can be eventually displayed (on a monitor or
other screen, since text could be displayed on a text-only display or beeper,
etc) is "video"?  This really, really rubs me the wrong way.  It just
feels "wrong".

        Now, it can be under anything.  But what's the _purpose_ and
effect?  Often, applications using SDP limit the number of streams of a
type (1 audio, 1 video, etc).  Now, they could relax that, but it starts
adding complexity to the negotiations ("1 video but 2 if one (and only one)
of the streams selects a text payload type").

        It makes sense for it to be video if it's intended to be 
in the same stream as "real" video as an alternate payload type (as an
overlay on video).  Maybe that's the case, in which case I partly withdraw
my objection.

>In addition certain of the modifiers create video-like modifications of
>the text strings. Especially the karaoke modifier that repaint the
>characters with a time dependent speed.

        I wouldn't consider that "video-like".  Non-static, but not
video-like. 

>So it is text, but with a twist. My opinion is that this still is text and
>many streams will be possible to display on a text only device. You can
>could in fact make a stock ticker that receives this format.

Stock ticker, "beeper", IM-specific device, cell SMS messages, scrolling-text
displays in stores, etc, etc.

Note: I really haven't been following this, so take my comments with a
block of salt.

-- 
Randell Jesup, Worldgate Communications, ex-Scala, ex-Amiga OS team
[email-masked]

From: magnus.westerlund at ericsson.com (Magnus Westerlund)
Date: Thu Jun  2 18:55:33 2005
Subject: [AVT] Re: Request to review media type in AVT working group last call: draft-ietf-avt-rtp-3gpp-timed-text.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]>

Ned Freed wrote:
> 
> Then why do you need the U bit?

 From TS 26.245, section 5.1:

Text strings for display and font names are uniformly coded in UTF-8, or 
start with a UTF-16 BYTE ORDER MARK (\uFEFF) and by that indicate that 
the string which starts with the byte order mark is in UTF-16. 
Terminals shall recognise the byte-order mark in this byte order; they 
are not required to recognise byte-reversed UTF-16, indicated by a 
byte-reversed byte-order mark.

However this payload format removes the Byte Order Mark and requires a 
specific byte order. Thus to be able to provide the same information 
that a string is encoded in UTF-8 or UTF-16, it is explicitly indicated 
using the U bit.

> 
> Let me be clear here. I have no problem with not defining the parameter, 
> but
> I don't understand why the number of charsets involved forms a criteria
> for whether or not it is needed. I'm just trying to understand a bit more
> about the nature of the underlying transport, I guess.
> 

Sorry, I might have misunderstood what charsets are. Are they all 
character encodings, i.e. mapping a value to a specific character? Or 
are there cases where charsets are sub-sets of a specific character 
encoding? For example, are there a charset that uses UTF-8 encoding but 
only contains a subset of the total characters?

If it is the seconds, there might be a benefit to define a charset 
character parameter to allow session participants to negotiate that set 
of used characters or at least know which will be used. However I guess 
it will be a parameter to which it will be hell to define the 
offer/answer usage for.

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]  Thu Jun  2 19:01:05 2005
From: ned.freed at mrochek.com (Ned Freed)
Date: Thu Jun  2 19:01:30 2005
Subject: [AVT] Re: Request to review media type in AVT working group	last
 call: draft-ietf-avt-rtp-3gpp-timed-text.txt
In-Reply-To: "Your message dated Thu, 02 Jun 2005 18:47:48 +0200"
	<[email-masked]>
References: <[email-masked]>
	<[email-masked]> <[email-masked]>
	<[email-masked]>
	<[email-masked]>
	<[email-masked]> <[email-masked]>
	<p06230595bec4d9ca9254@[17.202.35.52]>
	<[email-masked]>
	<p062305a3bec4e32ec5e7@[17.202.35.52]>
	<[email-masked]>
	<[email-masked]>
Message-ID: <[email-masked]>

> There is probably a need for a more reasonably defined top level type,
> like textual/* or something, but the timescales and amount of effort to
> establish such a thing are non-negligible.

Agreed.

				Ned
>From [email-masked]  Thu Jun  2 18:58:48 2005
From: singer at apple.com (Dave Singer)
Date: Thu Jun  2 19:01:51 2005
Subject: [AVT] Re: Request to review media type in AVT working group
 last  call:  draft-ietf-avt-rtp-3gpp-timed-text.txt
In-Reply-To: <[email-masked]>
References: <[email-masked]>
	<[email-masked]> <[email-masked]>
	<[email-masked]>
	<[email-masked]> <[email-masked]>
	<[email-masked]> <p06230595bec4d9ca9254@[17.202.35.52]>
	<[email-masked]>
	<p062305a3bec4e32ec5e7@[17.202.35.52]>
	<[email-masked]>
	<[email-masked]>
Message-ID: <p062305a9bec4eaae87c4@[17.202.35.52]>

At 18:47  +0200 2/06/05, Chris Lilley wrote:
>On Thursday, June 2, 2005, 6:32:45 PM, Ned wrote:
>
>>>  Thanks, but now I am lost.  Why is this a 'video' stream and not a
>>>  'text' stream, then?
>
>NF> Presumably because the intent is to display this as video. The 
>rules for what
>NF> can fit under video are pretty loose; this is certainly an 
>acceptable use of
>NF> the video top-level type. Text, OTOH, is usually thought of as a series of
>NF> lines and not as a stream of characters.
>
>Text is certainly a sequence of characters, which may or may not be
>preformatted into 'lines'. Other characteristics of text are that
>spell-checking and translation to a different language are reasonable
>things to do with it.
>
>Whether the text/* top level type is like that is another matter again,
>of course;  that type having sufficient problems that it should really
>not be used for anything much beyond text/plain; charset=us-ascii.
>
>
>NF> My (incorrect) understanding was that video was an unacceptable 
>choice due to
>NF> SDP constraints. Without that constraint I would have been 
>pushing for this
>NF> to go under video from the beginning.
>
>Timed text, because of its time dependent nature, is an arguable fit for
>video (but something of a stretch).
>
>There is probably a need for a more reasonably defined top level type,
>like textual/* or something, but the timescales and amount of effort to
>establish such a thing are non-negligible.

Thanks guys.  This is clearly a sticky area, and as you say, timed 
text is presumed to be visually presented (though I guess it could be 
read aloud) so I guess 'video' is OK.

I suspect that the true distinction lies in considering presentation; 
'text' types should be presentable by a text-to-speech system (for 
the vision impaired, for example), whereas 'video' would not be 
expected to be capable of this.  This in turn would suggest moving 
back to 'text' here, but only if the rules and maybe name of the 
'text' type were clarified, and I agree that that is a long road to 
hoe.

I rest my case, let video rule (though I still doubt its true correctness).
-- 
David Singer
Apple Computer/QuickTime
>From [email-masked]  Thu Jun  2 19:04:06 2005
From: magnus.westerlund at ericsson.com (Magnus Westerlund)
Date: Thu Jun  2 19:04:13 2005
Subject: [AVT] Re: Request to review media type in AVT working group last
 call:  draft-ietf-avt-rtp-3gpp-timed-text.txt
In-Reply-To: <[email-masked]>
References: <[email-masked]>
	<[email-masked]>
	<[email-masked]>
	<[email-masked]>
	<[email-masked]>
	<[email-masked]> <[email-masked]>
	<p06230595bec4d9ca9254@[17.202.35.52]>
	<[email-masked]>
	<p062305a3bec4e32ec5e7@[17.202.35.52]>
	<[email-masked]>
Message-ID: <[email-masked]>

Ned Freed wrote:
>> Thanks, but now I am lost.  Why is this a 'video' stream and not a
>> 'text' stream, then?
> 
> 
> Presumably because the intent is to display this as video. The rules for 
> what
> can fit under video are pretty loose; this is certainly an acceptable 
> use of
> the video top-level type. Text, OTOH, is usually thought of as a series of
> lines and not as a stream of characters.
> 
> My (incorrect) understanding was that video was an unacceptable choice 
> due to
> SDP constraints. Without that constraint I would have been pushing for this
> to go under video from the beginning.
> 

You are correct it is not SDP that limits the usage, the question is 
what the right type is. 3GPP Timed text is clearly text and it is 
displayed as lines. However it also has connections to video by being 
specified to placed as an overlay in a specific part of the video 
display. In addition certain of the modifiers create video-like 
modifications of the text strings. Especially the karaoke modifier that 
repaint the characters with a time dependent speed.

So it is text, but with a twist. My opinion is that this still is text 
and many streams will be possible to display on a text only device. You 
can could in fact make a stock ticker that receives this format.

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]  Thu Jun  2 19:12:07 2005
From: csp at csperkins.org (Colin Perkins)
Date: Thu Jun  2 19:12:42 2005
Subject: [AVT] Re: Request to review media type in AVT working group
	last call: draft-ietf-avt-rtp-3gpp-timed-text.txt
In-Reply-To: <[email-masked]>
References: <[email-masked]>
	<[email-masked]>
	<[email-masked]>
	<[email-masked]>
	<[email-masked]>
	<[email-masked]> <[email-masked]>
	<p06230595bec4d9ca9254@[17.202.35.52]>
	<[email-masked]>
	<p062305a3bec4e32ec5e7@[17.202.35.52]>
	<[email-masked]>
	<[email-masked]>
Message-ID: <[email-masked]>

On 2 Jun 2005, at 18:04, Magnus Westerlund wrote:
> Ned Freed wrote:
>>> Thanks, but now I am lost.  Why is this a 'video' stream and not a
>>> 'text' stream, then?
>>>
>> Presumably because the intent is to display this as video. The  
>> rules for what
>> can fit under video are pretty loose; this is certainly an  
>> acceptable use of
>> the video top-level type. Text, OTOH, is usually thought of as a  
>> series of
>> lines and not as a stream of characters.
>> My (incorrect) understanding was that video was an unacceptable  
>> choice due to
>> SDP constraints. Without that constraint I would have been pushing  
>> for this
>> to go under video from the beginning.
>>
>
> You are correct it is not SDP that limits the usage, the question  
> is what the right type is. 3GPP Timed text is clearly text and it  
> is displayed as lines. However it also has connections to video by  
> being specified to placed as an overlay in a specific part of the  
> video display. In addition certain of the modifiers create video- 
> like modifications of the text strings. Especially the karaoke  
> modifier that repaint the characters with a time dependent speed.
>
> So it is text, but with a twist. My opinion is that this still is  
> text and many streams will be possible to display on a text only  
> device. You can could in fact make a stock ticker that receives  
> this format.

And, it's straightforward to strip the formatting, and display as  
generic text.

Colin
>From [email-masked]  Thu Jun  2 19:50:21 2005
From: ned.freed at mrochek.com (Ned Freed)
Date: Thu Jun  2 19:58:02 2005
Subject: [AVT] Re: Request to review media type in AVT working group last
 call: draft-ietf-avt-rtp-3gpp-timed-text.txt
In-Reply-To: "Your message dated Thu, 02 Jun 2005 18:55:26 +0200"
	<[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]>

> Ned Freed wrote:
> >
> > Then why do you need the U bit?

>  From TS 26.245, section 5.1:

> Text strings for display and font names are uniformly coded in UTF-8, or
> start with a UTF-16 BYTE ORDER MARK (\uFEFF) and by that indicate that
> the string which starts with the byte order mark is in UTF-16.
> Terminals shall recognise the byte-order mark in this byte order; they
> are not required to recognise byte-reversed UTF-16, indicated by a
> byte-reversed byte-order mark.

> However this payload format removes the Byte Order Mark and requires a
> specific byte order. Thus to be able to provide the same information
> that a string is encoded in UTF-8 or UTF-16, it is explicitly indicated
> using the U bit.

Does the U bit appear in the same context as the media type itself or is
it part of the payload or some other aspect of the  protocol? It seems
appropriate to define a mapping to a parameter if it appears alongside
the media type, but not if it doesn't.

> > Let me be clear here. I have no problem with not defining the parameter, but
> > I don't understand why the number of charsets involved forms a criteria
> > for whether or not it is needed. I'm just trying to understand a bit more
> > about the nature of the underlying transport, I guess.

> Sorry, I might have misunderstood what charsets are. Are they all
> character encodings, i.e. mapping a value to a specific character?

A charset is defined as a mapping from bytes to characters.

Howevr, we're talking about a media type parameter here, not charsets
per se. The media type parameter could be expressed in a number of
different ways, e.g. u=8 vs u=16 would be one way to write it. I only
suggested writing it as "charset=utf-8" and "charset=utf-16" because
that corresponds to what's been done before.

> Or
> are there cases where charsets are sub-sets of a specific character
> encoding? For example, are there a charset that uses UTF-8 encoding but
> only contains a subset of the total characters?

I don't know of one of these specifically, but nothing would prevent one
from being defined.

Similarly, nothing prevents a charset parameter from being defined that
only accepts a small subset of the world's charsets. Or having different
default rules when it is missing. The only restriction here is on the
meaning of charset in conjunction with text media types, and we're no
longer talking about text types here.

> If it is the seconds, there might be a benefit to define a charset
> character parameter to allow session participants to negotiate that set
> of used characters or at least know which will be used. However I guess
> it will be a parameter to which it will be hell to define the
> offer/answer usage for.

I'm not suggesting defining additional parameters. I'm only asking if
it makes sense to map and existing session parameter to a media type
parameter.

				Ned
>From [email-masked]  Thu Jun  2 21:20:56 2005
From: LMM at acm.org (Larry Masinter)
Date: Thu Jun  2 21:21:08 2005
Subject: [AVT] Re: Request to review media type in AVT working grouplast
 call: draft-ietf-avt-rtp-3gpp-timed-text.txt
In-Reply-To: <[email-masked]>
Message-ID: <[email-masked]>

(I trimmed the 'to' list down to the two lists)

I think lots of "application" types contain text,
have the feature that "spell-checking and translation
to a different language" is a reasonable thing to do.

I think these are suitable content features (attributes),
not content-type (category), and the top level media
type category isn't a good place to add more differentiation.

Larry

From: chris at w3.org (Chris Lilley)
Date: Tue Jun  7 15:59:34 2005
Subject: Registration of MIME media type application/rnc
In-Reply-To: <[email-masked]>
References: <[email-masked]>
Message-ID: <[email-masked]>

On Thursday, June 2, 2005, 4:29:21 PM, MURATA wrote:

MM> This is a request for registration in the standard tree.

MM> The compact syntax for RELAX NG (a schema language for XML) will be
MM> published as a Final Draft Amendment (FDAM) of ISO/IEC 19757-4 soon.

Great news.

MM>      MIME media type name: application

MM>      MIME subtype name: rnc

MM>      Required parameters: none

MM>      Optional parameters: none

MM>      Encoding considerations: UTF-8 or UTF-16 shall be used for this media type.

For the xml syntax, rather than the compact syntax, what is the
appropriate media type? Is application/rng+xml being registered?

-- 
 Chris Lilley                    mailto:[email-masked]
 Chair, W3C SVG Working Group
 W3C Graphics Activity Lead

From: Jose.Rey at eu.panasonic.com (Jose Rey)
Date: Fri Jun  3 15:19:43 2005
Subject: [AVT] Re: Request to review media type in AVT working group last call: draft-ietf-avt-rtp-3gpp-timed-text.txt
Message-ID: <[email-masked]>

Hi Ned, 

Thanks for the comments and enhancements.  Agreed stuff has been cut...

> At one point I suggest it might be appropriate to map the U 
> bit to a charset parameter. Does this make any sense to do?

Sorry, I am not sure what you mean with that.  DO you mean to change the name of the field or the field in the payload format?

Comments?

Jos?  

> 
> 				Ned
> 
> _______________________________________________
> Audio/Video Transport Working Group
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/avt
> 
> 

From: blilly at erols.com (Bruce Lilly)
Date: Thu Jun  2 21:21:28 2005
Subject: Request to review media type in AVT working group last call: draft-ietf-avt-rtp-3gpp-timed-text.txt
In-Reply-To: <[email-masked]>
References: <[email-masked]> <[email-masked]> <[email-masked]>
Message-ID: <[email-masked]>

On Thu June 2 2005 10:23, Magnus Westerlund wrote:
> Hi,
> 
> After having discussed this with the authors and Colin we have the below 
> proposed changes. So does this resolve the issues with the media type 
> and the confusing statement around TCP?

From: ned.freed at mrochek.com (Ned Freed)
Date: Thu Jun  2 16:44:58 2005
Subject: Request to review media type in AVT working group last call: draft-ietf-avt-rtp-3gpp-timed-text.txt
In-Reply-To: "Your message dated Thu, 02 Jun 2005 16:23:23 +0200" <[email-masked]>
References: <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]>
Message-ID: <[email-masked]>

> After having discussed this with the authors and Colin we have the below
> proposed changes. So does this resolve the issues with the media type
> and the confusing statement around TCP?

IMO this looks good. I only have one wordsmithing nit and a question.

> ...

> NEW:
>      The media subtype for the 3GPP Timed Text codec is allocated from the
>      standards tree.  The top-level media type under which this payload
>      format is registered is 'video'. This registration is done using the
>      template defined in [34] and following RFC 3555 [33].

>      The receiver MUST ignore any unrecognized parameter.

>      Media type: video

I'm delighted to see this moved to video.

> NEW:
>      Encoding considerations:

>           This media type is framed (see section 4.8 in [34]) and
> partially contains binary data.

This seems a bit awkward. How about "This media type is framed (see section 4.8
in [34]) and has both binary and textual components."

>      Restrictions on usage:

> 	   This media type depends on RTP framing, and hence is only defined for
>       	   transfer via RTP [RFC 3550]. Transport within other framing protocols
>       	   is not defined at this time.

Nicely put.

At one point I suggest it might be appropriate to map the U bit to a charset
parameter. Does this make any sense to do?

				Ned
>From [email-masked]  Thu Jun  2 18:16:06 2005
From: magnus.westerlund at ericsson.com (Magnus Westerlund)
Date: Thu Jun  2 18:16:13 2005
Subject: Request to review media type in AVT working group last call:
 draft-ietf-avt-rtp-3gpp-timed-text.txt
In-Reply-To: <[email-masked]>
References: <[email-masked]>
	<[email-masked]>
	<[email-masked]>
	<[email-masked]>
	<[email-masked]>
	<[email-masked]> <[email-masked]>
	<[email-masked]>
Message-ID: <[email-masked]>

Hi Ned,

The word smithing looks fine and is say that we go with your proposal.

Ned Freed wrote:
> 
> At one point I suggest it might be appropriate to map the U bit to a 
> charset
> parameter. Does this make any sense to do?
> 

I would say no. If there was a possibility to move beyond UTF-8 and 
UTF-16 I would probably agree. However as these are the only charsets 
allowed and both are mandatory I don't see that it would provide any 
benefit at all.

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]  Thu Jun  2 18:11:36 2005
From: ned.freed at mrochek.com (Ned Freed)
Date: Thu Jun  2 18:21:05 2005
Subject: [AVT] Re: Request to review media type in AVT working group last
	call:  draft-ietf-avt-rtp-3gpp-timed-text.txt
In-Reply-To: "Your message dated Thu, 02 Jun 2005 08:47:24 -0700"
	<p06230595bec4d9ca9254@[17.202.35.52]>
References: <[email-masked]>
	<[email-masked]> <[email-masked]>
	<[email-masked]>
	<[email-masked]>
	<[email-masked]> <[email-masked]>
	<p06230595bec4d9ca9254@[17.202.35.52]>
Message-ID: <[email-masked]>

> I'd like to push back gently on the change from 'text' to 'video',
> just to test the waters.

> The media types 'video' and 'audio' express what you *get* if you
> decode the stream, not how it is *encoded*.  They're not call 'float'
> or 'integer' or 'huffman', for example.  Yet for some reason we want
> to reserve the media type 'text' for those that express their
> encoding in printable text, without regard for what they are
> expressing;  this seems inconsistent.

No, that's not it at all. The restrictions on the text type have to do with the
nature of the underlying data, not with how it is encoded. For example, there's
plenty of use of text types, including text/plain, that requires binary
encoding and cannot be accomodated by either 7bit or 8bit encodings.

There are, however, more restrictions on text that then are on other top-level
types. The fact that there are more restrictions may seem inconsistent, but
that's how this stuff was defined long ago and it is way too late to change it.

> I don't believe that
> everything expressed in say XML ought to be considered a 'text' media
> type, for example.

It's more likely that *nothing* expressed in XML would be considered to
be a text media type.

				Ned
>From [email-masked]  Thu Jun  2 18:21:26 2005
From: ned.freed at mrochek.com (Ned Freed)
Date: Thu Jun  2 18:24:17 2005
Subject: [AVT] Re: Request to review media type in AVT working group last
	call: draft-ietf-avt-rtp-3gpp-timed-text.txt
In-Reply-To: "Your message dated Thu, 02 Jun 2005 17:06:42 +0200"
	<[email-masked]>
References: <[email-masked]>
Message-ID: <[email-masked]>

> Hi Ned,

> Thanks for the comments and enhancements.  Agreed stuff has been cut...

> > At one point I suggest it might be appropriate to map the U
> > bit to a charset parameter. Does this make any sense to do?

> Sorry, I am not sure what you mean with that.  DO you mean to change the name of the field or the field in the payload format?

My understanding is that it is common practice when defining AVT media types
to say "this media type has associated with it parameter foo, parameter
foo is mapped in the following way to such and such fields in SDP".

My question was whether or not it made sense to map the U bit (which states
whether the underlying text in the media type is utf-8 or utf-16) to a
corresponding charset parameter with values of utf-8 and utf-16 (or whatever
utf-16 endian variant is appropriate), and if not, why not.

				Ned
>From [email-masked]  Thu Jun  2 18:24:48 2005
From: singer at apple.com (Dave Singer)
Date: Thu Jun  2 18:25:32 2005
Subject: [AVT] Re: Request to review media type in AVT working group
 last 	call:  draft-ietf-avt-rtp-3gpp-timed-text.txt
In-Reply-To: <[email-masked]>
References: <[email-masked]>
	<[email-masked]> <[email-masked]>
	<[email-masked]>
	<[email-masked]> <[email-masked]>
	<[email-masked]> <p06230595bec4d9ca9254@[17.202.35.52]>
	<[email-masked]>
Message-ID: <p062305a3bec4e32ec5e7@[17.202.35.52]>

At 9:11  -0700 2/06/05, Ned Freed wrote:
>>I'd like to push back gently on the change from 'text' to 'video',
>>just to test the waters.
>
>>The media types 'video' and 'audio' express what you *get* if you
>>decode the stream, not how it is *encoded*.  They're not call 'float'
>>or 'integer' or 'huffman', for example.  Yet for some reason we want
>>to reserve the media type 'text' for those that express their
>>encoding in printable text, without regard for what they are
>>expressing;  this seems inconsistent.
>
>No, that's not it at all. The restrictions on the text type have to 
>do with the
>nature of the underlying data, not with how it is encoded. For 
>example, there's
>plenty of use of text types, including text/plain, that requires binary
>encoding and cannot be accomodated by either 7bit or 8bit encodings.
>
>There are, however, more restrictions on text that then are on other top-level
>types. The fact that there are more restrictions may seem inconsistent, but
>that's how this stuff was defined long ago and it is way too late to 
>change it.
>
>>I don't believe that
>>everything expressed in say XML ought to be considered a 'text' media
>>type, for example.
>
>It's more likely that *nothing* expressed in XML would be considered to
>be a text media type.
>
>				Ned

Thanks, but now I am lost.  Why is this a 'video' stream and not a 
'text' stream, then?
-- 
David Singer
Apple Computer/QuickTime
>From [email-masked]  Thu Jun  2 18:25:41 2005
From: ned.freed at mrochek.com (Ned Freed)
Date: Thu Jun  2 18:28:13 2005
Subject: [AVT] Re: Request to review media type in AVT working group last
 call: draft-ietf-avt-rtp-3gpp-timed-text.txt
In-Reply-To: "Your message dated Thu, 02 Jun 2005 18:16:06 +0200"
	<[email-masked]>
References: <[email-masked]>
	<[email-masked]> <[email-masked]>
	<[email-masked]>
	<[email-masked]>
	<[email-masked]> <[email-masked]>
	<[email-masked]> <[email-masked]>
Message-ID: <[email-masked]>

> Hi Ned,

> The word smithing looks fine and is say that we go with your proposal.

> Ned Freed wrote:
> >
> > At one point I suggest it might be appropriate to map the U bit to a
> > charset
> > parameter. Does this make any sense to do?
> >

> I would say no. If there was a possibility to move beyond UTF-8 and
> UTF-16 I would probably agree. However as these are the only charsets
> allowed and both are mandatory I don't see that it would provide any
> benefit at all.

Then why do you need the U bit?

Let me be clear here. I have no problem with not defining the parameter, but
I don't understand why the number of charsets involved forms a criteria
for whether or not it is needed. I'm just trying to understand a bit more
about the nature of the underlying transport, I guess.

				Ned
>From [email-masked]  Thu Jun  2 17:47:24 2005
From: singer at apple.com (Dave Singer)
Date: Thu Jun  2 18:29:01 2005
Subject: [AVT] Re: Request to review media type in AVT working group last
 call:  draft-ietf-avt-rtp-3gpp-timed-text.txt
In-Reply-To: <[email-masked]>
References: <[email-masked]>
	<[email-masked]> <[email-masked]>
	<[email-masked]>
	<[email-masked]> <[email-masked]>
	<[email-masked]>
Message-ID: <p06230595bec4d9ca9254@[17.202.35.52]>

I'd like to push back gently on the change from 'text' to 'video', 
just to test the waters.

The media types 'video' and 'audio' express what you *get* if you 
decode the stream, not how it is *encoded*.  They're not call 'float' 
or 'integer' or 'huffman', for example.  Yet for some reason we want 
to reserve the media type 'text' for those that express their 
encoding in printable text, without regard for what they are 
expressing;  this seems inconsistent.  I don't believe that 
everything expressed in say XML ought to be considered a 'text' media 
type, for example.  The fact that an (enthusiastic) human might be 
able to read the text is kinda irrelevant (especially given how 
readable much machine-generated HTML and XML is, in fact).

At 16:23  +0200 2/06/05, Magnus Westerlund wrote:
>Hi,
>
>After having discussed this with the authors and Colin we have the 
>below proposed changes. So does this resolve the issues with the 
>media type and the confusing statement around TCP?
>
>Please note that the WG last call ends today.
>
>PROPOSED CHANGES:
>
>- Section 2.1, p.4: remove paragraph that causes confusion
>
>REMOVED:
>
>     The scope of the 3GPP PSS specification (in the following referred to
>     as PSS) includes both downloading and streaming of multimedia content
>     over 3G packet-switched networks.  PSS adopts multimedia codecs such
>     as MPEG-4 Visual [22], AMR wide-band [23] or MPEG-4 AAC [24] for
>     encoding content.  Other protocols like RTSP [15] for session set-up
>     and control, or SMIL [9] for handling presentation layouts.  For
>     transport, HTTP over TCP is used for downloading and RTP for
>     streaming.
>
>
>- Section 8:
>OLD:
>     The media subtype for the 3GPP Timed Text codec is allocated from the
>     IETF tree.  The top-level media type under which this payload format
>     is registered is 'text'.
>
>     The receiver MUST ignore any unrecognized parameter.
>
>     Media type: text
>
>NEW:
>     The media subtype for the 3GPP Timed Text codec is allocated from the
>     standards tree.  The top-level media type under which this payload
>     format is registered is 'video'. This registration is done using the
>     template defined in [34] and following RFC 3555 [33].
>
>     The receiver MUST ignore any unrecognized parameter.
>
>     Media type: video
>
>
>OLD:
>     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.
>
>
>NEW:
>     Encoding considerations:
>
>          This media type is framed (see section 4.8 in [34]) and 
>partially contains binary data.
>
>     Restrictions on usage:
>
>	   This media type depends on RTP framing, and hence is only 
>defined for
>     	   transfer via RTP [RFC 3550]. Transport within other 
>framing protocols
>     	   is not defined at this time.
>
>OLD:
>     Interoperability considerations:
>
>          The 3GPP Timed Text media format and its storage 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
>          timed text media format in a backwards-compatible way, e.g. new
>          modifier boxes or extensions to the sample descriptions.  The
>          payload format defined in RFCXXXX allows for such extensions.
>          For future 3GPP Releases of the Timed Text Format, the parameter
>          "sver" is used to identify the exact specification used.
>
>NEW:
>     Interoperability considerations:
>
>          The 3GPP Timed Text media format and its file storage is
>          specified in Release 6 of 3GPP TS 26.245 "Transparent end-to-end
>          packet switched streaming service (PSS); Timed Text Format
>          (Release 6)".  Note also that 3GPP may in future Releases
>          specify extensions or updates to the timed text media format in
>          a backwards-compatible way, e.g. new modifier boxes or
>          extensions to the sample descriptions.  The payload format
>          defined in RFCXXXX allows for such extensions.  For future 3GPP
>          Releases of the Timed Text Format, the parameter "sver" is used
>          to identify the exact specification used.
>
>          The defined storage format for 3GPP Timed Text format is 
>the 3GPP File
>	   Format (3GP) [35].  3GP files may be transferred using the 
>media type
>          video/3gpp as registered by RFC 3839 [36].  The 3GPP File 
>Format is a container
>          file that may contain, e.g., audio and video which may be 
>synchronized with the
>          3GPP Timed Text.
>
>
>- Section 12.2: New informative references
>
>NEW:
>
>     [33] Casner, S. and P. Hoschka, "MIME Type Registration of RTP
>          Payload Formats", RFC 3555, July 2003.
>
>     [34] Freed, N. and J. Klensin, "Media Type Specifications and
>          Registration Procedures", draft-freed-media-type-reg-04,
>          April 2005.
>
>     [35] Transparent end-to-end packet switched streaming service (PSS);
>          3GPP file format (3GP) (Release 6), TS 26.244 V6.3. March 2005.
>
>     [36] Castagno, R. and D. Singer, "MIME Type Registrations for 3rd
>          Generation Partnership Project (3GPP) Multimedia files",
>          RFC 3839, July 2004.
>
>
>Magnus Westerlund wrote:
>>Hi,
>>
>>I will try to summarize the proposed edits I and the authors will 
>>try to incorporate into a updated proposal on how to resolve this 
>>specific case. The general topic on how to update the RTP 
>>registration of RTP payload format & encoding names in the future 
>>remains. But we have deadlines and needs to produce something now.
>>
>>- We change the top-level media type to video. It is not my 
>>personal preference, but the media type is a borderline case of 
>>being video and some in the AVT WG have argued for it becoming 
>>video.
>>- We clarify the restriction on usage that applies and why this is 
>>only intended for RTP.
>>- We clarify that the encoding consideration for the payloads are 
>>that they are framed and contain binary information in certain 
>>parts.
>>- Include the already proposed changes regarding references, etc.
>>
>>If you think I have forgotten any changes necessary to get at least 
>>this media type into acceptable shape, please comment.
>>
>>We will send the updated proposal for the media type registration 
>>for your review as soon as we have word smithed the text.
>>
>>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]
>>
>
>
>--
>
>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]
>
>_______________________________________________
>Audio/Video Transport Working Group
>[email-masked]
>https://www1.ietf.org/mailman/listinfo/avt

-- 
David Singer
Apple Computer/QuickTime
>From [email-masked]  Thu Jun  2 18:32:45 2005
From: ned.freed at mrochek.com (Ned Freed)
Date: Thu Jun  2 18:38:00 2005
Subject: [AVT] Re: Request to review media type in AVT working group last
	call:  draft-ietf-avt-rtp-3gpp-timed-text.txt
In-Reply-To: "Your message dated Thu, 02 Jun 2005 09:24:48 -0700"
	<p062305a3bec4e32ec5e7@[17.202.35.52]>
References: <[email-masked]>
	<[email-masked]> <[email-masked]>
	<[email-masked]>
	<[email-masked]>
	<[email-masked]> <[email-masked]>
	<p06230595bec4d9ca9254@[17.202.35.52]>
	<[email-masked]>
	<p062305a3bec4e32ec5e7@[17.202.35.52]>
Message-ID: <[email-masked]>

> Thanks, but now I am lost.  Why is this a 'video' stream and not a
> 'text' stream, then?

Presumably because the intent is to display this as video. The rules for what
can fit under video are pretty loose; this is certainly an acceptable use of
the video top-level type. Text, OTOH, is usually thought of as a series of
lines and not as a stream of characters.

My (incorrect) understanding was that video was an unacceptable choice due to
SDP constraints. Without that constraint I would have been pushing for this
to go under video from the beginning.

				Ned
>From [email-masked]  Thu Jun  2 18:47:48 2005
From: chris at w3.org (Chris Lilley)
Date: Thu Jun  2 18:48:01 2005
Subject: [AVT] Re: Request to review media type in AVT working group
	last call: draft-ietf-avt-rtp-3gpp-timed-text.txt
In-Reply-To: <[email-masked]>
References: <[email-masked]>
	<[email-masked]> <[email-masked]>
	<[email-masked]>
	<[email-masked]>
	<[email-masked]> <[email-masked]>
	<p06230595bec4d9ca9254@[17.202.35.52]>
	<[email-masked]>
	<p062305a3bec4e32ec5e7@[17.202.35.52]>
	<[email-masked]>
Message-ID: <[email-masked]>

On Thursday, June 2, 2005, 6:32:45 PM, Ned wrote:

>> Thanks, but now I am lost.  Why is this a 'video' stream and not a
>> 'text' stream, then?

NF> Presumably because the intent is to display this as video. The rules for what
NF> can fit under video are pretty loose; this is certainly an acceptable use of
NF> the video top-level type. Text, OTOH, is usually thought of as a series of
NF> lines and not as a stream of characters.

Text is certainly a sequence of characters, which may or may not be
preformatted into 'lines'. Other characteristics of text are that
spell-checking and translation to a different language are reasonable
things to do with it.

Whether the text/* top level type is like that is another matter again,
of course;  that type having sufficient problems that it should really
not be used for anything much beyond text/plain; charset=us-ascii.

NF> My (incorrect) understanding was that video was an unacceptable choice due to
NF> SDP constraints. Without that constraint I would have been pushing for this
NF> to go under video from the beginning.

Timed text, because of its time dependent nature, is an arguable fit for
video (but something of a stretch).

There is probably a need for a more reasonably defined top level type,
like textual/* or something, but the timescales and amount of effort to
establish such a thing are non-negligible.

-- 
 Chris Lilley                    mailto:[email-masked]
 Chair, W3C SVG Working Group
 W3C Graphics Activity Lead

From: magnus.westerlund at ericsson.com (Magnus Westerlund)
Date: Thu Jun  2 16:23:33 2005
Subject: Request to review media type in AVT working group last call: draft-ietf-avt-rtp-3gpp-timed-text.txt
In-Reply-To: <[email-masked]>
References: <[email-masked]>	<[email-masked]>	<[email-masked]>	<[email-masked]>	<[email-masked]> <[email-masked]>
Message-ID: <[email-masked]>

Hi,

After having discussed this with the authors and Colin we have the below 
proposed changes. So does this resolve the issues with the media type 
and the confusing statement around TCP?

Please note that the WG last call ends today.

PROPOSED CHANGES:

- Section 2.1, p.4: remove paragraph that causes confusion

REMOVED:

     The scope of the 3GPP PSS specification (in the following referred to
     as PSS) includes both downloading and streaming of multimedia content
     over 3G packet-switched networks.  PSS adopts multimedia codecs such
     as MPEG-4 Visual [22], AMR wide-band [23] or MPEG-4 AAC [24] for
     encoding content.  Other protocols like RTSP [15] for session set-up
     and control, or SMIL [9] for handling presentation layouts.  For
     transport, HTTP over TCP is used for downloading and RTP for
     streaming.

- Section 8:
OLD:
     The media subtype for the 3GPP Timed Text codec is allocated from the
     IETF tree.  The top-level media type under which this payload format
     is registered is 'text'.

     The receiver MUST ignore any unrecognized parameter.

     Media type: text

NEW:
     The media subtype for the 3GPP Timed Text codec is allocated from the
     standards tree.  The top-level media type under which this payload
     format is registered is 'video'. This registration is done using the
     template defined in [34] and following RFC 3555 [33].

     The receiver MUST ignore any unrecognized parameter.

     Media type: video

OLD:
     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.

NEW:
     Encoding considerations:

          This media type is framed (see section 4.8 in [34]) and 
partially contains binary data.

     Restrictions on usage:

	   This media type depends on RTP framing, and hence is only defined for
      	   transfer via RTP [RFC 3550]. Transport within other framing 
protocols
      	   is not defined at this time.

OLD:
     Interoperability considerations:

          The 3GPP Timed Text media format and its storage 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
          timed text media format in a backwards-compatible way, e.g. new
          modifier boxes or extensions to the sample descriptions.  The
          payload format defined in RFCXXXX allows for such extensions.
          For future 3GPP Releases of the Timed Text Format, the parameter
          "sver" is used to identify the exact specification used.

NEW:
     Interoperability considerations:

          The 3GPP Timed Text media format and its file storage is
          specified in Release 6 of 3GPP TS 26.245 "Transparent end-to-end
          packet switched streaming service (PSS); Timed Text Format
          (Release 6)".  Note also that 3GPP may in future Releases
          specify extensions or updates to the timed text media format in
          a backwards-compatible way, e.g. new modifier boxes or
          extensions to the sample descriptions.  The payload format
          defined in RFCXXXX allows for such extensions.  For future 3GPP
          Releases of the Timed Text Format, the parameter "sver" is used
          to identify the exact specification used.

          The defined storage format for 3GPP Timed Text format is the 
3GPP File
	   Format (3GP) [35].  3GP files may be transferred using the media type
          video/3gpp as registered by RFC 3839 [36].  The 3GPP File 
Format is a container
          file that may contain, e.g., audio and video which may be 
synchronized with the
          3GPP Timed Text.

- Section 12.2: New informative references

NEW:

     [33] Casner, S. and P. Hoschka, "MIME Type Registration of RTP
          Payload Formats", RFC 3555, July 2003.

     [34] Freed, N. and J. Klensin, "Media Type Specifications and
          Registration Procedures", draft-freed-media-type-reg-04,
          April 2005.

     [35] Transparent end-to-end packet switched streaming service (PSS);
          3GPP file format (3GP) (Release 6), TS 26.244 V6.3. March 2005.

     [36] Castagno, R. and D. Singer, "MIME Type Registrations for 3rd
          Generation Partnership Project (3GPP) Multimedia files",
          RFC 3839, July 2004.

Magnus Westerlund wrote:
> Hi,
> 
> I will try to summarize the proposed edits I and the authors will try to 
> incorporate into a updated proposal on how to resolve this specific 
> case. The general topic on how to update the RTP registration of RTP 
> payload format & encoding names in the future remains. But we have 
> deadlines and needs to produce something now.
> 
> - We change the top-level media type to video. It is not my personal 
> preference, but the media type is a borderline case of being video and 
> some in the AVT WG have argued for it becoming video.
> - We clarify the restriction on usage that applies and why this is only 
> intended for RTP.
> - We clarify that the encoding consideration for the payloads are that 
> they are framed and contain binary information in certain parts.
> - Include the already proposed changes regarding references, etc.
> 
> If you think I have forgotten any changes necessary to get at least this 
> media type into acceptable shape, please comment.
> 
> We will send the updated proposal for the media type registration for 
> your review as soon as we have word smithed the text.
> 
> 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]
> 

-- 

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]  Thu Jun  2 16:29:21 2005
From: murata at hokkaido.email.ne.jp (MURATA Makoto)
Date: Thu Jun  2 16:29:36 2005
Subject: Registration of MIME media type application/rnc
Message-ID: <[email-masked]>

This is a request for registration in the standard tree.

The compact syntax for RELAX NG (a schema language for XML) will be
published as a Final Draft Amendment (FDAM) of ISO/IEC 19757-4 soon.
The FDAM will contain this registation information.  If this FDAM
passes a two-month FDAM ballot, it will become an Amendment of ISO/IEC
197575-4.  Since this FDAM ballot does not allow any technical
comments and many member bodies of ISO/IEC JTC1 simply say yes, the
FDAM is extremely likely to pass the ballot.  The compact syntax 
was first published as an OASIS committee specification.

     MIME media type name: application

     MIME subtype name: rnc

     Required parameters: none

     Optional parameters: none

     Encoding considerations: UTF-8 or UTF-16 shall be used for  this media type. 

     Security considerations:  When the RELAX NG validator retrieves a schema 
in the RELAX NG compact syntax, it may further retrieve external schemas that 
are referenced from the schema directly or indirectly.  Although the RELAX NG
validator is required not to retrieve an infinite number of schemas, a large 
number of external schemas may be retrieved, thus wasting the network, disk, and CPU 
power.

     Interoperability considerations: 
         RELAX NG has been widely used as an XML schema language.  
	  A notable example is the Open Document specification of OASIS.

     Published specification:

     ISO/IEC 19757-2, Document Schema Definition Language (DSDL) 
     Part 2 - Regular-grammar-based validation -- RELAX NG, 
     Amendment 1: Compact Syntax

     OASIS Committee Specification, RELAX NG Compact Syntax
     21 November 2002

     Applications which use this media type: 
		   validators, schema authoring tools, and so forth

     Additional information:

       Magic number(s): none
       File extension(s): rnc
       Macintosh File Type Code(s): "TEXT"

     Person & email address to contact for further information:

     MURATA Makoto (FAMILY Given), International University of Japan,
     [email-masked]

     Intended usage: COMMON

     Author/Change controller: ISO/IEC JTC1/SC34
-- 
MURATA Makoto <[email-masked]>