- Ietf-types - example.com

RE: [AVT] Re: Comments on draft-freed-media-types-reg-01.txt
by ned.freed＠mrochek.com 09 Sep '04

09 Sep '04

> > > When one has limited usage, like say "only for usage in RTP" I think > > > there are need to consider some wider interpretation of what "to some > > > extent readable" means. We had an example in the 3GPP timed text > > > discussion, where the RTP payload format consists of embedded UTF-8 or > > > UTF-16 strings in an otherwise binary format. However for RTP that is > > > the common case. Should such any clarification on the performance of > > > such consideration be written into this spec or do it belong to a > > > further registration document in relation do a specific domain of usage? > > I would say it belongs in the registration document. > does such a clarification belong under "Encoding considerations" or under > "Restrictions on usage"? Until now most payload formats included a sentece > like "This type is only defined for transfer via RTP." under encoding > considerations. In this case, is it not more appropriate to do this under > "Restrictions on usage"? Encoding considerations is really intended to be a single value chosen from a list. As such, this really belongs under restrictions on usage. > This is how it would look like in our case: > "Encoding considerations: > RTP payloads conforming to this payload format do not comply with the strict > rules for registration under the 'text' top-level MIME type, as outlined in > RFC 2026 and its revision RFCYYYY []. Wrong RFC # here,, I believe. Additionally, I don't see this as a case of noncompliance with the revised rules. A better approach would be to say that this type is incompatible with use of text media types in other protocols. > The reason for this is that the RTP > client must, at least, understand the payload format fields (in binary) in > order to decode the timed text contents (partly text strings, partly > binary). This binary information is not considered 'directly readable' > without 'special software' as required for 'text' subtypes (in contrast to > text strings). Around the 60th IETF it was decided to relax these rules for > RTP payload formats. In particular, it was allowed to register RTP payload > formats under the 'text' top-level type (if appropriate) as long as the > domain of applicability of the format is clearly specified (e.g. only for > transmission using RTP). This payload format complies with these 'relaxed' > rules. I don't think having this sort of historical note in a registration is appropriate either. Ned

1 0

Re: draft-freed-mime-p4-04 is apparently superseded by..
by Jeff.Hodges＠KingsMountain.com 07 Sep '04

07 Sep '04

> http://www.ietf.org/html.charters/avt-charter.html So just fwiw, the AVT WG's mailing list archives require a small amount of grovelling to find (for me anyways). They aren't pointed to by the above AVT charter page, for instance. This appears to be them.. ftp://ftp.ietf.org/ietf-mail-archive/avt/ ..and current discussion is here.. ftp://ftp.ietf.org/ietf-mail-archive/avt/current JeffH

1 0

RE: [AVT] Comments on draft-freed-media-types-reg-01.txt
by Allison, Art 07 Sep '04

07 Sep '04

Comment: One very widely deployed <though for a single purpose in DTV> standard for rich text display that has not been mentioned is CEA 708 C. The media types standard seems to be able to support different encodings of rich text and this is a good thing. I also urge that rich text formats have identification codes at the highest possible level. Art ::{)> Arthur W. Allison Director, Science & Technology National Association of Broadcasters 202 429 5418 -----Original Message----- From: Magnus Westerlund [mailto:magnus.westerlund@ericsson.com] Sent: Tuesday, September 07, 2004 10:40 AM To: Ned Freed; John C Klensin; 'ietf-types(a)iana.org' Cc: IETF AVT WG Subject: [AVT] Comments on draft-freed-media-types-reg-01.txt Hi Ned and John, I have now reviewed your document and have some comments and questions. MW1: Section 3.4: Based on all arguments I have heard about any experimental tree, they should be strongly discouraged to be used at all. The motivation, is that if one defines a experimental type in a test application. The application becomes a success, suddenly you have an deployed base of something you didn't intended to. Then trying to change the type leads to interoperability issues, and may in best case result in usage of two different names for the same type. I think it might be better to recommend that one simply uses a real type, and tries to register it as soon as possible. MW2: Section 4.2.1, third paragraph: "Beyond plain text, there are many formats for representing what might be known as "rich text". An interesting characteristic of many such representations is that they are to some extent readable even without the software that interprets them. It is useful, then, to distinguish them, at the highest level, from such unreadable data as images, audio, or text represented in an unreadable form. In the absence of appropriate interpretation software, it is reasonable to show subtypes of "text" to the user, while it is not reasonable to do so with most non textual data. Such formatted textual data should be represented using subtypes of "text"." When one has limited usage, like say "only for usage in RTP" I think there are need to consider some wider interpretation of what "to some extent readable" means. We had an example in the 3GPP timed text discussion, where the RTP payload format consists of embedded UTF-8 or UTF-16 strings in an otherwise binary format. However for RTP that is the common case. Should such any clarification on the performance of such consideration be written into this spec or do it belong to a further registration document in relation do a specific domain of usage? ME3: Section 4.3: Parameters only applicable to a specific domain of usage? Certain types will be (are) registered for several domain of usage, however the different domain may require that different parameters are used. I can give you an example in RFC 3267 that has quite many parameters for RTP usage, but none for the file format. How is it supposed to be indicated that this is the case? MW4: Section 4.3: Syntax rules for parameters? I think the syntax (ABNF) definition of the parameter values need to be properly defined. Otherwise it is hard to make any assumption about what is potential to be used in protocols. I think it also needs to take the current used protocols like, mail, HTTP, SDP into account. MW5: Section 4.9: I think the draft hints in section 4.2 that with certain limited usage, another document may further define how the media types should be treated, and what to think of. However I think it might be worth being a bit more clear on what such a document should do. In addition to defining any further restrictions on registration, I think it should define a "name" for this application to be used in the "Restriction on Usage" heading in the template. MW6: I think further clarification on the coupling between the "intended usage" and the "Restriction on usage" is needed. For example, is one allowed to use "Common" when the restriction of usage says: Only for use in RTP? And is the classification of what is common, limited usage, or obsolete depending on the domain? MW7: Section 10: Actually I find the labeling of "Author/Change controller:" a bit confusing. In my view there can be a big difference between Author and Change controller. For example in my proposed registration of audio/rtp.enc.aescm128 where I am the author and the direct recipient of any comments at the initial stage. However the change control over this type belongs to 3GPP. And although the contact person exist, that might be even a third entity in some cases. Might it not be wise to split them into separate cases to clarify this? Cheers Magnus Westerlund Multimedia Technologies, Ericsson Research EAB/TVA/A ---------------------------------------------------------------------- Ericsson AB | Phone +46 8 4048287 Torshamsgatan 23 | Fax +46 8 7575550 S-164 80 Stockholm, Sweden | mailto: magnus.westerlund(a)ericsson.com _______________________________________________ Audio/Video Transport Working Group avt(a)ietf.org https://www1.ietf.org/mailman/listinfo/avt

1 0

Re: Media Types in 3GPP Timed text draft (was: RE: [AVT] RTP andMediaTypes)
by Magnus Westerlund 07 Sep '04

07 Sep '04

Dave Singer wrote: > But text/html is not only rendering text, it is expressed in text. 3GPP > renders text, but it is expressed in binary. > Not really. In my view timed text is expressed in binary framing and UTF-8 or UTF-16 encoded text (which might be argued is binary). But the framing issues, are true for basically all RTP payload formats. You need to understand the RTP payload format to do anything. Cheers Magnus Westerlund Multimedia Technologies, Ericsson Research EAB/TVA/A ---------------------------------------------------------------------- Ericsson AB | Phone +46 8 4048287 Torshamsgatan 23 | Fax +46 8 7575550 S-164 80 Stockholm, Sweden | mailto: magnus.westerlund(a)ericsson.com

2 1

Re: Media Types in 3GPP Timed text draft (was: RE: [AVT] RTP andMediaTypes)
by Colin Perkins 07 Sep '04

07 Sep '04

Jose, On 7 Sep 2004, at 12:56, Jose Rey wrote: >> -----Original Message----- >> From: Colin Perkins [mailto:csp@csperkins.org] >> Sent: Tuesday, September 07, 2004 12:03 PM >> To: Jose Rey >> Cc: IETF AVT WG; Dave Singer; Magnus Westerlund; IETF-Types >> Subject: Re: Media Types in 3GPP Timed text draft (was: RE: [AVT] RTP >> andMediaTypes) >> >> On 17 Aug 2004, at 14:42, Jose Rey wrote: >>> Dave and I have been discussing this offline and come to the >>> following >>> conclusions: >>> >>> 1.- it is not envisioned that the 3GPP Timed Text payload format will >>> be >>> used for applications such as instant messaging or text conversation, >>> which do not precise of text decoration for working properly, since >>> there are other more appropriate media types covering these usages, >>> like text/t140. Hence, video/ is enough. >> >> I agree that this is not likely to be used for instant messaging or >> text conversation, although I don't understand why that would be >> relevant? > > below.. > >> Is this fundamentally text or a video codec? If it's a video >> codec, it should be under "video/", otherwise under "text/". > > I think it is a video codec, since without the video capabilities > (modifiers) it would just provide the same services as , e.g., > conversational text=just plain timed text, for which it is not thought > to be used. There are other text formats that include formatting modifiers, for example "text/html". I don't understand why their presence would make this a video format. >>> 2.- we are not clear on what exactly means to "relax rules for media >>> registration under text/". I.e. is text/t140 an example of these >>> "relaxed" rules or does it comply with the traditional rules as per >>> rfc 2046? Does the relaxed rules just mean that besides text also >>> payload headers of that media type are udnerstood? >> >> My understanding is that the new rules are intended to allow formats >> such as 3GPP timed text to be registered under the text top-level >> media >> type, if appropriate, provided their domain of applicability is >> clearly >> specified (e.g. the domain of applicability might be that the type is >> defined for transfer via RTP only). > > The MIME subtype /3gpp-tt cannot be used for HTML download since for > that > purpose a 3gp file and therefore the video/3gp MIME type is used. So I > think this is indeed restricted to RTP. However, what is the gain of > doing that? My point was that, since this is restricted to transport via RTP, it can be registered under the "text" top-level media type. > Given the answer to the first question I think registering under > text/ would not be of any use? Why not? It would seem to be the natural home for a timed text format. Colin

3 2

Re: Media Types in 3GPP Timed text draft (was: RE: [AVT] RTP andMediaTypes)
by Colin Perkins 07 Sep '04

07 Sep '04

On 7 Sep 2004, at 13:54, Jose Rey wrote: ... >> There are other text formats that include formatting modifiers, for >> example "text/html". I don't understand why their presence would make >> this a video format. > > Ok, I was guiding myself more by the what I understood as type of apps. > However, just for my clarity: if we wouldn't use the "relaxed rules" > could I still use text/? Is text/t140 conformat to the 'traditional > rules'? None of the RTP payload formats -- not text, audio or video -- can be used with the 'traditional' rules. This is the reason why the MIME registration rules are being updated. >>>>> 2.- we are not clear on what exactly means to "relax rules for >>>>> media >>>>> registration under text/". I.e. is text/t140 an example of these >>>>> "relaxed" rules or does it comply with the traditional rules as per >>>>> rfc 2046? Does the relaxed rules just mean that besides text also >>>>> payload headers of that media type are udnerstood? >>>> >>>> My understanding is that the new rules are intended to allow formats >>>> such as 3GPP timed text to be registered under the text top-level >>>> media >>>> type, if appropriate, provided their domain of applicability is >>>> clearly >>>> specified (e.g. the domain of applicability might be that the type >>>> is >>>> defined for transfer via RTP only). >>> >>> The MIME subtype /3gpp-tt cannot be used for HTML download since for >>> that >>> purpose a 3gp file and therefore the video/3gp MIME type is used. >>> So I >>> think this is indeed restricted to RTP. However, what is the gain >>> of >>> doing that? >> >> My point was that, since this is restricted to transport via RTP, it >> can be registered under the "text" top-level media type. > > What I mean is what would be the use of having two, not one or the > other. The media type for the file format may well be different than that for the RTP payload format, if that's what you mean. Colin

2 1

Re: Media Types in 3GPP Timed text draft (was: RE: [AVT] RTP andMediaTypes)
by Magnus Westerlund 07 Sep '04

07 Sep '04

Hi Jose, See below. Jose Rey wrote: > > >>Is this fundamentally text or a video codec? If it's a video >>codec, it should be under "video/", otherwise under "text/". > > > I think it is a video codec, since without the video capabilities > (modifiers) it would just provide the same services as , e.g., > conversational text=just plain timed text, for which it is not thought to be > used. > I would argue that it is in fact text. It is Rich text, that has both different types of decoration, like colors and fonts, and also time based modifications, like karaoke markings. However it is in the bottom always text. It can't show anything else than the charsets from Unicode that is defined in section 5.3 of 3GPP TS 26.245. It is also readable with a minimal effort by simply extracting it from the RTP payload. I would think that basic extraction in complete text blocks is really equal to the capability of reading something with CAT when it comes to RTP. > >>>2.- we are not clear on what exactly means to "relax rules for media >>>registration under text/". I.e. is text/t140 an example of these >>>"relaxed" rules or does it comply with the traditional rules as per >>>rfc 2046? Does the relaxed rules just mean that besides text also >>>payload headers of that media type are udnerstood? >> >>My understanding is that the new rules are intended to allow formats >>such as 3GPP timed text to be registered under the text top-level media >>type, if appropriate, provided their domain of applicability is clearly >>specified (e.g. the domain of applicability might be that the type is >>defined for transfer via RTP only). >> > > > The MIME subtype /3gpp-tt cannot be used for HTML download since for that > purpose a 3gp file and therefore the video/3gp MIME type is used. So I > think this is indeed restricted to RTP. However, what is the gain of doing > that? Given the answer to the first question I think registering under > text/ would not be of any use? > I think there is a purpose of separating something that is of a different media type. It is clear that text and video might not be as well separated as video and audio. However there is some difference in what is needed to present text and video when it comes to devices. Text is generally much less complex, and do not require the same resolution, color support, etc., to be appropriately interpreted. Sure it can benefit from having the same capability, however not necessary to avoid losing information in many cases. Thus I would argue that there is a purpose to express that difference using different media types. A 3GPP timed text session is also a complementing medium to a video stream, or it may be the other way around, that video is complementing the text. So from an AVT perspective I would expect it common that you will actually have the video and timed text in different RTP sessions. This due to selectability, adaptation and pure simplicity in handling. However this is not really a argument either way for choosing text over video or vice versa. I do however agree with Dave that we should only select one media type. I was bringing up the potential usage of having two, simply to see if there is any merit. However I don't think there is any gain, only trouble on that road. Cheers Magnus Westerlund Multimedia Technologies, Ericsson Research EAB/TVA/A ---------------------------------------------------------------------- Ericsson AB | Phone +46 8 4048287 Torshamsgatan 23 | Fax +46 8 7575550 S-164 80 Stockholm, Sweden | mailto: magnus.westerlund(a)ericsson.com

1 0

Re: Media Types in 3GPP Timed text draft (was: RE: [AVT] RTP andMediaTypes)
by Colin Perkins 07 Sep '04

07 Sep '04

Jose, On 17 Aug 2004, at 14:42, Jose Rey wrote: > Dave and I have been discussing this offline and come to the following > conclusions: > > 1.- it is not envisioned that the 3GPP Timed Text payload format will > be > used for applications such as instant messaging or text conversation, > which do not precise of text decoration for working properly, since > there are other more appropriate media types covering these usages, > like text/t140. Hence, video/ is enough. I agree that this is not likely to be used for instant messaging or text conversation, although I don't understand why that would be relevant? Is this fundamentally text or a video codec? If it's a video codec, it should be under "video/", otherwise under "text/". > 2.- we are not clear on what exactly means to "relax rules for media > registration under text/". I.e. is text/t140 an example of these > "relaxed" rules or does it comply with the traditional rules as per > rfc 2046? Does the relaxed rules just mean that besides text also > payload headers of that media type are udnerstood? My understanding is that the new rules are intended to allow formats such as 3GPP timed text to be registered under the text top-level media type, if appropriate, provided their domain of applicability is clearly specified (e.g. the domain of applicability might be that the type is defined for transfer via RTP only). Colin

3 2

Re: draft-freed-mime-p4-04 is apparently superseded by..
by Jeff.Hodges＠KingsMountain.com 06 Sep '04

06 Sep '04

> Sorry, since this came up during IESG document approval discussions it has > mostly happened off-list. However, there has been plenty of discussions of this > and other, similar media types on the AVT list; you might want to read over > those archives to get a sense of where this is coming from. you mean this "AVT"... http://www.ietf.org/html.charters/avt-charter.html ..yes? JeffH

2 1

Re: Please review: DRAFT Reg of application/samlassertion+xml
by Jeff.Hodges＠KingsMountain.com 06 Sep '04

06 Sep '04

> I'm a bit concerned that this might be read as asserting that a > application/samlassertion+xml object must use the specific namespace prefix > "saml", rather than any namesp[ace prefix that maps to a SAML namespace URI. good catch, thanks. > Assuming this is not being claimed, I'd suggest: > [[ > Additional information: > > Magic number(s): > In general, the same as for application/xml [RFC3023]. In > particular, the XML root element of the returned object will be > <saml:Assertion>, where "saml" as any namespace prefix that maps > to a version-specific SAML assertion namespace URI, as defined by > the appropriate SAML "core" specification (see bibliography). > In the case of SAMLv2.0, the root element of the returned object > may be either <saml:Assertion> or <saml:EncryptedAssertion>, > where "saml" is a prefix that maps to the SAMLv2.0 assertion > namespace URI: urn:oasis:names:tc:SAML:2.0:assertion. > ]] how 'bout this build: Magic number(s): In general, the same as for application/xml [RFC3023]. In particular, the XML root element of the returned object will be <saml:Assertion>, where "saml" represents any XML namespace prefix that maps to a version-specific SAML assertion XML namespace URI, as defined by the appropriate version-specific SAML "core" specification (see bibliography). With SAMLv2.0 specifically, the root element of the returned object may be either <saml:Assertion> or <saml:EncryptedAssertion> , where "saml" is an XML namspace prefix that maps to the SAMLv2.0 assertion namespace URI: urn:oasis:names:tc:SAML:2.0:assertion. ? thanks, JeffH

1 0