Subject: Minor error in CCXML media type registration.
From: chris at w3.org (Chris Lilley)
Date: Tue Jan 3 16:22:49 2006

Hello www-voice,

In Appendix I - CCXML Media Type
http://www.w3.org/TR/2004/WD-ccxml-20040430/#ccxml-mime-definition

the sentence

>> Several CCXML instructions may cause arbitrary URIs to be referenced.
>> In this case, the security issues of RFC1738, section 6, should be
>> considered.

should instead reference RFC 2396, section 7 which updates (and largely
replaces) RFC 1738.

2396 is itself being updated, but is not yet an RFC.

http://www.ietf.org/rfc/rfc2396.txt
http://gbiv.com/protocols/uri/rev-2002/rfc2396bis.html

-- 
 Chris Lilley                    mailto:[email-masked]
 Chair, W3C SVG Working Group
 Member, W3C Technical Architecture Group

From: ned.freed at mrochek.com ([email-masked])
Date: Sun Sep 26 07:16:58 2004
Subject: [AVT] Re: Comments on draft-freed-media-types-reg-01.txt
In-Reply-To: "Your message dated Sat, 25 Sep 2004 18:52:16 +0100" <[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]>

> On 24 Sep 2004, at 16:29, [email-masked] wrote:
> >> > And interop problems are likely if files are produced without the
> >> > magic number
> >> > and software that checks the magic numbers is used. Similarly,
> >> > treating the
> >> > magic number as audio data could, depending on the codec involved
> >> have
> >> > some
> >> > interesting effects.
> >
> >> Of course, but so what? One clearly needs software that understands
> >> the
> >> format, and if you produce files without the magic number they're not
> >> conforming.
> >
> > Sure they are. Your entire entire goal here is to use the same label
> > for two different formats, one with the magic number and one without.

> No, not within the same domain. I'm intending that the format that's
> limited to use when transported in an unreliable sequence of RTP
> datagrams has a different header than the format for use when
> transported by a reliable byte stream, but that's a different domain of
> applicability. It's certainly should not be legal to use the headers
> for the byte stream format in RTP, or vice-versa.

You're assuming that material can be constrained to a single domain. We have
ample experience that (a) such assumptions are routinely voilated and (2) we
have absolutely no competence at predicting when violations will occur.

> > This admits the possibility of two conformant pieces of software
> > failing to interoperate, and that's not good.
> >
> >> > Now, nothing says you cannot use a naming convention of some sort
> >> to link the
> >> > two types in some way. But IMO they really need to be two different
> >> types.
> >
> >> In which case we have two different and separate namespaces, trying to
> >> share the same registry. This, IMHO, doesn't make sense.
> >
> > No, what we have is a single registry for specific formats and a way to
> > link formats that are in some way related.

> But that link is the media type name, with the domain of applicability
> to prevent interoperability problems. This is done in RFCs 3267 and
> 3558, for example, and doesn't appear to have caused problems.

Two examples where problems haven't yet arisen in a specific domain doesn't
mean much. There are hundreds of media types and who knows how many domains of
applicability, and the rules have to work for all of them.

				Ned
>From [email-masked]  Thu Sep 30 01:55:46 2004
From: chris at w3.org (Chris Lilley)
Date: Thu Sep 30 01:55:52 2004
Subject: Minor error in CCXML media type registration.
Message-ID: <[email-masked]>

Hello www-voice,

In Appendix I - CCXML Media Type
http://www.w3.org/TR/2004/WD-ccxml-20040430/#ccxml-mime-definition

the sentence

>> Several CCXML instructions may cause arbitrary URIs to be referenced.
>> In this case, the security issues of RFC1738, section 6, should be
>> considered.

should instead reference RFC 2396, section 7 which updates (and largely
replaces) RFC 1738.

2396 is itself being updated, but is not yet an RFC.

http://www.ietf.org/rfc/rfc2396.txt
http://gbiv.com/protocols/uri/rev-2002/rfc2396bis.html

-- 
 Chris Lilley                    mailto:[email-masked]
 Chair, W3C SVG Working Group
 Member, W3C Technical Architecture Group

From: ned.freed at mrochek.com ([email-masked])
Date: Tue Jan  3 16:22:49 2006
Subject: [AVT] Re: Comments on draft-freed-media-types-reg-01.txt
In-Reply-To: "Your message dated Sat, 25 Sep 2004 18:52:16 +0100" <[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]>

> On 24 Sep 2004, at 16:29, [email-masked] wrote:
> >> > And interop problems are likely if files are produced without the
> >> > magic number
> >> > and software that checks the magic numbers is used. Similarly,
> >> > treating the
> >> > magic number as audio data could, depending on the codec involved
> >> have
> >> > some
> >> > interesting effects.
> >
> >> Of course, but so what? One clearly needs software that understands
> >> the
> >> format, and if you produce files without the magic number they're not
> >> conforming.
> >
> > Sure they are. Your entire entire goal here is to use the same label
> > for two different formats, one with the magic number and one without.

> No, not within the same domain. I'm intending that the format that's
> limited to use when transported in an unreliable sequence of RTP
> datagrams has a different header than the format for use when
> transported by a reliable byte stream, but that's a different domain of
> applicability. It's certainly should not be legal to use the headers
> for the byte stream format in RTP, or vice-versa.

You're assuming that material can be constrained to a single domain. We have
ample experience that (a) such assumptions are routinely voilated and (2) we
have absolutely no competence at predicting when violations will occur.

> > This admits the possibility of two conformant pieces of software
> > failing to interoperate, and that's not good.
> >
> >> > Now, nothing says you cannot use a naming convention of some sort
> >> to link the
> >> > two types in some way. But IMO they really need to be two different
> >> types.
> >
> >> In which case we have two different and separate namespaces, trying to
> >> share the same registry. This, IMHO, doesn't make sense.
> >
> > No, what we have is a single registry for specific formats and a way to
> > link formats that are in some way related.

> But that link is the media type name, with the domain of applicability
> to prevent interoperability problems. This is done in RFCs 3267 and
> 3558, for example, and doesn't appear to have caused problems.

Two examples where problems haven't yet arisen in a specific domain doesn't
mean much. There are hundreds of media types and who knows how many domains of
applicability, and the rules have to work for all of them.

				Ned

From: csp at csperkins.org (Colin Perkins)
Date: Tue Jan  3 16:22:49 2006
Subject: [AVT] Re: Comments on draft-freed-media-types-reg-01.txt
In-Reply-To: <[email-masked]>
References: <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]>
Message-ID: <[email-masked]>

On 24 Sep 2004, at 16:29, [email-masked] wrote:
>> > And interop problems are likely if files are produced without the
>> > magic number
>> > and software that checks the magic numbers is used. Similarly,
>> > treating the
>> > magic number as audio data could, depending on the codec involved 
>> have
>> > some
>> > interesting effects.
>
>> Of course, but so what? One clearly needs software that understands 
>> the
>> format, and if you produce files without the magic number they're not
>> conforming.
>
> Sure they are. Your entire entire goal here is to use the same label
> for two different formats, one with the magic number and one without.

No, not within the same domain. I'm intending that the format that's 
limited to use when transported in an unreliable sequence of RTP 
datagrams has a different header than the format for use when 
transported by a reliable byte stream, but that's a different domain of 
applicability. It's certainly should not be legal to use the headers 
for the byte stream format in RTP, or vice-versa.

> This admits the possibility of two conformant pieces of software
> failing to interoperate, and that's not good.
>
>> > Now, nothing says you cannot use a naming convention of some sort 
>> to link the
>> > two types in some way. But IMO they really need to be two different 
>> types.
>
>> In which case we have two different and separate namespaces, trying to
>> share the same registry. This, IMHO, doesn't make sense.
>
> No, what we have is a single registry for specific formats and a way to
> link formats that are in some way related.

But that link is the media type name, with the domain of applicability 
to prevent interoperability problems. This is done in RFCs 3267 and 
3558, for example, and doesn't appear to have caused problems.

Colin

From: ned.freed at mrochek.com ([email-masked])
Date: Fri Sep 24 17:31:54 2004
Subject: [AVT] Re: Comments on draft-freed-media-types-reg-01.txt
In-Reply-To: "Your message dated Thu, 23 Sep 2004 10:07:41 +0200" <[email-masked]>
References: <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]>
Message-ID: <[email-masked]>

> > And interop problems are likely if files are produced without the
> > magic number
> > and software that checks the magic numbers is used. Similarly,
> > treating the
> > magic number as audio data could, depending on the codec involved have
> > some
> > interesting effects.

> Of course, but so what? One clearly needs software that understands the
> format, and if you produce files without the magic number they're not
> conforming.

Sure they are. Your entire entire goal here is to use the same label
for two different formats, one with the magic number and one without.
This admits the possibility of two conformant pieces of software
failing to interoperate, and that's not good.

> > Now, nothing says you cannot use a naming convention of some sort to link the
> > two types in some way. But IMO they really need to be two different types.

> In which case we have two different and separate namespaces, trying to
> share the same registry. This, IMHO, doesn't make sense.

No, what we have is a single registry for specific formats and a way to
link formats that are in some way related.

				Ned
>From [email-masked]  Sat Sep 25 19:52:16 2004
From: csp at csperkins.org (Colin Perkins)
Date: Sat Sep 25 19:52:35 2004
Subject: [AVT] Re: Comments on draft-freed-media-types-reg-01.txt
In-Reply-To: <[email-masked]>
References: <[email-masked]>
	<[email-masked]>
	<[email-masked]>
	<[email-masked]>
	<[email-masked]>
	<[email-masked]>
	<[email-masked]>
	<[email-masked]>
Message-ID: <[email-masked]>

On 24 Sep 2004, at 16:29, [email-masked] wrote:
>> > And interop problems are likely if files are produced without the
>> > magic number
>> > and software that checks the magic numbers is used. Similarly,
>> > treating the
>> > magic number as audio data could, depending on the codec involved 
>> have
>> > some
>> > interesting effects.
>
>> Of course, but so what? One clearly needs software that understands 
>> the
>> format, and if you produce files without the magic number they're not
>> conforming.
>
> Sure they are. Your entire entire goal here is to use the same label
> for two different formats, one with the magic number and one without.

No, not within the same domain. I'm intending that the format that's 
limited to use when transported in an unreliable sequence of RTP 
datagrams has a different header than the format for use when 
transported by a reliable byte stream, but that's a different domain of 
applicability. It's certainly should not be legal to use the headers 
for the byte stream format in RTP, or vice-versa.

> This admits the possibility of two conformant pieces of software
> failing to interoperate, and that's not good.
>
>> > Now, nothing says you cannot use a naming convention of some sort 
>> to link the
>> > two types in some way. But IMO they really need to be two different 
>> types.
>
>> In which case we have two different and separate namespaces, trying to
>> share the same registry. This, IMHO, doesn't make sense.
>
> No, what we have is a single registry for specific formats and a way to
> link formats that are in some way related.

But that link is the media type name, with the domain of applicability 
to prevent interoperability problems. This is done in RFCs 3267 and 
3558, for example, and doesn't appear to have caused problems.

Colin

From: ned.freed at mrochek.com ([email-masked])
Date: Tue Jan  3 16:22:49 2006
Subject: [AVT] Re: Comments on draft-freed-media-types-reg-01.txt
In-Reply-To: "Your message dated Thu, 23 Sep 2004 10:07:41 +0200" <[email-masked]>
References: <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]>
Message-ID: <[email-masked]>

> > And interop problems are likely if files are produced without the
> > magic number
> > and software that checks the magic numbers is used. Similarly,
> > treating the
> > magic number as audio data could, depending on the codec involved have
> > some
> > interesting effects.

> Of course, but so what? One clearly needs software that understands the
> format, and if you produce files without the magic number they're not
> conforming.

Sure they are. Your entire entire goal here is to use the same label
for two different formats, one with the magic number and one without.
This admits the possibility of two conformant pieces of software
failing to interoperate, and that's not good.

> > Now, nothing says you cannot use a naming convention of some sort to link the
> > two types in some way. But IMO they really need to be two different types.

> In which case we have two different and separate namespaces, trying to
> share the same registry. This, IMHO, doesn't make sense.

No, what we have is a single registry for specific formats and a way to
link formats that are in some way related.

				Ned

From: chris at w3.org (Chris Lilley)
Date: Fri Sep 24 13:42:12 2004
Subject: MIME registration for application/gdiff
In-Reply-To: <[email-masked]>
References: <[email-masked]> <[email-masked]>
Message-ID: <[email-masked]>

On Friday, September 24, 2004, 9:41:52 AM, Linus wrote:

LW> On Fri, 10 Sep 2004, Lisa Dusseault wrote:

>> I'm trying to register a MIME type officially for application/gdiff.
>> This type was defined in a W3C NOTE several years ago:
>>
>> <http://www.w3.org/TR/NOTE-gdiff-19970901>

LW> Registering types in the IETF trees nominally involves writing some RFC
LW> document. (Tech notes from W3 have no validity for the IETF.)

Or, to clarify: Registering types in the Standards tree involves writing
an RFC (for IETF formats) or a W3C standards track document (for W3C
formats) or the equivalent standards track document (for other standards
organizations).

W3C Notes are not standards track documents:

  "This document is a NOTE made available by the W3 Consortium for
  discussion only. This indicates no endorsement of its content, nor
  that the Consortium has, is, or will be allocating any resources to
  the issues addressed by the NOTE."

LW> Given that W3 has not bothered to do this themselves,

Given that such W3C notes are not eligible for registration in the
Standards tree,

LW> I'd recommend that
LW> you file a small, informational RFC for this, so that the MIME type can
LW> eventually be added.

Yup. Or register in the vnd. or prs. trees as appropriate.  Or use
application/x.gdiff (without registration).

-- 
 Chris Lilley                    mailto:[email-masked]
 Chair, W3C SVG Working Group
 Member, W3C Technical Architecture Group

From: chris at w3.org (Chris Lilley)
Date: Tue Jan  3 16:22:49 2006
Subject: MIME registration for application/gdiff
In-Reply-To: <[email-masked]>
References: <[email-masked]> <[email-masked]>
Message-ID: <[email-masked]>

On Friday, September 24, 2004, 9:41:52 AM, Linus wrote:

LW> On Fri, 10 Sep 2004, Lisa Dusseault wrote:

>> I'm trying to register a MIME type officially for application/gdiff.
>> This type was defined in a W3C NOTE several years ago:
>>
>> <http://www.w3.org/TR/NOTE-gdiff-19970901>

LW> Registering types in the IETF trees nominally involves writing some RFC
LW> document. (Tech notes from W3 have no validity for the IETF.)

Or, to clarify: Registering types in the Standards tree involves writing
an RFC (for IETF formats) or a W3C standards track document (for W3C
formats) or the equivalent standards track document (for other standards
organizations).

W3C Notes are not standards track documents:

  "This document is a NOTE made available by the W3 Consortium for
  discussion only. This indicates no endorsement of its content, nor
  that the Consortium has, is, or will be allocating any resources to
  the issues addressed by the NOTE."

LW> Given that W3 has not bothered to do this themselves,

Given that such W3C notes are not eligible for registration in the
Standards tree,

LW> I'd recommend that
LW> you file a small, informational RFC for this, so that the MIME type can
LW> eventually be added.

Yup. Or register in the vnd. or prs. trees as appropriate.  Or use
application/x.gdiff (without registration).

-- 
 Chris Lilley                    mailto:[email-masked]
 Chair, W3C SVG Working Group
 Member, W3C Technical Architecture Group

From: triad at df.lth.se (Linus Walleij)
Date: Fri Sep 24 09:42:33 2004
Subject: MIME registration for application/gdiff
In-Reply-To: <[email-masked]>
Message-ID: <[email-masked]>

On Fri, 10 Sep 2004, Lisa Dusseault wrote:

> I'm trying to register a MIME type officially for application/gdiff.
> This type was defined in a W3C NOTE several years ago:
>
> <http://www.w3.org/TR/NOTE-gdiff-19970901>

Registering types in the IETF trees nominally involves writing some RFC
document. (Tech notes from W3 have no validity for the IETF.)

Given that W3 has not bothered to do this themselves, I'd recommend that
you file a small, informational RFC for this, so that the MIME type can
eventually be added.

Linus Walleij

From: triad at df.lth.se (Linus Walleij)
Date: Tue Jan  3 16:22:49 2006
Subject: MIME registration for application/gdiff
In-Reply-To: <[email-masked]>
Message-ID: <[email-masked]>

On Fri, 10 Sep 2004, Lisa Dusseault wrote:

> I'm trying to register a MIME type officially for application/gdiff.
> This type was defined in a W3C NOTE several years ago:
>
> <http://www.w3.org/TR/NOTE-gdiff-19970901>

Registering types in the IETF trees nominally involves writing some RFC
document. (Tech notes from W3 have no validity for the IETF.)

Given that W3 has not bothered to do this themselves, I'd recommend that
you file a small, informational RFC for this, so that the MIME type can
eventually be added.

Linus Walleij

From: csp at csperkins.org (Colin Perkins)
Date: Fri Sep 24 10:38:31 2004
Subject: [AVT] Re: Comments on draft-freed-media-types-reg-01.txt
In-Reply-To: <[email-masked]>
References: <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]>
Message-ID: <[email-masked]>

Ned,

On 11 Sep 2004, at 19:21, [email-masked] wrote:
>> On 8 Sep 2004, at 14:59, [email-masked] wrote:
>> >> >> 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?
>> >> >
>> >> >
>> >> > IMO if the parameter space is different the types are different. 
>> I
>> >> don't
>> >> > think it is appropriate to have domain-specific parameters, only
>> >> > type-specific ones.
>> >
>> >> Okay, so registering the RTP payload format and a dedicated file
>> >> format
>> >> for the same codec needs to use two different media types, due to 
>> that
>> >> that they partially needs to have different parameters?
>> >
>> > They most certainly do.
>
>> I'm a little concerned about the strength of this rule. I agree when
>> the parameter space is separate, but I can certainly envisage cases
>> when the parameter space and data format for two different domains 
>> have
>> a very high degree of overlap, and where it makes sense for them to 
>> use
>> the same media type.
>
> Data formats are either the same or they aren't. If they are the same 
> only one
> media type is required. If they aren't then different types are 
> required
> regardless of the disjointness of domains of applicability, the use of 
> the same
> underlying set of codecs, and so on.
>
> Leakage between domains is just too common to relax this rule.

Data formats can be the same, although they have different framing. 
There are several existing examples where we have the same data, using 
the same MIME type, but with different framing for RTP and for the file 
format. I would argue that this is entirely legitimate, and indeed 
required if we're to allow registrations for different domains of 
applicability.

> OTOH, parameters can be optional. I don't much care for it, but I 
> suppose
> there's nothing to prevent you from having a parameter that's optional 
> in some
> contexts and mandatory in others. (This could simply be spelled out in 
> the
> parameter specification language.) However, I would not want to  see 
> language
> prohibiting a particular parameter in some context; IMO this goes too 
> far.
> Having a single parameter with different domain-specific meanings is 
> also
> unacceptable.

Sure.

>> For example, there are several audio codecs where the RTP payload
>> format can be summarised as "put frames into RTP packets in order" and
>> the file format is "put frames into the file in order, following an
>> initial magic number". In both cases there are common parameters:
>> sampling rate, frame duration, and number of channels. However the RTP
>> payload format needs an additional parameter: maximum frame duration
>> (RTP packets have a size limit due to the path MTU, but the file 
>> format
>> supports any frame size). I'm not sure it makes sense to require these
>> to use different media types, since they're clearly the same format
>> applied to different domains, yet the above rule would seem to require
>> it.
>
> And interop problems are likely if files are produced without the 
> magic number
> and software that checks the magic numbers is used. Similarly, 
> treating the
> magic number as audio data could, depending on the codec involved have 
> some
> interesting effects.

Of course, but so what? One clearly needs software that understands the 
format, and if you produce files without the magic number they're not 
conforming.

> Now, nothing says you cannot use a naming convention of some sort to 
> link the
> two types in some way. But IMO they really need to be two different 
> types.

In which case we have two different and separate namespaces, trying to 
share the same registry. This, IMHO, doesn't make sense.

Colin

From: csp at csperkins.org (Colin Perkins)
Date: Tue Jan  3 16:22:49 2006
Subject: [AVT] Re: Comments on draft-freed-media-types-reg-01.txt
In-Reply-To: <[email-masked]>
References: <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]>
Message-ID: <[email-masked]>

Ned,

On 11 Sep 2004, at 19:21, [email-masked] wrote:
>> On 8 Sep 2004, at 14:59, [email-masked] wrote:
>> >> >> 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?
>> >> >
>> >> >
>> >> > IMO if the parameter space is different the types are different. 
>> I
>> >> don't
>> >> > think it is appropriate to have domain-specific parameters, only
>> >> > type-specific ones.
>> >
>> >> Okay, so registering the RTP payload format and a dedicated file
>> >> format
>> >> for the same codec needs to use two different media types, due to 
>> that
>> >> that they partially needs to have different parameters?
>> >
>> > They most certainly do.
>
>> I'm a little concerned about the strength of this rule. I agree when
>> the parameter space is separate, but I can certainly envisage cases
>> when the parameter space and data format for two different domains 
>> have
>> a very high degree of overlap, and where it makes sense for them to 
>> use
>> the same media type.
>
> Data formats are either the same or they aren't. If they are the same 
> only one
> media type is required. If they aren't then different types are 
> required
> regardless of the disjointness of domains of applicability, the use of 
> the same
> underlying set of codecs, and so on.
>
> Leakage between domains is just too common to relax this rule.

Data formats can be the same, although they have different framing. 
There are several existing examples where we have the same data, using 
the same MIME type, but with different framing for RTP and for the file 
format. I would argue that this is entirely legitimate, and indeed 
required if we're to allow registrations for different domains of 
applicability.

> OTOH, parameters can be optional. I don't much care for it, but I 
> suppose
> there's nothing to prevent you from having a parameter that's optional 
> in some
> contexts and mandatory in others. (This could simply be spelled out in 
> the
> parameter specification language.) However, I would not want to  see 
> language
> prohibiting a particular parameter in some context; IMO this goes too 
> far.
> Having a single parameter with different domain-specific meanings is 
> also
> unacceptable.

Sure.

>> For example, there are several audio codecs where the RTP payload
>> format can be summarised as "put frames into RTP packets in order" and
>> the file format is "put frames into the file in order, following an
>> initial magic number". In both cases there are common parameters:
>> sampling rate, frame duration, and number of channels. However the RTP
>> payload format needs an additional parameter: maximum frame duration
>> (RTP packets have a size limit due to the path MTU, but the file 
>> format
>> supports any frame size). I'm not sure it makes sense to require these
>> to use different media types, since they're clearly the same format
>> applied to different domains, yet the above rule would seem to require
>> it.
>
> And interop problems are likely if files are produced without the 
> magic number
> and software that checks the magic numbers is used. Similarly, 
> treating the
> magic number as audio data could, depending on the codec involved have 
> some
> interesting effects.

Of course, but so what? One clearly needs software that understands the 
format, and if you produce files without the magic number they're not 
conforming.

> Now, nothing says you cannot use a naming convention of some sort to 
> link the
> two types in some way. But IMO they really need to be two different 
> types.

In which case we have two different and separate namespaces, trying to 
share the same registry. This, IMHO, doesn't make sense.

Colin

From: Jeff.Hodges at KingsMountain.com ([email-masked])
Date: Tue Sep 21 19:40:40 2004
Subject: for review: draft -02 of application/samlmetadata+xml registration
Message-ID: <[email-masked]>

this rev of the application/samlmetadata+xml reflects the enhancements 
recently suggested by Martin & Graham. thanks,

JeffH

   Registration of MIME media type application/samlmetadata+xml

<@@NOTE: This document is:

sstc-saml-2.0-application-samlmetadata-registration-02
Jeff Hodges <[email-masked]>
21-Sep-2004

This document is intended to be included in
sstc-saml-metadata-2.0-cd-02 [SAMLv2Meta] (ie the next time it is
rev'd), as an appendix.

Please see http://www.w3.org/2002/06/registering-mediatype.html
for an overview of the intricities involved when a non-IETF organization
registers a MIME media type in the "standards tree" (aka "IETF
tree"). Please also note that that doc is W3C-specific, and is only
pointed to here as a source for overall information rather than
normative procedures.

The below registration material is intended to satisfy the
requirements stated in draft-freed-media-type-reg-01.txt (which
superseded draft-freed-mime-p4-04.txt).

This "NOTE" is intended to be removed upon copying this document's
content into [SAMLv2Meta].

Acknowledgments: Thanks to Ned Freed, Larry Masinter, Graham Klyne,
and Chris Lilley for their comments on prior drafts of this
registration. The security considerations section leverages that of
http://www.iana.org/assignments/media-types/application/vnd.paos+xml,
by John Kemp.
>

To: [email-masked]
Subject: Registration of MIME media type
application/samlmetadata+xml

Introduction
     This document defines a MIME media type --
     application/samlmetadata+xml -- for use with the XML
     serialization of Security Assertion Markup Language metadata.

     SAML is a work product of the OASIS Security Services Technical
     Committee [SSTC]. The SAML specifications define XML-based
     constructs with which one may make, and convey, security
     assertions. Using SAML, one can assert that an authentication
     event pertaining to some subject has occurred and convey said
     assertion to a relying party, for example.

     SAML profiles require agreements between system entities
     regarding identifiers, binding support, endpoints,
     certificates, keys, and so forth. Such information is treated
     as metadata by SAML v2.0. [SAMLv2Meta] specifies this metadata,
     as well as specifying metadata publication and resolution
     mechanisms. If the publishing protocol permits MIME-based
     identification of content types, then use of the
     application/samlmetadata+xml MIME media type is required.

MIME media type name: application

MIME subtype name: samlmetadata+xml

Required parameters: none

Optional parameters: charset
     Same as charset parameter of application/xml [RFC3023].

Encoding considerations:
     Same as for application/xml [RFC3023].

Security considerations:
     Per their specification, samlmetadata+xml typed objects do not
     contain executable content. However, these objects are
     XML-based [XML], and thus they have all of the general security
     considerations presented in section 10 of [RFC3023].

     SAML metadata [SAMLv2Meta] contains information whose integrity
     and authenticity is important ? identity provider and service
     provider public keys and endpoint addresses, for example.

     To counter potential issues, the publisher may sign
     samlmetadata+xml typed objects. Any such signature should be
     verified by the recipient of the data - both as a valid
     signature, and as being the signature of the publisher.

     Additionally, various of the publication protocols, e.g.
     HTTP-over-TLS/SSL, offer means for ensuring the authenticity of
     the publishing party and for protecting the metadata in
     transit. [SAMLv2Meta] also defines prescriptive metadata
     caching directives, as well as guidance on handling HTTPS
     redirects, trust processing, server authentication, and related
     items.

     For a more detailed discussion of SAML v2.0 metadata and its
     security considerations, please see [SAMLv2Meta]. For a
     discussion of overall SAML v2.0 security considerations and
     specific security-related design features, please refer to the
     SAML v2.0 specifications listed in the below bibliography. The
     specifications containing security-specific information are
     explicitly listed.

Interoperability considerations:
     SAML v2.0 metadata explicitly supports identifying the
     protocols and versions supported by the identified entities.
     For example, an identity provider entity can be denoted as
     supporting SAML v2.0, SAML v1.1 [SAMLv1.1], Liberty ID-FF 1.2
     [LAPFF], or even other protocols if they are unambiguously
     identifiable via URI [RFC2396]. This protocol support 
     information is conveyed via the protocolSupportEnumeration
     attribute of metadata objects of the RoleDescriptorType.

Published specification:
     [SAMLv2Meta] explicitly specifies use of the
     application/samlmetadata+xml MIME media type.

Applications which use this media type:
     Potentially any application implementing SAML v2.0, as well as
     those applications implementing specifications based on SAML,
     e.g. those available from the Liberty Alliance [LAP].

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 have a namespace-qualified name with:

               - a local name of: EntityDescriptor, or
                                  AffiliationDescriptor, or
                                  EntitiesDescriptor

               - a namespace URI of: urn:oasis:names:tc:SAML:2.0:metadata
                                     (the SAMLv2.0 metadata namespace)

     File extension(s): none

     Macintosh File Type Code(s): none

Person & email address to contact for further information:
     This registration is made on behalf of the OASIS Security
     Services Technical Committee (SSTC) Please refer to the SSTC
     website for current information on committee chairperson(s) and
     their contact addresses:
     http://www.oasis-open.org/committees/security/. Committee
     members should submit comments and potential errata to the
     [email-masked] list. Others should 
     submit them by filling out the web form located at
     http://www.oasis-open.org/committees/comments/form.php?wg_abbrev=

     Additionally, the SAML developer community email distribution
     list, [email-masked], may be employed to discuss
     usage of the application/samlmetadata+xml MIME media type. The
     "saml-dev" mailing list is publicly archived here:
     http://lists.oasis-open.org/archives/saml-dev/. To post to the 
     "saml-dev" mailing list, one must subscribe to it. To
     subscribe, send a message with the single word "subscribe" in
     the message body, to: [email-masked].

Intended usage: COMMON

Author/Change controller:
     The SAML specification sets are a work product of the OASIS
     Security Services Technical Committee (SSTC). OASIS and the
     SSTC have change control over the SAML specification sets.

Bibliography

     [LAP]          "Liberty Alliance Project". See
                    http://www.projectliberty.org/
                    
     [LAPFF]        "Liberty Alliance Project: Federation Framework". See
                    http://www.projectliberty.org/resources/specificat
                    
     [OASIS]        "Organization for the Advancement of Structured
                    Information Systems". See
                    http://www.oasis-open.org/
                    
     [RFC2396]      T. Berners-Lee, R. Fielding, L. Masinter, Uniform 
                    Resource Identifiers (URI): Generic Syntax. IETF
                    RFC 2396, August 1998. Available at
                    http://www.ietf.org/rfc/rfc2396.txt
                    
     [RFC3023]      M. Murata, S. St.Laurent, D. Kohn, "XML Media Types",
                    IETF Request for Comments 3023, January 2001.
                    Available as
                    http://www.rfc-editor.org/rfc/rfc3023.txt
                    
     [SAMLv1.1]     OASIS Security Services Technical Committee,
                    "Security Assertion Markup Language (SAML)
                    Version 1.1 Specification Set". OASIS Standard
                    200308, August 2003. Available as
                    http://www.oasis-open.org/committees/download.php
                    /3400/oasis-sstc-saml-1.1-pdf-xsd.zip
                    
     [SAMLv2.0]     OASIS Security Services Technical Committee,
                    "Security Assertion Markup Language (SAML)
                    Version 2.0 Specification Set". WORK IN
                    PROGRESS. Available at
                    http://www.oasis-open.org/committees/security/
                    
     [SAMLv2Bind]   S. Cantor et al., "Bindings for the OASIS Security
                    Assertion Markup Language (SAML) V2.0". OASIS 
                    SSTC, August 2004. Document ID
                    sstc-saml-bindings-2.0-cd-01, WORK IN PROGRESS. 
                    See http://www.oasis-open.org/committees/security/
                    
     [SAMLv2Core]   S. Cantor et al., "Assertions and Protocols for
                    the OASIS Security Assertion Markup Language
                    (SAML) V2.0". OASIS SSTC, August 2004. Document
                    ID sstc-saml-core-2.0-cd-01, WORK IN PROGRESS.
                    See http://www.oasis-open.org/committees/security/
                    
     [SAMLv2Meta]   S. Cantor et al., Metadata for the OASIS Security 
                    Assertion Markup Language (SAML) V2.0. OASIS 
                    SSTC, August 2004. Document ID
                    sstc-saml-metadata-2.0-cd-01. See
                    http://www.oasis-open.org/committees/security/
                    
     [SAMLv2Prof]   S. Cantor et al., "Profiles for the OASIS Security
                    Assertion Markup Language (SAML) V2.0". OASIS 
                    SSTC, August 2004. Document ID
                    sstc-saml-profiles-2.0-cd-01, WORK IN PROGRESS. 
                    See http://www.oasis-open.org/committees/security/
                    
     [SAMLv2Sec]    F. Hirsch et al., "Security and Privacy
                    Considerations for the OASIS Security Assertion
                    Markup Language (SAML) V2.0". OASIS SSTC, August
                    2004, WORK IN PROGRESS. Document ID
                    sstc-saml-sec-consider-2.0-cd-01. See
                    http://www.oasis-open.org/committees/security/
                    
     [SSTC]         "OASIS Security Services Technical Committee". See
                    http://www.oasis-open.org/committees/security/
                    
     [XML]          Bray, T., Paoli, J., Sperberg-McQueen, C.M. and
                    E. Maler, Fran?ois Yergeau, "Extensible Markup
                    Language (XML) 1.0 (Third Edition)", World Wide
                    Web Consortium Recommendation REC-xml, Feb 2004,
                    Available as http://www.w3.org/TR/REC-xml/

---
end

From: Jeff.Hodges at KingsMountain.com ([email-masked])
Date: Tue Jan  3 16:22:49 2006
Subject: for review: draft -02 of application/samlmetadata+xml registration
Message-ID: <[email-masked]>

this rev of the application/samlmetadata+xml reflects the enhancements 
recently suggested by Martin & Graham. thanks,

JeffH

   Registration of MIME media type application/samlmetadata+xml

<@@NOTE: This document is:

sstc-saml-2.0-application-samlmetadata-registration-02
Jeff Hodges <[email-masked]>
21-Sep-2004

This document is intended to be included in
sstc-saml-metadata-2.0-cd-02 [SAMLv2Meta] (ie the next time it is
rev'd), as an appendix.

Please see http://www.w3.org/2002/06/registering-mediatype.html
for an overview of the intricities involved when a non-IETF organization
registers a MIME media type in the "standards tree" (aka "IETF
tree"). Please also note that that doc is W3C-specific, and is only
pointed to here as a source for overall information rather than
normative procedures.

The below registration material is intended to satisfy the
requirements stated in draft-freed-media-type-reg-01.txt (which
superseded draft-freed-mime-p4-04.txt).

This "NOTE" is intended to be removed upon copying this document's
content into [SAMLv2Meta].

Acknowledgments: Thanks to Ned Freed, Larry Masinter, Graham Klyne,
and Chris Lilley for their comments on prior drafts of this
registration. The security considerations section leverages that of
http://www.iana.org/assignments/media-types/application/vnd.paos+xml,
by John Kemp.
>

To: [email-masked]
Subject: Registration of MIME media type
application/samlmetadata+xml

Introduction
     This document defines a MIME media type --
     application/samlmetadata+xml -- for use with the XML
     serialization of Security Assertion Markup Language metadata.

     SAML is a work product of the OASIS Security Services Technical
     Committee [SSTC]. The SAML specifications define XML-based
     constructs with which one may make, and convey, security
     assertions. Using SAML, one can assert that an authentication
     event pertaining to some subject has occurred and convey said
     assertion to a relying party, for example.

     SAML profiles require agreements between system entities
     regarding identifiers, binding support, endpoints,
     certificates, keys, and so forth. Such information is treated
     as metadata by SAML v2.0. [SAMLv2Meta] specifies this metadata,
     as well as specifying metadata publication and resolution
     mechanisms. If the publishing protocol permits MIME-based
     identification of content types, then use of the
     application/samlmetadata+xml MIME media type is required.

MIME media type name: application

MIME subtype name: samlmetadata+xml

Required parameters: none

Optional parameters: charset
     Same as charset parameter of application/xml [RFC3023].

Encoding considerations:
     Same as for application/xml [RFC3023].

Security considerations:
     Per their specification, samlmetadata+xml typed objects do not
     contain executable content. However, these objects are
     XML-based [XML], and thus they have all of the general security
     considerations presented in section 10 of [RFC3023].

     SAML metadata [SAMLv2Meta] contains information whose integrity
     and authenticity is important ? identity provider and service
     provider public keys and endpoint addresses, for example.

     To counter potential issues, the publisher may sign
     samlmetadata+xml typed objects. Any such signature should be
     verified by the recipient of the data - both as a valid
     signature, and as being the signature of the publisher.

     Additionally, various of the publication protocols, e.g.
     HTTP-over-TLS/SSL, offer means for ensuring the authenticity of
     the publishing party and for protecting the metadata in
     transit. [SAMLv2Meta] also defines prescriptive metadata
     caching directives, as well as guidance on handling HTTPS
     redirects, trust processing, server authentication, and related
     items.

     For a more detailed discussion of SAML v2.0 metadata and its
     security considerations, please see [SAMLv2Meta]. For a
     discussion of overall SAML v2.0 security considerations and
     specific security-related design features, please refer to the
     SAML v2.0 specifications listed in the below bibliography. The
     specifications containing security-specific information are
     explicitly listed.

Interoperability considerations:
     SAML v2.0 metadata explicitly supports identifying the
     protocols and versions supported by the identified entities.
     For example, an identity provider entity can be denoted as
     supporting SAML v2.0, SAML v1.1 [SAMLv1.1], Liberty ID-FF 1.2
     [LAPFF], or even other protocols if they are unambiguously
     identifiable via URI [RFC2396]. This protocol support 
     information is conveyed via the protocolSupportEnumeration
     attribute of metadata objects of the RoleDescriptorType.

Published specification:
     [SAMLv2Meta] explicitly specifies use of the
     application/samlmetadata+xml MIME media type.

Applications which use this media type:
     Potentially any application implementing SAML v2.0, as well as
     those applications implementing specifications based on SAML,
     e.g. those available from the Liberty Alliance [LAP].

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 have a namespace-qualified name with:

               - a local name of: EntityDescriptor, or
                                  AffiliationDescriptor, or
                                  EntitiesDescriptor

               - a namespace URI of: urn:oasis:names:tc:SAML:2.0:metadata
                                     (the SAMLv2.0 metadata namespace)

     File extension(s): none

     Macintosh File Type Code(s): none

Person & email address to contact for further information:
     This registration is made on behalf of the OASIS Security
     Services Technical Committee (SSTC) Please refer to the SSTC
     website for current information on committee chairperson(s) and
     their contact addresses:
     http://www.oasis-open.org/committees/security/. Committee
     members should submit comments and potential errata to the
     [email-masked] list. Others should 
     submit them by filling out the web form located at
     http://www.oasis-open.org/committees/comments/form.php?wg_abbrev=

     Additionally, the SAML developer community email distribution
     list, [email-masked], may be employed to discuss
     usage of the application/samlmetadata+xml MIME media type. The
     "saml-dev" mailing list is publicly archived here:
     http://lists.oasis-open.org/archives/saml-dev/. To post to the 
     "saml-dev" mailing list, one must subscribe to it. To
     subscribe, send a message with the single word "subscribe" in
     the message body, to: [email-masked].

Intended usage: COMMON

Author/Change controller:
     The SAML specification sets are a work product of the OASIS
     Security Services Technical Committee (SSTC). OASIS and the
     SSTC have change control over the SAML specification sets.

Bibliography

     [LAP]          "Liberty Alliance Project". See
                    http://www.projectliberty.org/
                    
     [LAPFF]        "Liberty Alliance Project: Federation Framework". See
                    http://www.projectliberty.org/resources/specificat
                    
     [OASIS]        "Organization for the Advancement of Structured
                    Information Systems". See
                    http://www.oasis-open.org/
                    
     [RFC2396]      T. Berners-Lee, R. Fielding, L. Masinter, Uniform 
                    Resource Identifiers (URI): Generic Syntax. IETF
                    RFC 2396, August 1998. Available at
                    http://www.ietf.org/rfc/rfc2396.txt
                    
     [RFC3023]      M. Murata, S. St.Laurent, D. Kohn, "XML Media Types",
                    IETF Request for Comments 3023, January 2001.
                    Available as
                    http://www.rfc-editor.org/rfc/rfc3023.txt
                    
     [SAMLv1.1]     OASIS Security Services Technical Committee,
                    "Security Assertion Markup Language (SAML)
                    Version 1.1 Specification Set". OASIS Standard
                    200308, August 2003. Available as
                    http://www.oasis-open.org/committees/download.php
                    /3400/oasis-sstc-saml-1.1-pdf-xsd.zip
                    
     [SAMLv2.0]     OASIS Security Services Technical Committee,
                    "Security Assertion Markup Language (SAML)
                    Version 2.0 Specification Set". WORK IN
                    PROGRESS. Available at
                    http://www.oasis-open.org/committees/security/
                    
     [SAMLv2Bind]   S. Cantor et al., "Bindings for the OASIS Security
                    Assertion Markup Language (SAML) V2.0". OASIS 
                    SSTC, August 2004. Document ID
                    sstc-saml-bindings-2.0-cd-01, WORK IN PROGRESS. 
                    See http://www.oasis-open.org/committees/security/
                    
     [SAMLv2Core]   S. Cantor et al., "Assertions and Protocols for
                    the OASIS Security Assertion Markup Language
                    (SAML) V2.0". OASIS SSTC, August 2004. Document
                    ID sstc-saml-core-2.0-cd-01, WORK IN PROGRESS.
                    See http://www.oasis-open.org/committees/security/
                    
     [SAMLv2Meta]   S. Cantor et al., Metadata for the OASIS Security 
                    Assertion Markup Language (SAML) V2.0. OASIS 
                    SSTC, August 2004. Document ID
                    sstc-saml-metadata-2.0-cd-01. See
                    http://www.oasis-open.org/committees/security/
                    
     [SAMLv2Prof]   S. Cantor et al., "Profiles for the OASIS Security
                    Assertion Markup Language (SAML) V2.0". OASIS 
                    SSTC, August 2004. Document ID
                    sstc-saml-profiles-2.0-cd-01, WORK IN PROGRESS. 
                    See http://www.oasis-open.org/committees/security/
                    
     [SAMLv2Sec]    F. Hirsch et al., "Security and Privacy
                    Considerations for the OASIS Security Assertion
                    Markup Language (SAML) V2.0". OASIS SSTC, August
                    2004, WORK IN PROGRESS. Document ID
                    sstc-saml-sec-consider-2.0-cd-01. See
                    http://www.oasis-open.org/committees/security/
                    
     [SSTC]         "OASIS Security Services Technical Committee". See
                    http://www.oasis-open.org/committees/security/
                    
     [XML]          Bray, T., Paoli, J., Sperberg-McQueen, C.M. and
                    E. Maler, Fran?ois Yergeau, "Extensible Markup
                    Language (XML) 1.0 (Third Edition)", World Wide
                    Web Consortium Recommendation REC-xml, Feb 2004,
                    Available as http://www.w3.org/TR/REC-xml/

---
end

From: Jeff.Hodges at KingsMountain.com ([email-masked])
Date: Tue Sep 21 19:34:13 2004
Subject: for review: draft -03 of application/samlassertion+xml registration
Message-ID: <[email-masked]>

this rev of the application/samlassertion+xml reflects the enhancements 
recently suggested by Martin & Graham. thanks,

JeffH

   Registration of MIME media type application/samlassertion+xml

<@@NOTE: This document is:

sstc-saml-2.0-application-samlassertion-registration-03
Jeff Hodges <[email-masked]>
21-Sep-2004

This document supersedes draft-hodges-saml-mediatype-02.txt. It is
intended to be included in sstc-saml-bindings-2.0-cd-02 (ie the next
time [SAMLv2Bind] is rev'd), as an appendix.

Please see http://www.w3.org/2002/06/registering-mediatype.html
for an overview of the intricities involved when a non-IETF organization
registers a MIME media type in the "standards tree" (aka "IETF
tree"). Please also note that that doc is W3C-specific, and is only
pointed to here as a source for overall information rather than
normative procedures.

The below registration material is intended to satisfy the
requirements stated in draft-freed-media-type-reg-01.txt (which
superseded draft-freed-mime-p4-04.txt).

This "NOTE" is intended to be removed upon copying this document's
content into [SAMLv2Bind].

Acknowledgments: Thanks to Ned Freed, Larry Masinter, Graham Klyne,
and Chris Lilley for their comments on prior drafts of this
registration. The security considerations section leverages that of
http://www.iana.org/assignments/media-types/application/vnd.paos+xml,
by John Kemp.
>

To: [email-masked]
Subject: Registration of MIME media type
application/samlassertion+xml

Introduction
     This document defines a MIME media type --
     application/samlassertion+xml -- for use with the XML
     serialization of SAML (Security Assertion Markup Language)
     assertions.

     The SAML specification sets -- [SAMLv1.0], [SAMLv1.1],
     [SAMLv2.0] -- are work products of the OASIS Security Services
     Technical Committee [SSTC]. The SAML specifications define
     XML-based constructs with which one may make, and convey,
     security assertions. Using SAML, one can assert that an
     authentication event pertaining to some subject has occured and
     convey said assertion to a relying party, for example.

     SAML assertions, which are explicitly versioned, are defined by
     [SAMLv1Core], [SAMLv11Core], and [SAMLv2Core].

MIME media type name: application

MIME subtype name: samlassertion+xml

Required parameters: none

Optional parameters: charset
     Same as charset parameter of application/xml [RFC3023].

Encoding considerations:
     Same as for application/xml [RFC3023].

Security considerations:
     Per their specification, samlassertion+xml typed objects do not
     contain executable content. However, SAML assertions are
     XML-based objects [XML]. As such, they have all of the general
     security considerations presented in section 10 of [RFC3023],
     as well as additional ones, since they are explicit security
     objects. For example, samlassertion+xml typed objects will
     often contain data that may identify or pertain to a natural
     person, and may be used as a basis for sessions and access
     control decisions.

     To counter potential issues, samlassertion+xml typed objects
     contain data that should be signed appropriately by the sender.
     Any such signature must be verified by the recipient of the
     data - both as a valid signature, and as being the signature of
     the sender. Issuers of samlassertion+xml objects containing
     SAMLv2 assertions may also encrypt all, or portions of, the
     assertions [SAMLv2Core].

     In addition, SAML profiles and protocol bindings specify use of
     secure channels as appropriate.

     [SAMLv2.0] incorporates various privacy-protection techniques
     in its design. For example: opaque handles, specific to
     interactions between specific system entities, may be assigned
     to subjects. The handles are mappable to wider-context
     identifiers (e.g. email addresses, account identifiers, etc) by
     only the specific parties.

     For a more detailed discussion of SAML security considerations
     and specific security-related design techniques, please refer
     to the SAML specifications listed in the below bibliography.
     The specifications containing security-specific information
     have been explicitly listed for each version of SAML.

Interoperability considerations:
     SAML assertions are explicitly versioned. Relying parties
     should ensure that they observe assertion version information
     and behave accordingly. See "Chapter 4 SAML Versioning" in
     [SAMLv1Core], [SAMLv11Core], or [SAMLv2Core], as appropriate.

Published specification:
     [SAMLv2Bind] explicitly specifies use of the
     application/samlassertion+xml MIME media type. However, it is
     conceivable that non-SAMLv2 assertions (i.e. SAMLv1 and/or
     SAMLv1.1) might in practice be conveyed using SAMLv2 bindings.

Applications which use this media type:
     Potentially any application implementing SAML, as well as those
     applications implementing specifications based on SAML, e.g.
     those available from the Liberty Alliance [LAP].

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 have a namespace-qualified name with:

               - a local name of: Assertion

               - a namespace URI of: one of the version-specific
                 SAML assertion XML namespace URIs, 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" represents any XML
          namespace prefix that maps to the SAMLv2.0 assertion 
          namespace URI:

               urn:oasis:names:tc:SAML:2.0:assertion

     File extension(s): none

     Macintosh File Type Code(s): none

Person & email address to contact for further information:
     This registration is made on behalf of the OASIS Security
     Services Technical Committee (SSTC) Please refer to the SSTC
     website for current information on committee chairperson(s) and
     their contact addresses:
     http://www.oasis-open.org/committees/security/. Committee
     members should submit comments and potential errata to the
     [email-masked] list. Others should 
     submit them by filling out the web form located at
     http://www.oasis-open.org/committees/comments/form.php?wg_abbrev=

     Additionally, the SAML developer community email distribution
     list, [email-masked], may be employed to discuss
     usage of the application/samlassertion+xml MIME media type. The
     "saml-dev" mailing list is publicly archived here:
     http://lists.oasis-open.org/archives/saml-dev/. To post to the 
     "saml-dev" mailing list, one must subscribe to it. To
     subscribe, send a message with the single word "subscribe" in
     the message body, to: [email-masked].

Intended usage: COMMON

Author/Change controller:
     The SAML specification sets are a work product of the OASIS
     Security Services Technical Committee (SSTC). OASIS and the
     SSTC have change control over the SAML specification sets.

Bibliography

     [LAP]          "Liberty Alliance Project". See
                    http://www.projectliberty.org/
                    
     [OASIS]        "Organization for the Advancement of Structured
                    Information Systems". See
                    http://www.oasis-open.org/
                    
     [RFC3023]      M. Murata, S. St.Laurent, D. Kohn, "XML Media Types",
                    IETF Request for Comments 3023, January 2001.
                    Available as
                    http://www.rfc-editor.org/rfc/rfc3023.txt
                    
     [SAMLv1.0]     OASIS Security Services Technical Committee,
                    "Security Assertion Markup Language (SAML)
                    Version 1.0 Specification Set". OASIS Standard
                    200205, November 2002. Available as
                    http://www.oasis-open.org/committees/download.php
                    /2290/oasis-sstc-saml-1.0.zip
                    
     [SAMLv1Bind]   Prateek Mishra et al., "Bindings and Profiles for
                    the OASIS Security Assertion Markup Language
                    (SAML)", OASIS, November 2002. Document ID
                    oasis-sstc-saml-bindings-1.0. See
                    http://www.oasis-open.org/committees/security/
                    
     [SAMLv1Core]   Phillip Hallam-Baker et al., "Assertions and
                    Protocol for the OASIS Security Assertion Markup
                    Language (SAML)", OASIS, November 2002. Document
                    ID oasis-sstc-saml-core-1.0. See
                    http://www.oasis-open.org/committees/security/
                    
     [SAMLv1Sec]    Chris McLaren et al., "Security Considerations for
                    the OASIS Security Assertion Markup Language
                    (SAML)", OASIS, November 2002. Document ID
                    oasis-sstc-saml-sec-consider-1.0. See
                    http://www.oasis-open.org/committees/security/
                    
     [SAMLv1.1]     OASIS Security Services Technical Committee,
                    "Security Assertion Markup Language (SAML)
                    Version 1.1 Specification Set". OASIS Standard
                    200308, August 2003. Available as
                    http://www.oasis-open.org/committees/download.php
                    /3400/oasis-sstc-saml-1.1-pdf-xsd.zip
                    
     [SAMLv11Bind]  E. Maler et al. "Bindings and Profiles for the
                    OASIS Security Assertion Markup Language
                    (SAML)". OASIS, September 2003. Document ID
                    oasis-sstc-saml-bindings-1.1.
                    http://www.oasis-open.org/committees/security/
                    
     [SAMLv11Core]  E. Maler et al. "Assertions and Protocol for the
                    OASIS Security Assertion Markup Language
                    (SAML)". OASIS, September 2003. Document ID
                    oasis-sstc-saml-core-1.1.
                    http://www.oasis-open.org/committees/security/
                    
     [SAMLv11Sec]   E. Maler et al. "Security Considerations for the
                    OASIS Security Assertion Markup Language
                    (SAML)". OASIS, September 2003. Document ID
                    oasis-sstc-saml-sec-consider-1.1.
                    http://www.oasis-open.org/committees/security/
                    
     [SAMLv2.0]     OASIS Security Services Technical Committee,
                    "Security Assertion Markup Language (SAML)
                    Version 2.0 Specification Set". WORK IN
                    PROGRESS. Available at
                    http://www.oasis-open.org/committees/security/
                    
     [SAMLv2Bind]   S. Cantor et al., "Bindings for the OASIS Security
                    Assertion Markup Language (SAML) V2.0". OASIS 
                    SSTC, August 2004. Document ID
                    sstc-saml-bindings-2.0-cd-01, WORK IN PROGRESS. 
                    See http://www.oasis-open.org/committees/security/
                    
     [SAMLv2Core]   S. Cantor et al., "Assertions and Protocols for
                    the OASIS Security Assertion Markup Language
                    (SAML) V2.0". OASIS SSTC, August 2004. Document
                    ID sstc-saml-core-2.0-cd-01, WORK IN PROGRESS.
                    See http://www.oasis-open.org/committees/security/
                    
     [SAMLv2Prof]   S. Cantor et al., "Profiles for the OASIS Security
                    Assertion Markup Language (SAML) V2.0". OASIS 
                    SSTC, August 2004. Document ID
                    sstc-saml-profiles-2.0-cd-01, WORK IN PROGRESS. 
                    See http://www.oasis-open.org/committees/security/
                    
     [SAMLv2Sec]    F. Hirsch et al., "Security and Privacy
                    Considerations for the OASIS Security Assertion
                    Markup Language (SAML) V2.0". OASIS SSTC, August
                    2004, WORK IN PROGRESS. Document ID
                    sstc-saml-sec-consider-2.0-cd-01. See
                    http://www.oasis-open.org/committees/security/
                    
     [SSTC]         "OASIS Security Services Technical Committee". See
                    http://www.oasis-open.org/committees/security/
                    
     [XML]          Bray, T., Paoli, J., Sperberg-McQueen, C.M. and 
                    E. Maler, Fran?ois Yergeau, "Extensible
                    Markup Language  (XML) 1.0 (Third Edition)",
                    World Wide Web  Consortium Recommendation
                    REC-xml, Feb 2004, Available as 
                    http://www.w3.org/TR/REC-xml/
                    
---
end

From: Jeff.Hodges at KingsMountain.com ([email-masked])
Date: Tue Jan  3 16:22:49 2006
Subject: for review: draft -03 of application/samlassertion+xml registration
Message-ID: <[email-masked]>

this rev of the application/samlassertion+xml reflects the enhancements 
recently suggested by Martin & Graham. thanks,

JeffH

   Registration of MIME media type application/samlassertion+xml

<@@NOTE: This document is:

sstc-saml-2.0-application-samlassertion-registration-03
Jeff Hodges <[email-masked]>
21-Sep-2004

This document supersedes draft-hodges-saml-mediatype-02.txt. It is
intended to be included in sstc-saml-bindings-2.0-cd-02 (ie the next
time [SAMLv2Bind] is rev'd), as an appendix.

Please see http://www.w3.org/2002/06/registering-mediatype.html
for an overview of the intricities involved when a non-IETF organization
registers a MIME media type in the "standards tree" (aka "IETF
tree"). Please also note that that doc is W3C-specific, and is only
pointed to here as a source for overall information rather than
normative procedures.

The below registration material is intended to satisfy the
requirements stated in draft-freed-media-type-reg-01.txt (which
superseded draft-freed-mime-p4-04.txt).

This "NOTE" is intended to be removed upon copying this document's
content into [SAMLv2Bind].

Acknowledgments: Thanks to Ned Freed, Larry Masinter, Graham Klyne,
and Chris Lilley for their comments on prior drafts of this
registration. The security considerations section leverages that of
http://www.iana.org/assignments/media-types/application/vnd.paos+xml,
by John Kemp.
>

To: [email-masked]
Subject: Registration of MIME media type
application/samlassertion+xml

Introduction
     This document defines a MIME media type --
     application/samlassertion+xml -- for use with the XML
     serialization of SAML (Security Assertion Markup Language)
     assertions.

     The SAML specification sets -- [SAMLv1.0], [SAMLv1.1],
     [SAMLv2.0] -- are work products of the OASIS Security Services
     Technical Committee [SSTC]. The SAML specifications define
     XML-based constructs with which one may make, and convey,
     security assertions. Using SAML, one can assert that an
     authentication event pertaining to some subject has occured and
     convey said assertion to a relying party, for example.

     SAML assertions, which are explicitly versioned, are defined by
     [SAMLv1Core], [SAMLv11Core], and [SAMLv2Core].

MIME media type name: application

MIME subtype name: samlassertion+xml

Required parameters: none

Optional parameters: charset
     Same as charset parameter of application/xml [RFC3023].

Encoding considerations:
     Same as for application/xml [RFC3023].

Security considerations:
     Per their specification, samlassertion+xml typed objects do not
     contain executable content. However, SAML assertions are
     XML-based objects [XML]. As such, they have all of the general
     security considerations presented in section 10 of [RFC3023],
     as well as additional ones, since they are explicit security
     objects. For example, samlassertion+xml typed objects will
     often contain data that may identify or pertain to a natural
     person, and may be used as a basis for sessions and access
     control decisions.

     To counter potential issues, samlassertion+xml typed objects
     contain data that should be signed appropriately by the sender.
     Any such signature must be verified by the recipient of the
     data - both as a valid signature, and as being the signature of
     the sender. Issuers of samlassertion+xml objects containing
     SAMLv2 assertions may also encrypt all, or portions of, the
     assertions [SAMLv2Core].

     In addition, SAML profiles and protocol bindings specify use of
     secure channels as appropriate.

     [SAMLv2.0] incorporates various privacy-protection techniques
     in its design. For example: opaque handles, specific to
     interactions between specific system entities, may be assigned
     to subjects. The handles are mappable to wider-context
     identifiers (e.g. email addresses, account identifiers, etc) by
     only the specific parties.

     For a more detailed discussion of SAML security considerations
     and specific security-related design techniques, please refer
     to the SAML specifications listed in the below bibliography.
     The specifications containing security-specific information
     have been explicitly listed for each version of SAML.

Interoperability considerations:
     SAML assertions are explicitly versioned. Relying parties
     should ensure that they observe assertion version information
     and behave accordingly. See "Chapter 4 SAML Versioning" in
     [SAMLv1Core], [SAMLv11Core], or [SAMLv2Core], as appropriate.

Published specification:
     [SAMLv2Bind] explicitly specifies use of the
     application/samlassertion+xml MIME media type. However, it is
     conceivable that non-SAMLv2 assertions (i.e. SAMLv1 and/or
     SAMLv1.1) might in practice be conveyed using SAMLv2 bindings.

Applications which use this media type:
     Potentially any application implementing SAML, as well as those
     applications implementing specifications based on SAML, e.g.
     those available from the Liberty Alliance [LAP].

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 have a namespace-qualified name with:

               - a local name of: Assertion

               - a namespace URI of: one of the version-specific
                 SAML assertion XML namespace URIs, 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" represents any XML
          namespace prefix that maps to the SAMLv2.0 assertion 
          namespace URI:

               urn:oasis:names:tc:SAML:2.0:assertion

     File extension(s): none

     Macintosh File Type Code(s): none

Person & email address to contact for further information:
     This registration is made on behalf of the OASIS Security
     Services Technical Committee (SSTC) Please refer to the SSTC
     website for current information on committee chairperson(s) and
     their contact addresses:
     http://www.oasis-open.org/committees/security/. Committee
     members should submit comments and potential errata to the
     [email-masked] list. Others should 
     submit them by filling out the web form located at
     http://www.oasis-open.org/committees/comments/form.php?wg_abbrev=

     Additionally, the SAML developer community email distribution
     list, [email-masked], may be employed to discuss
     usage of the application/samlassertion+xml MIME media type. The
     "saml-dev" mailing list is publicly archived here:
     http://lists.oasis-open.org/archives/saml-dev/. To post to the 
     "saml-dev" mailing list, one must subscribe to it. To
     subscribe, send a message with the single word "subscribe" in
     the message body, to: [email-masked].

Intended usage: COMMON

Author/Change controller:
     The SAML specification sets are a work product of the OASIS
     Security Services Technical Committee (SSTC). OASIS and the
     SSTC have change control over the SAML specification sets.

Bibliography

     [LAP]          "Liberty Alliance Project". See
                    http://www.projectliberty.org/
                    
     [OASIS]        "Organization for the Advancement of Structured
                    Information Systems". See
                    http://www.oasis-open.org/
                    
     [RFC3023]      M. Murata, S. St.Laurent, D. Kohn, "XML Media Types",
                    IETF Request for Comments 3023, January 2001.
                    Available as
                    http://www.rfc-editor.org/rfc/rfc3023.txt
                    
     [SAMLv1.0]     OASIS Security Services Technical Committee,
                    "Security Assertion Markup Language (SAML)
                    Version 1.0 Specification Set". OASIS Standard
                    200205, November 2002. Available as
                    http://www.oasis-open.org/committees/download.php
                    /2290/oasis-sstc-saml-1.0.zip
                    
     [SAMLv1Bind]   Prateek Mishra et al., "Bindings and Profiles for
                    the OASIS Security Assertion Markup Language
                    (SAML)", OASIS, November 2002. Document ID
                    oasis-sstc-saml-bindings-1.0. See
                    http://www.oasis-open.org/committees/security/
                    
     [SAMLv1Core]   Phillip Hallam-Baker et al., "Assertions and
                    Protocol for the OASIS Security Assertion Markup
                    Language (SAML)", OASIS, November 2002. Document
                    ID oasis-sstc-saml-core-1.0. See
                    http://www.oasis-open.org/committees/security/
                    
     [SAMLv1Sec]    Chris McLaren et al., "Security Considerations for
                    the OASIS Security Assertion Markup Language
                    (SAML)", OASIS, November 2002. Document ID
                    oasis-sstc-saml-sec-consider-1.0. See
                    http://www.oasis-open.org/committees/security/
                    
     [SAMLv1.1]     OASIS Security Services Technical Committee,
                    "Security Assertion Markup Language (SAML)
                    Version 1.1 Specification Set". OASIS Standard
                    200308, August 2003. Available as
                    http://www.oasis-open.org/committees/download.php
                    /3400/oasis-sstc-saml-1.1-pdf-xsd.zip
                    
     [SAMLv11Bind]  E. Maler et al. "Bindings and Profiles for the
                    OASIS Security Assertion Markup Language
                    (SAML)". OASIS, September 2003. Document ID
                    oasis-sstc-saml-bindings-1.1.
                    http://www.oasis-open.org/committees/security/
                    
     [SAMLv11Core]  E. Maler et al. "Assertions and Protocol for the
                    OASIS Security Assertion Markup Language
                    (SAML)". OASIS, September 2003. Document ID
                    oasis-sstc-saml-core-1.1.
                    http://www.oasis-open.org/committees/security/
                    
     [SAMLv11Sec]   E. Maler et al. "Security Considerations for the
                    OASIS Security Assertion Markup Language
                    (SAML)". OASIS, September 2003. Document ID
                    oasis-sstc-saml-sec-consider-1.1.
                    http://www.oasis-open.org/committees/security/
                    
     [SAMLv2.0]     OASIS Security Services Technical Committee,
                    "Security Assertion Markup Language (SAML)
                    Version 2.0 Specification Set". WORK IN
                    PROGRESS. Available at
                    http://www.oasis-open.org/committees/security/
                    
     [SAMLv2Bind]   S. Cantor et al., "Bindings for the OASIS Security
                    Assertion Markup Language (SAML) V2.0". OASIS 
                    SSTC, August 2004. Document ID
                    sstc-saml-bindings-2.0-cd-01, WORK IN PROGRESS. 
                    See http://www.oasis-open.org/committees/security/
                    
     [SAMLv2Core]   S. Cantor et al., "Assertions and Protocols for
                    the OASIS Security Assertion Markup Language
                    (SAML) V2.0". OASIS SSTC, August 2004. Document
                    ID sstc-saml-core-2.0-cd-01, WORK IN PROGRESS.
                    See http://www.oasis-open.org/committees/security/
                    
     [SAMLv2Prof]   S. Cantor et al., "Profiles for the OASIS Security
                    Assertion Markup Language (SAML) V2.0". OASIS 
                    SSTC, August 2004. Document ID
                    sstc-saml-profiles-2.0-cd-01, WORK IN PROGRESS. 
                    See http://www.oasis-open.org/committees/security/
                    
     [SAMLv2Sec]    F. Hirsch et al., "Security and Privacy
                    Considerations for the OASIS Security Assertion
                    Markup Language (SAML) V2.0". OASIS SSTC, August
                    2004, WORK IN PROGRESS. Document ID
                    sstc-saml-sec-consider-2.0-cd-01. See
                    http://www.oasis-open.org/committees/security/
                    
     [SSTC]         "OASIS Security Services Technical Committee". See
                    http://www.oasis-open.org/committees/security/
                    
     [XML]          Bray, T., Paoli, J., Sperberg-McQueen, C.M. and 
                    E. Maler, Fran?ois Yergeau, "Extensible
                    Markup Language  (XML) 1.0 (Third Edition)",
                    World Wide Web  Consortium Recommendation
                    REC-xml, Feb 2004, Available as 
                    http://www.w3.org/TR/REC-xml/
                    
---
end

From: Jeff.Hodges at KingsMountain.com ([email-masked])
Date: Tue Sep 21 19:31:34 2004
Subject: Please review: DRAFT Reg of application/samlassertion+xml 
In-Reply-To: Graham Klyne <[email-masked]> 's message of  Tue, 21 Sep 2004 10:09:29 +0100
Message-ID: <[email-masked]>

> At 09:28 20/09/04 -0700, [email-masked] wrote:
> >Ok, how about this...
> >
> >
> >Magic number(s):
> >     In general, the same as for application/xml [RFC3023]. In
> >     particular, the XML root element of the returned object will be
> >     <Assertion>, and will be in one of the version-specific SAML
> >     assertion XML namespaces, 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" represents any XML namspace prefix that maps to the
> >     SAMLv2.0 assertion namespace URI:
> >
> >        urn:oasis:names:tc:SAML:2.0:assertion.
> 
> I think the intent here is pretty clear and correct, but I find myself 
> fretting a little at the wording in case of possible misunderstanding, so 
> here's my suggestion for the 1st para:
> 
> [[
> Magic number(s):
>      In general, the same as for application/xml [RFC3023]. In
>      particular, the XML root element of the returned object will
>      have a namespace-qualified name with:
>      - local name: Assertion
>      - namespace URI: one of the version-specific SAML assertion
>        XML namespace URIs, as defined by the appropriate version-
>        specific SAML "core" specification (see bibliography).
> ]]
> 
> I'm not sure that this is better;  mainly, I aimed to avoid the (very
> slight) implication that the root element would always be introduced
> by the literal <Assertion>.  In any case, your 2nd paragraph makes the
> situation clear, so use or ignore my thoughts as you see fit.

ScottC and I chatted about this and feel yer right and it's worth it to 
express it as you have above. So thanks again for the salient comments. a rev 
of both reg's incorp'g the above will be forthcoming.

JeffH

From: Jeff.Hodges at KingsMountain.com ([email-masked])
Date: Tue Jan  3 16:22:49 2006
Subject: Please review: DRAFT Reg of application/samlassertion+xml 
In-Reply-To: Graham Klyne <[email-masked]> 's message of  Tue, 21 Sep 2004 10:09:29 +0100
Message-ID: <[email-masked]>

> At 09:28 20/09/04 -0700, [email-masked] wrote:
> >Ok, how about this...
> >
> >
> >Magic number(s):
> >     In general, the same as for application/xml [RFC3023]. In
> >     particular, the XML root element of the returned object will be
> >     <Assertion>, and will be in one of the version-specific SAML
> >     assertion XML namespaces, 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" represents any XML namspace prefix that maps to the
> >     SAMLv2.0 assertion namespace URI:
> >
> >        urn:oasis:names:tc:SAML:2.0:assertion.
> 
> I think the intent here is pretty clear and correct, but I find myself 
> fretting a little at the wording in case of possible misunderstanding, so 
> here's my suggestion for the 1st para:
> 
> [[
> Magic number(s):
>      In general, the same as for application/xml [RFC3023]. In
>      particular, the XML root element of the returned object will
>      have a namespace-qualified name with:
>      - local name: Assertion
>      - namespace URI: one of the version-specific SAML assertion
>        XML namespace URIs, as defined by the appropriate version-
>        specific SAML "core" specification (see bibliography).
> ]]
> 
> I'm not sure that this is better;  mainly, I aimed to avoid the (very
> slight) implication that the root element would always be introduced
> by the literal <Assertion>.  In any case, your 2nd paragraph makes the
> situation clear, so use or ignore my thoughts as you see fit.

ScottC and I chatted about this and feel yer right and it's worth it to 
express it as you have above. So thanks again for the salient comments. a rev 
of both reg's incorp'g the above will be forthcoming.

JeffH

From: Jeff.Hodges at KingsMountain.com ([email-masked])
Date: Tue Sep 21 19:28:15 2004
Subject: for review: draft -01 of application/samlmetadata+xml  registration
In-Reply-To: Martin Duerst <[email-masked]> 's message of  Tue, 21 Sep 2004 12:15:41 +0900
Message-ID: <[email-masked]>

> There is now a third edition of XML. The reference section
> should be updated.

good catch, thanks.

> >Please see http://www.w3.org/2002/06/registering-mediatype.html
> >for an overview of the intricities involved when a non-IETF organization
> >registers a MIME media type in the "standards tree" (aka "IETF
> >tree").
> 
> Again, this document only applies to media types from W3C.

however, I think it's worthwhile for one from any non-ietf SDO to take a look 
at (u guys did a good job on it). So i've added an extra admonishment to the 
preface NOTE wrt this. Also note that the preface NOTE won't be sent to the 
iesg (unless someone thinks it'd add value to that submission), and the 
preface NOTE will be deleted when the reg's are copied into our (OASIS SSTC 
SAML) specs.

thanks,

JeffH

From: Jeff.Hodges at KingsMountain.com ([email-masked])
Date: Tue Jan  3 16:22:49 2006
Subject: for review: draft -01 of application/samlmetadata+xml  registration
In-Reply-To: Martin Duerst <[email-masked]> 's message of  Tue, 21 Sep 2004 12:15:41 +0900
Message-ID: <[email-masked]>

> There is now a third edition of XML. The reference section
> should be updated.

good catch, thanks.

> >Please see http://www.w3.org/2002/06/registering-mediatype.html
> >for an overview of the intricities involved when a non-IETF organization
> >registers a MIME media type in the "standards tree" (aka "IETF
> >tree").
> 
> Again, this document only applies to media types from W3C.

however, I think it's worthwhile for one from any non-ietf SDO to take a look 
at (u guys did a good job on it). So i've added an extra admonishment to the 
preface NOTE wrt this. Also note that the preface NOTE won't be sent to the 
iesg (unless someone thinks it'd add value to that submission), and the 
preface NOTE will be deleted when the reg's are copied into our (OASIS SSTC 
SAML) specs.

thanks,

JeffH

From: GK at ninebynine.org (Graham Klyne)
Date: Tue Sep 21 13:39:06 2004
Subject: Please review: DRAFT Reg of application/samlassertion+xml 
In-Reply-To: <[email-masked]>
References: <Chris Lilley <[email-masked]>
Message-ID: <[email-masked]>

At 09:28 20/09/04 -0700, [email-masked] wrote:
>Ok, how about this...
>
>
>Magic number(s):
>     In general, the same as for application/xml [RFC3023]. In
>     particular, the XML root element of the returned object will be
>     <Assertion>, and will be in one of the version-specific SAML
>     assertion XML namespaces, 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" represents any XML namspace prefix that maps to the
>     SAMLv2.0 assertion namespace URI:
>
>        urn:oasis:names:tc:SAML:2.0:assertion.

I think the intent here is pretty clear and correct, but I find myself 
fretting a little at the wording in case of possible misunderstanding, so 
here's my suggestion for the 1st para:

[[
Magic number(s):
     In general, the same as for application/xml [RFC3023]. In
     particular, the XML root element of the returned object will
     have a namespace-qualified name with:
     - local name: Assertion
     - namespace URI: one of the version-specific SAML assertion
       XML namespace URIs, as defined by the appropriate version-
       specific SAML "core" specification (see bibliography).
]]

I'm not sure that this is better;  mainly, I aimed to avoid the (very
slight) implication that the root element would always be introduced
by the literal <Assertion>.  In any case, your 2nd paragraph makes the
situation clear, so use or ignore my thoughts as you see fit.

#g

------------
Graham Klyne
For email:
http://www.ninebynine.org/#Contact

From: GK at ninebynine.org (Graham Klyne)
Date: Tue Jan  3 16:22:49 2006
Subject: Please review: DRAFT Reg of application/samlassertion+xml 
In-Reply-To: <[email-masked]>
References: <Chris Lilley <[email-masked]>
Message-ID: <[email-masked]>

At 09:28 20/09/04 -0700, [email-masked] wrote:
>Ok, how about this...
>
>
>Magic number(s):
>     In general, the same as for application/xml [RFC3023]. In
>     particular, the XML root element of the returned object will be
>     <Assertion>, and will be in one of the version-specific SAML
>     assertion XML namespaces, 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" represents any XML namspace prefix that maps to the
>     SAMLv2.0 assertion namespace URI:
>
>        urn:oasis:names:tc:SAML:2.0:assertion.

I think the intent here is pretty clear and correct, but I find myself 
fretting a little at the wording in case of possible misunderstanding, so 
here's my suggestion for the 1st para:

[[
Magic number(s):
     In general, the same as for application/xml [RFC3023]. In
     particular, the XML root element of the returned object will
     have a namespace-qualified name with:
     - local name: Assertion
     - namespace URI: one of the version-specific SAML assertion
       XML namespace URIs, as defined by the appropriate version-
       specific SAML "core" specification (see bibliography).
]]

I'm not sure that this is better;  mainly, I aimed to avoid the (very
slight) implication that the root element would always be introduced
by the literal <Assertion>.  In any case, your 2nd paragraph makes the
situation clear, so use or ignore my thoughts as you see fit.

#g

------------
Graham Klyne
For email:
http://www.ninebynine.org/#Contact

From: duerst at w3.org (Martin Duerst)
Date: Tue Sep 21 05:16:16 2004
Subject: for review: draft -01 of application/samlmetadata+xml registration
In-Reply-To: <[email-masked]>
Message-ID: <4.2.0.58.J.20040921121407.05da0c40@localhost>

There is now a third edition of XML. The reference section
should be updated.

Regards,    Martin.

At 12:42 04/09/20 -0700, [email-masked] wrote:
>   Registration of MIME media type application/samlmetadata+xml
>
><@@NOTE: This document is:
>
>sstc-saml-2.0-application-samlmetadata-registration-01
>Jeff Hodges <[email-masked]>
>20-Sep-2004
>
>This document is intended to be included in
>sstc-saml-metadata-2.0-cd-02 (ie the next time [SAMLv2Meta] is
>rev'd), as an appendix.
>
>Please see http://www.w3.org/2002/06/registering-mediatype.html
>for an overview of the intricities involved when a non-IETF organization
>registers a MIME media type in the "standards tree" (aka "IETF
>tree").

Again, this document only applies to media types from W3C.

>      [XML]          Bray, T., Paoli, J., Sperberg-McQueen, C.M. and
>                     E. Maler, "Extensible Markup Language (XML) 1.0
>                     (Second Edition)", World Wide Web Consortium
>                     Recommendation REC-xml, October 2000, Available
>                     as http://www.w3.org/TR/REC-xml

From: duerst at w3.org (Martin Duerst)
Date: Tue Jan  3 16:22:49 2006
Subject: for review: draft -01 of application/samlmetadata+xml registration
In-Reply-To: <[email-masked]>
Message-ID: <4.2.0.58.J.20040921121407.05da0c40@localhost>

There is now a third edition of XML. The reference section
should be updated.

Regards,    Martin.

At 12:42 04/09/20 -0700, [email-masked] wrote:
>   Registration of MIME media type application/samlmetadata+xml
>
><@@NOTE: This document is:
>
>sstc-saml-2.0-application-samlmetadata-registration-01
>Jeff Hodges <[email-masked]>
>20-Sep-2004
>
>This document is intended to be included in
>sstc-saml-metadata-2.0-cd-02 (ie the next time [SAMLv2Meta] is
>rev'd), as an appendix.
>
>Please see http://www.w3.org/2002/06/registering-mediatype.html
>for an overview of the intricities involved when a non-IETF organization
>registers a MIME media type in the "standards tree" (aka "IETF
>tree").

Again, this document only applies to media types from W3C.

>      [XML]          Bray, T., Paoli, J., Sperberg-McQueen, C.M. and
>                     E. Maler, "Extensible Markup Language (XML) 1.0
>                     (Second Edition)", World Wide Web Consortium
>                     Recommendation REC-xml, October 2000, Available
>                     as http://www.w3.org/TR/REC-xml

From: Jeff.Hodges at KingsMountain.com ([email-masked])
Date: Mon Sep 20 21:42:53 2004
Subject: for review: draft -01 of application/samlmetadata+xml registration
Message-ID: <[email-masked]>

  Registration of MIME media type application/samlmetadata+xml

<@@NOTE: This document is:

sstc-saml-2.0-application-samlmetadata-registration-01
Jeff Hodges <[email-masked]>
20-Sep-2004

This document is intended to be included in
sstc-saml-metadata-2.0-cd-02 (ie the next time [SAMLv2Meta] is
rev'd), as an appendix.

Please see http://www.w3.org/2002/06/registering-mediatype.html
for an overview of the intricities involved when a non-IETF organization
registers a MIME media type in the "standards tree" (aka "IETF
tree").

The below registration material is intended to satisfy the
requirements stated in draft-freed-media-type-reg-01.txt (which
superseded draft-freed-mime-p4-04.txt).

This "NOTE" is intended to be removed upon copying this document's
content into [SAMLv2Meta].

Acknowledgments: Thanks to Ned Freed, Larry Masinter, Graham Klyne,
and Chris Lilley for their comments on prior drafts of this
registration. The security considerations section leverages that of
http://www.iana.org/assignments/media-types/application/vnd.paos+xml,
by John Kemp.
>

To: [email-masked]
Subject: Registration of MIME media type application/samlmetadata+xml

Introduction
     This document defines a MIME media type --
     application/samlmetadata+xml -- for use with the XML
     serialization of Security Assertion Markup Language metadata.

     SAML is a work product of the OASIS Security Services Technical
     Committee [SSTC]. The SAML specifications define XML-based
     constructs with which one may make, and convey, security
     assertions. Using SAML, one can assert that an authentication
     event pertaining to some subject has occurred and convey said
     assertion to a relying party, for example.

     SAML profiles require agreements between system entities
     regarding identifiers, binding support, endpoints,
     certificates, keys, and so forth. Such information is treated
     as metadata by SAML v2.0. [SAMLv2Meta] specifies this metadata,
     as well as specifying metadata publication and resolution
     mechanisms. If the publishing protocol permits MIME-based
     identification of content types, then use of the
     application/samlmetadata+xml MIME media type is required.

MIME media type name: application

MIME subtype name: samlmetadata+xml

Required parameters: none

Optional parameters: charset
     Same as charset parameter of application/xml [RFC3023].

Encoding considerations:
     Same as for application/xml [RFC3023].

Security considerations:
     Per their specification, samlmetadata+xml typed objects do not
     contain executable content. However, these objects are
     XML-based [XML], and thus they have all of the general security
     considerations presented in section 10 of [RFC3023].

     SAML metadata [SAMLv2Meta] contains information whose integrity
     and authenticity is important ? identity provider and service
     provider public keys and endpoint addresses, for example.

     To counter potential issues, the publisher may sign
     samlmetadata+xml typed objects. Any such signature should be
     verified by the recipient of the data - both as a valid
     signature, and as being the signature of the publisher.

     Additionally, various of the publication protocols, e.g.
     HTTP-over-TLS/SSL, offer means for ensuring the authenticity of
     the publishing party and for protecting the metadata in
     transit. [SAMLv2Meta] also defines prescriptive metadata
     caching directives, as well as guidance on handling HTTPS
     redirects, trust processing, server authentication, and related
     items.

     For a more detailed discussion of SAML v2.0 metadata and its
     security considerations, please see [SAMLv2Meta]. For a
     discussion of overall SAML v2.0 security considerations and
     specific security-related design features, please refer to the
     SAML v2.0 specifications listed in the below bibliography. The
     specifications containing security-specific information are
     explicitly listed.

Interoperability considerations:
     SAML v2.0 metadata explicitly supports identifying the
     protocols and versions supported by the identified entities.
     For example, an identity provider entity can be denoted as
     supporting SAML v2.0, SAML v1.1 [SAMLv1.1], Liberty ID-FF 1.2
     [LAPFF], or even other protocols if they are unambiguously
     identifiable via URI [RFC2396]. This protocol support 
     information is conveyed via the protocolSupportEnumeration
     attribute of metadata objects of the RoleDescriptorType.

Published specification:
     [SAMLv2Meta] explicitly specifies use of the
     application/samlmetadata+xml MIME media type.

Applications which use this media type:
     Potentially any application implementing SAML v2.0, as well as
     those applications implementing specifications based on SAML,
     e.g. those available from the Liberty Alliance [LAP].

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 one of <EntityDescriptor>,
          <AffiliationDescriptor>, or <EntitiesDescriptor>, and will
          be in the SAMLv2.0 metadata namespace:

               urn:oasis:names:tc:SAML:2.0:metadata

     File extension(s): none
     Macintosh File Type Code(s): none

Person & email address to contact for further information:
     This registration is made on behalf of the OASIS Security
     Services Technical Committee (SSTC) Please refer to the SSTC
     website for current information on committee chairperson(s) and
     their contact addresses:
     http://www.oasis-open.org/committees/security/. Committee
     members should submit comments and potential errata to the
     [email-masked] list. Others should 
     submit them by filling out the web form located at
     http://www.oasis-open.org/committees/comments/form.php?wg_abbrev=

     Additionally, the SAML developer community email distribution
     list, [email-masked], may be employed to discuss
     usage of the application/samlmetadata+xml MIME media type. The
     "saml-dev" mailing list is publicly archived here:
     http://lists.oasis-open.org/archives/saml-dev/. To post to the 
     "saml-dev" mailing list, one must subscribe to it. To
     subscribe, send a message with the single word "subscribe" in
     the message body, to: [email-masked].

Intended usage: COMMON

Author/Change controller:
     The SAML specification sets are a work product of the OASIS
     Security Services Technical Committee (SSTC). OASIS and the
     SSTC have change control over the SAML specification sets.

Bibliography

     [LAP]          "Liberty Alliance Project". See
                    http://www.projectliberty.org/
                    
     [LAPFF]        Liberty Alliance Project: Federation Framework". See
                    http://www.projectliberty.org/resources
                    /specifications.php#box1

     [OASIS] "       Organization for the Advancement of Structured
                    Information Systems". See
                    http://www.oasis-open.org/
                    
     [RFC2396]      T. Berners-Lee, R. Fielding, L. Masinter, Uniform 
                    Resource Identifiers (URI): Generic Syntax. IETF
                    RFC 2396, August 1998. Available at
                    http://www.ietf.org/rfc/rfc2396.txt
                    
     [RFC3023]      M. Murata, S. St.Laurent, D. Kohn, "XML Media Types",
                    IETF Request for Comments 3023, January 2001.
                    Available as
                    http://www.rfc-editor.org/rfc/rfc3023.txt
                    
     [SAMLv1.1]     OASIS Security Services Technical Committee,
                    "Security Assertion Markup Language (SAML)
                    Version 1.1 Specification Set". OASIS Standard
                    200308, August 2003. Available as
                    http://www.oasis-open.org/committees/download.php
                    /3400/oasis-sstc-saml-1.1-pdf-xsd.zip
                    
     [SAMLv2.0]     OASIS Security Services Technical Committee,
                    "Security Assertion Markup Language (SAML)
                    Version 2.0 Specification Set". WORK IN
                    PROGRESS. Available at
                    http://www.oasis-open.org/committees/security/
                    
     [SAMLv2Bind]   S. Cantor et al., "Bindings for the OASIS Security
                    Assertion Markup Language (SAML) V2.0". OASIS 
                    SSTC, August 2004. Document ID
                    sstc-saml-bindings-2.0-cd-01, WORK IN PROGRESS. 
                    See http://www.oasis-open.org/committees/security/
                    
     [SAMLv2Core]   S. Cantor et al., "Assertions and Protocols for 
                    the OASIS Security Assertion Markup Language
                    (SAML) V2.0". OASIS SSTC, August 2004. Document
                    ID sstc-saml-core-2.0-cd-01, WORK IN PROGRESS.
                    See http://www.oasis-open.org/committees/security/
                    
     [SAMLv2Meta]   S. Cantor et al., Metadata for the OASIS Security 
                    Assertion Markup Language (SAML) V2.0. OASIS 
                    SSTC, August 2004. Document ID
                    sstc-saml-metadata-2.0-cd-01. See
                    http://www.oasis-open.org/committees/security/
                    
     [SAMLv2Prof]   S. Cantor et al., "Profiles for the OASIS Security
                    Assertion Markup Language (SAML) V2.0". OASIS 
                    SSTC, August 2004. Document ID
                    sstc-saml-profiles-2.0-cd-01, WORK IN PROGRESS. 
                    See http://www.oasis-open.org/committees/security/
                    
     [SAMLv2Sec]    F. Hirsch et al., "Security and Privacy
                    Considerations for the OASIS Security Assertion
                    Markup Language (SAML) V2.0". OASIS SSTC, August
                    2004, WORK IN PROGRESS. Document ID
                    sstc-saml-sec-consider-2.0-cd-01. See
                    http://www.oasis-open.org/committees/security/
                    
     [SSTC]         "OASIS Security Services Technical Committee". See
                    http://www.oasis-open.org/committees/security/
                    
     [XML]          Bray, T., Paoli, J., Sperberg-McQueen, C.M. and 
                    E. Maler, "Extensible Markup Language (XML) 1.0 
                    (Second Edition)", World Wide Web Consortium
                    Recommendation REC-xml, October 2000, Available 
                    as http://www.w3.org/TR/REC-xml

---
end

From: Jeff.Hodges at KingsMountain.com ([email-masked])
Date: Tue Jan  3 16:22:49 2006
Subject: for review: draft -01 of application/samlmetadata+xml registration
Message-ID: <[email-masked]>

  Registration of MIME media type application/samlmetadata+xml

<@@NOTE: This document is:

sstc-saml-2.0-application-samlmetadata-registration-01
Jeff Hodges <[email-masked]>
20-Sep-2004

This document is intended to be included in
sstc-saml-metadata-2.0-cd-02 (ie the next time [SAMLv2Meta] is
rev'd), as an appendix.

Please see http://www.w3.org/2002/06/registering-mediatype.html
for an overview of the intricities involved when a non-IETF organization
registers a MIME media type in the "standards tree" (aka "IETF
tree").

The below registration material is intended to satisfy the
requirements stated in draft-freed-media-type-reg-01.txt (which
superseded draft-freed-mime-p4-04.txt).

This "NOTE" is intended to be removed upon copying this document's
content into [SAMLv2Meta].

Acknowledgments: Thanks to Ned Freed, Larry Masinter, Graham Klyne,
and Chris Lilley for their comments on prior drafts of this
registration. The security considerations section leverages that of
http://www.iana.org/assignments/media-types/application/vnd.paos+xml,
by John Kemp.
>

To: [email-masked]
Subject: Registration of MIME media type application/samlmetadata+xml

Introduction
     This document defines a MIME media type --
     application/samlmetadata+xml -- for use with the XML
     serialization of Security Assertion Markup Language metadata.

     SAML is a work product of the OASIS Security Services Technical
     Committee [SSTC]. The SAML specifications define XML-based
     constructs with which one may make, and convey, security
     assertions. Using SAML, one can assert that an authentication
     event pertaining to some subject has occurred and convey said
     assertion to a relying party, for example.

     SAML profiles require agreements between system entities
     regarding identifiers, binding support, endpoints,
     certificates, keys, and so forth. Such information is treated
     as metadata by SAML v2.0. [SAMLv2Meta] specifies this metadata,
     as well as specifying metadata publication and resolution
     mechanisms. If the publishing protocol permits MIME-based
     identification of content types, then use of the
     application/samlmetadata+xml MIME media type is required.

MIME media type name: application

MIME subtype name: samlmetadata+xml

Required parameters: none

Optional parameters: charset
     Same as charset parameter of application/xml [RFC3023].

Encoding considerations:
     Same as for application/xml [RFC3023].

Security considerations:
     Per their specification, samlmetadata+xml typed objects do not
     contain executable content. However, these objects are
     XML-based [XML], and thus they have all of the general security
     considerations presented in section 10 of [RFC3023].

     SAML metadata [SAMLv2Meta] contains information whose integrity
     and authenticity is important ? identity provider and service
     provider public keys and endpoint addresses, for example.

     To counter potential issues, the publisher may sign
     samlmetadata+xml typed objects. Any such signature should be
     verified by the recipient of the data - both as a valid
     signature, and as being the signature of the publisher.

     Additionally, various of the publication protocols, e.g.
     HTTP-over-TLS/SSL, offer means for ensuring the authenticity of
     the publishing party and for protecting the metadata in
     transit. [SAMLv2Meta] also defines prescriptive metadata
     caching directives, as well as guidance on handling HTTPS
     redirects, trust processing, server authentication, and related
     items.

     For a more detailed discussion of SAML v2.0 metadata and its
     security considerations, please see [SAMLv2Meta]. For a
     discussion of overall SAML v2.0 security considerations and
     specific security-related design features, please refer to the
     SAML v2.0 specifications listed in the below bibliography. The
     specifications containing security-specific information are
     explicitly listed.

Interoperability considerations:
     SAML v2.0 metadata explicitly supports identifying the
     protocols and versions supported by the identified entities.
     For example, an identity provider entity can be denoted as
     supporting SAML v2.0, SAML v1.1 [SAMLv1.1], Liberty ID-FF 1.2
     [LAPFF], or even other protocols if they are unambiguously
     identifiable via URI [RFC2396]. This protocol support 
     information is conveyed via the protocolSupportEnumeration
     attribute of metadata objects of the RoleDescriptorType.

Published specification:
     [SAMLv2Meta] explicitly specifies use of the
     application/samlmetadata+xml MIME media type.

Applications which use this media type:
     Potentially any application implementing SAML v2.0, as well as
     those applications implementing specifications based on SAML,
     e.g. those available from the Liberty Alliance [LAP].

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 one of <EntityDescriptor>,
          <AffiliationDescriptor>, or <EntitiesDescriptor>, and will
          be in the SAMLv2.0 metadata namespace:

               urn:oasis:names:tc:SAML:2.0:metadata

     File extension(s): none
     Macintosh File Type Code(s): none

Person & email address to contact for further information:
     This registration is made on behalf of the OASIS Security
     Services Technical Committee (SSTC) Please refer to the SSTC
     website for current information on committee chairperson(s) and
     their contact addresses:
     http://www.oasis-open.org/committees/security/. Committee
     members should submit comments and potential errata to the
     [email-masked] list. Others should 
     submit them by filling out the web form located at
     http://www.oasis-open.org/committees/comments/form.php?wg_abbrev=

     Additionally, the SAML developer community email distribution
     list, [email-masked], may be employed to discuss
     usage of the application/samlmetadata+xml MIME media type. The
     "saml-dev" mailing list is publicly archived here:
     http://lists.oasis-open.org/archives/saml-dev/. To post to the 
     "saml-dev" mailing list, one must subscribe to it. To
     subscribe, send a message with the single word "subscribe" in
     the message body, to: [email-masked].

Intended usage: COMMON

Author/Change controller:
     The SAML specification sets are a work product of the OASIS
     Security Services Technical Committee (SSTC). OASIS and the
     SSTC have change control over the SAML specification sets.

Bibliography

     [LAP]          "Liberty Alliance Project". See
                    http://www.projectliberty.org/
                    
     [LAPFF]        Liberty Alliance Project: Federation Framework". See
                    http://www.projectliberty.org/resources
                    /specifications.php#box1

     [OASIS] "       Organization for the Advancement of Structured
                    Information Systems". See
                    http://www.oasis-open.org/
                    
     [RFC2396]      T. Berners-Lee, R. Fielding, L. Masinter, Uniform 
                    Resource Identifiers (URI): Generic Syntax. IETF
                    RFC 2396, August 1998. Available at
                    http://www.ietf.org/rfc/rfc2396.txt
                    
     [RFC3023]      M. Murata, S. St.Laurent, D. Kohn, "XML Media Types",
                    IETF Request for Comments 3023, January 2001.
                    Available as
                    http://www.rfc-editor.org/rfc/rfc3023.txt
                    
     [SAMLv1.1]     OASIS Security Services Technical Committee,
                    "Security Assertion Markup Language (SAML)
                    Version 1.1 Specification Set". OASIS Standard
                    200308, August 2003. Available as
                    http://www.oasis-open.org/committees/download.php
                    /3400/oasis-sstc-saml-1.1-pdf-xsd.zip
                    
     [SAMLv2.0]     OASIS Security Services Technical Committee,
                    "Security Assertion Markup Language (SAML)
                    Version 2.0 Specification Set". WORK IN
                    PROGRESS. Available at
                    http://www.oasis-open.org/committees/security/
                    
     [SAMLv2Bind]   S. Cantor et al., "Bindings for the OASIS Security
                    Assertion Markup Language (SAML) V2.0". OASIS 
                    SSTC, August 2004. Document ID
                    sstc-saml-bindings-2.0-cd-01, WORK IN PROGRESS. 
                    See http://www.oasis-open.org/committees/security/
                    
     [SAMLv2Core]   S. Cantor et al., "Assertions and Protocols for 
                    the OASIS Security Assertion Markup Language
                    (SAML) V2.0". OASIS SSTC, August 2004. Document
                    ID sstc-saml-core-2.0-cd-01, WORK IN PROGRESS.
                    See http://www.oasis-open.org/committees/security/
                    
     [SAMLv2Meta]   S. Cantor et al., Metadata for the OASIS Security 
                    Assertion Markup Language (SAML) V2.0. OASIS 
                    SSTC, August 2004. Document ID
                    sstc-saml-metadata-2.0-cd-01. See
                    http://www.oasis-open.org/committees/security/
                    
     [SAMLv2Prof]   S. Cantor et al., "Profiles for the OASIS Security
                    Assertion Markup Language (SAML) V2.0". OASIS 
                    SSTC, August 2004. Document ID
                    sstc-saml-profiles-2.0-cd-01, WORK IN PROGRESS. 
                    See http://www.oasis-open.org/committees/security/
                    
     [SAMLv2Sec]    F. Hirsch et al., "Security and Privacy
                    Considerations for the OASIS Security Assertion
                    Markup Language (SAML) V2.0". OASIS SSTC, August
                    2004, WORK IN PROGRESS. Document ID
                    sstc-saml-sec-consider-2.0-cd-01. See
                    http://www.oasis-open.org/committees/security/
                    
     [SSTC]         "OASIS Security Services Technical Committee". See
                    http://www.oasis-open.org/committees/security/
                    
     [XML]          Bray, T., Paoli, J., Sperberg-McQueen, C.M. and 
                    E. Maler, "Extensible Markup Language (XML) 1.0 
                    (Second Edition)", World Wide Web Consortium
                    Recommendation REC-xml, October 2000, Available 
                    as http://www.w3.org/TR/REC-xml

---
end

From: Jeff.Hodges at KingsMountain.com ([email-masked])
Date: Mon Sep 20 21:33:31 2004
Subject: for review: draft -02 of application/samlassertion+xml registration
Message-ID: <[email-masked]>

   Registration of MIME media type application/samlassertion+xml

<@@NOTE: This document is:

sstc-saml-2.0-application-samlassertion-registration-02
Jeff Hodges <[email-masked]>
20-Sep-2004

This document supersedes draft-hodges-saml-mediatype-02.txt. It is
intended to be included in sstc-saml-bindings-2.0-cd-02 (ie the next
time [SAMLv2Bind] is rev'd), as an appendix.

Please see http://www.w3.org/2002/06/registering-mediatype.html
for an overview of the intricities involved when a non-IETF organization
registers a MIME media type in the ?standards tree? (aka ?IETF
tree?).

The below registration material is intended to satisfy the
requirements stated in draft-freed-media-type-reg-01.txt (which
superseded draft-freed-mime-p4-04.txt).

This ?NOTE? is intended to be removed upon copying this document's
content into [SAMLv2Bind].

Acknowledgments: Thanks to Ned Freed, Larry Masinter, Graham Klyne,
and Chris Lilley for their comments on prior drafts of this
registration. The security considerations section leverages that of
http://www.iana.org/assignments/media-types/application/vnd.paos+xml,
by John Kemp.
>

To: [email-masked]
Subject: Registration of MIME media type application/samlassertion+xml

Introduction
     This document defines a MIME media type --
     application/samlassertion+xml -- for use with the XML
     serialization of SAML (Security Assertion Markup Language)
     assertions.

     The SAML specification sets -- [SAMLv1.0], [SAMLv1.1],
     [SAMLv2.0] -- are work products of the OASIS Security Services
     Technical Committee [SSTC]. The SAML specifications define
     XML-based constructs with which one may make, and convey,
     security assertions. Using SAML, one can assert that an
     authentication event pertaining to some subject has occured and
     convey said assertion to a relying party, for example.

     SAML assertions, which are explicitly versioned, are defined by
     [SAMLv1Core], [SAMLv11Core], and [SAMLv2Core].

MIME media type name: application

MIME subtype name: samlassertion+xml

Required parameters: none

Optional parameters: charset
     Same as charset parameter of application/xml [RFC3023].

Encoding considerations:
     Same as for application/xml [RFC3023].

Security considerations:
     Per their specification, samlassertion+xml typed objects do not
     contain executable content. However, SAML assertions are
     XML-based objects [XML]. As such, they have all of the general
     security considerations presented in section 10 of [RFC3023],
     as well as additional ones, since they are explicit security
     objects. For example, samlassertion+xml typed objects will
     often contain data that may identify or pertain to a natural
     person, and may be used as a basis for sessions and access
     control decisions.

     To counter potential issues, samlassertion+xml typed objects
     contain data that should be signed appropriately by the sender.
     Any such signature must be verified by the recipient of the
     data - both as a valid signature, and as being the signature of
     the sender. Issuers of samlassertion+xml objects containing
     SAMLv2 assertions may also encrypt all, or portions of, the
     assertions [SAMLv2Core].

     In addition, SAML profiles and protocol bindings specify use of
     secure channels as appropriate.

     [SAMLv2.0] incorporates various privacy-protection techniques
     in its design. For example: opaque handles, specific to
     interactions between specific system entities, may be assigned
     to subjects. The handles are mappable to wider-context
     identifiers (e.g. email addresses, account identifiers, etc) by
     only the specific parties.

     For a more detailed discussion of SAML security considerations
     and specific security-related design techniques, please refer
     to the SAML specifications listed in the below bibliography.
     The specifications containing security-specific information
     have been explicitly listed for each version of SAML.

Interoperability considerations:
     SAML assertions are explicitly versioned. Relying parties
     should ensure that they observe assertion version information
     and behave accordingly. See "Chapter 4 SAML Versioning" in
     [SAMLv1Core], [SAMLv11Core], or [SAMLv2Core], as appropriate.

Published specification:
     [SAMLv2Bind] explicitly specifies use of the
     application/samlassertion+xml MIME media type. However, it is
     conceivable that non-SAMLv2 assertions (i.e. SAMLv1 and/or
     SAMLv1.1) might in practice be conveyed using SAMLv2 bindings.

Applications which use this media type:
     Potentially any application implementing SAML, as well as those
     applications implementing specifications based on SAML, e.g.
     those available from the Liberty Alliance [LAP].

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 <Assertion>, and will be in one of the
          version-specific SAML assertion XML namespaces, 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" represents any XML
          namespace prefix that maps to the SAMLv2.0 assertion 
          namespace URI:

               urn:oasis:names:tc:SAML:2.0:assertion

     File extension(s): none
     Macintosh File Type Code(s): none

Person & email address to contact for further information:
     This registration is made on behalf of the OASIS Security
     Services Technical Committee (SSTC) Please refer to the SSTC
     website for current information on committee chairperson(s) and
     their contact addresses:
     http://www.oasis-open.org/committees/security/. Committee
     members should submit comments and potential errata to the
     [email-masked] list. Others should 
     submit them by filling out the web form located at
     http://www.oasis-open.org/committees/comments/form.php?wg_abbrev=

     Additionally, the SAML developer community email distribution
     list, [email-masked], may be employed to discuss
     usage of the application/samlassertion+xml MIME media type. The
     "saml-dev" mailing list is publicly archived here:
     http://lists.oasis-open.org/archives/saml-dev/. To post to the 
     "saml-dev" mailing list, one must subscribe to it. To
     subscribe, send a message with the single word "subscribe" in
     the message body, to: [email-masked].

Intended usage: COMMON

Author/Change controller:
     The SAML specification sets are a work product of the OASIS
     Security Services Technical Committee (SSTC). OASIS and the
     SSTC have change control over the SAML specification sets.

Bibliography

     [LAP] ?         Liberty Alliance Project?. See
                    http://www.projectliberty.org/
                    
     [OASIS] ?       Organization for the Advancement of Structured
                    Information Systems?. See
                    http://www.oasis-open.org/
                    
     [RFC3023]      M. Murata, S. St.Laurent, D. Kohn, ?XML Media Types?,
                    IETF Request for Comments 3023, January 2001.
                    Available as
                    http://www.rfc-editor.org/rfc/rfc3023.txt
                    
     [SAMLv1.0]     OASIS Security Services Technical Committee,
                    ?Security Assertion Markup Language (SAML)
                    Version 1.0 Specification Set?. OASIS Standard
                    200205, November 2002. Available as
                    http://www.oasis-open.org/committees/download.php
                    /2290/oasis-sstc-saml-1.0.zip
                    
     [SAMLv1Bind]   Prateek Mishra et al., ?Bindings and Profiles for
                    the OASIS Security Assertion Markup Language
                    (SAML)?, OASIS, November 2002. Document ID
                    oasis-sstc-saml-bindings-1.0. See
                    http://www.oasis-open.org/committees/security/
                    
     [SAMLv1Core]   Phillip Hallam-Baker et al., ?Assertions and
                    Protocol for the OASIS Security Assertion Markup
                    Language (SAML)?, OASIS, November 2002. Document
                    ID oasis-sstc-saml-core-1.0. See
                    http://www.oasis-open.org/committees/security/
                    
     [SAMLv1Sec]    Chris McLaren et al., ?Security Considerations for
                    the OASIS Security Assertion Markup Language
                    (SAML)?, OASIS, November 2002. Document ID
                    oasis-sstc-saml-sec-consider-1.0. See
                    http://www.oasis-open.org/committees/security/
                    
     [SAMLv1.1]     OASIS Security Services Technical Committee,
                    ?Security Assertion Markup Language (SAML)
                    Version 1.1 Specification Set?. OASIS Standard
                    200308, August 2003. Available as
                    http://www.oasis-open.org/committees/download.php
                    /3400/oasis-sstc-saml-1.1-pdf-xsd.zip
                    
     [SAMLv11Bind]  E. Maler et al. ?Bindings and Profiles for the
                    OASIS Security Assertion Markup Language
                    (SAML)?. OASIS, September 2003. Document ID
                    oasis-sstc-saml-bindings-1.1.
                    http://www.oasis-open.org/committees/security/
                    
     [SAMLv11Core]  E. Maler et al. ?Assertions and Protocol for the
                    OASIS Security Assertion Markup Language
                    (SAML)?. OASIS, September 2003. Document ID
                    oasis-sstc-saml-core-1.1.
                    http://www.oasis-open.org/committees/security/
                    
     [SAMLv11Sec]   E. Maler et al. ?Security Considerations for the
                    OASIS Security Assertion Markup Language
                    (SAML)?. OASIS, September 2003. Document ID
                    oasis-sstc-saml-sec-consider-1.1.
                    http://www.oasis-open.org/committees/security/
                    
     [SAMLv2.0]     OASIS Security Services Technical Committee,
                    ?Security Assertion Markup Language (SAML)
                    Version 2.0 Specification Set?. WORK IN
                    PROGRESS. Available at
                    http://www.oasis-open.org/committees/security/
                    
     [SAMLv2Bind]   S. Cantor et al., ?Bindings for the OASIS Security
                    Assertion Markup Language (SAML) V2.0?. OASIS 
                    SSTC, August 2004. Document ID
                    sstc-saml-bindings-2.0-cd-01, WORK IN PROGRESS. 
                    See http://www.oasis-open.org/committees/security/
                    
     [SAMLv2Core]   S. Cantor et al., ?Assertions and Protocols for
                    the OASIS Security Assertion Markup Language
                    (SAML) V2.0?. OASIS SSTC, August 2004. Document
                    ID sstc-saml-core-2.0-cd-01, WORK IN PROGRESS.
                    See http://www.oasis-open.org/committees/security/
                    
     [SAMLv2Prof]   S. Cantor et al., ?Profiles for the OASIS Security
                    Assertion Markup Language (SAML) V2.0?. OASIS 
                    SSTC, August 2004. Document ID
                    sstc-saml-profiles-2.0-cd-01, WORK IN PROGRESS. 
                    See http://www.oasis-open.org/committees/security/
                    
     [SAMLv2Sec]    F. Hirsch et al., ?Security and Privacy
                    Considerations for the OASIS Security Assertion
                    Markup Language (SAML) V2.0?. OASIS SSTC, August
                    2004, WORK IN PROGRESS. Document ID
                    sstc-saml-sec-consider-2.0-cd-01. See
                    http://www.oasis-open.org/committees/security/
                    
     [SSTC]         ?OASIS Security Services Technical Committee?. See
                    http://www.oasis-open.org/committees/security/
                    
     [XML]          Bray, T., Paoli, J., Sperberg-McQueen, C.M. and 
                    E. Maler,"Extensible Markup Language (XML) 1.0 
                    (Second Edition)", World Wide Web Consortium
                    Recommendation REC-xml, October 2000, Available 
                    as http://www.w3.org/TR/REC-xml

---
end

From: Jeff.Hodges at KingsMountain.com ([email-masked])
Date: Tue Jan  3 16:22:49 2006
Subject: for review: draft -02 of application/samlassertion+xml registration
Message-ID: <[email-masked]>

   Registration of MIME media type application/samlassertion+xml

<@@NOTE: This document is:

sstc-saml-2.0-application-samlassertion-registration-02
Jeff Hodges <[email-masked]>
20-Sep-2004

This document supersedes draft-hodges-saml-mediatype-02.txt. It is
intended to be included in sstc-saml-bindings-2.0-cd-02 (ie the next
time [SAMLv2Bind] is rev'd), as an appendix.

Please see http://www.w3.org/2002/06/registering-mediatype.html
for an overview of the intricities involved when a non-IETF organization
registers a MIME media type in the ?standards tree? (aka ?IETF
tree?).

The below registration material is intended to satisfy the
requirements stated in draft-freed-media-type-reg-01.txt (which
superseded draft-freed-mime-p4-04.txt).

This ?NOTE? is intended to be removed upon copying this document's
content into [SAMLv2Bind].

Acknowledgments: Thanks to Ned Freed, Larry Masinter, Graham Klyne,
and Chris Lilley for their comments on prior drafts of this
registration. The security considerations section leverages that of
http://www.iana.org/assignments/media-types/application/vnd.paos+xml,
by John Kemp.
>

To: [email-masked]
Subject: Registration of MIME media type application/samlassertion+xml

Introduction
     This document defines a MIME media type --
     application/samlassertion+xml -- for use with the XML
     serialization of SAML (Security Assertion Markup Language)
     assertions.

     The SAML specification sets -- [SAMLv1.0], [SAMLv1.1],
     [SAMLv2.0] -- are work products of the OASIS Security Services
     Technical Committee [SSTC]. The SAML specifications define
     XML-based constructs with which one may make, and convey,
     security assertions. Using SAML, one can assert that an
     authentication event pertaining to some subject has occured and
     convey said assertion to a relying party, for example.

     SAML assertions, which are explicitly versioned, are defined by
     [SAMLv1Core], [SAMLv11Core], and [SAMLv2Core].

MIME media type name: application

MIME subtype name: samlassertion+xml

Required parameters: none

Optional parameters: charset
     Same as charset parameter of application/xml [RFC3023].

Encoding considerations:
     Same as for application/xml [RFC3023].

Security considerations:
     Per their specification, samlassertion+xml typed objects do not
     contain executable content. However, SAML assertions are
     XML-based objects [XML]. As such, they have all of the general
     security considerations presented in section 10 of [RFC3023],
     as well as additional ones, since they are explicit security
     objects. For example, samlassertion+xml typed objects will
     often contain data that may identify or pertain to a natural
     person, and may be used as a basis for sessions and access
     control decisions.

     To counter potential issues, samlassertion+xml typed objects
     contain data that should be signed appropriately by the sender.
     Any such signature must be verified by the recipient of the
     data - both as a valid signature, and as being the signature of
     the sender. Issuers of samlassertion+xml objects containing
     SAMLv2 assertions may also encrypt all, or portions of, the
     assertions [SAMLv2Core].

     In addition, SAML profiles and protocol bindings specify use of
     secure channels as appropriate.

     [SAMLv2.0] incorporates various privacy-protection techniques
     in its design. For example: opaque handles, specific to
     interactions between specific system entities, may be assigned
     to subjects. The handles are mappable to wider-context
     identifiers (e.g. email addresses, account identifiers, etc) by
     only the specific parties.

     For a more detailed discussion of SAML security considerations
     and specific security-related design techniques, please refer
     to the SAML specifications listed in the below bibliography.
     The specifications containing security-specific information
     have been explicitly listed for each version of SAML.

Interoperability considerations:
     SAML assertions are explicitly versioned. Relying parties
     should ensure that they observe assertion version information
     and behave accordingly. See "Chapter 4 SAML Versioning" in
     [SAMLv1Core], [SAMLv11Core], or [SAMLv2Core], as appropriate.

Published specification:
     [SAMLv2Bind] explicitly specifies use of the
     application/samlassertion+xml MIME media type. However, it is
     conceivable that non-SAMLv2 assertions (i.e. SAMLv1 and/or
     SAMLv1.1) might in practice be conveyed using SAMLv2 bindings.

Applications which use this media type:
     Potentially any application implementing SAML, as well as those
     applications implementing specifications based on SAML, e.g.
     those available from the Liberty Alliance [LAP].

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 <Assertion>, and will be in one of the
          version-specific SAML assertion XML namespaces, 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" represents any XML
          namespace prefix that maps to the SAMLv2.0 assertion 
          namespace URI:

               urn:oasis:names:tc:SAML:2.0:assertion

     File extension(s): none
     Macintosh File Type Code(s): none

Person & email address to contact for further information:
     This registration is made on behalf of the OASIS Security
     Services Technical Committee (SSTC) Please refer to the SSTC
     website for current information on committee chairperson(s) and
     their contact addresses:
     http://www.oasis-open.org/committees/security/. Committee
     members should submit comments and potential errata to the
     [email-masked] list. Others should 
     submit them by filling out the web form located at
     http://www.oasis-open.org/committees/comments/form.php?wg_abbrev=

     Additionally, the SAML developer community email distribution
     list, [email-masked], may be employed to discuss
     usage of the application/samlassertion+xml MIME media type. The
     "saml-dev" mailing list is publicly archived here:
     http://lists.oasis-open.org/archives/saml-dev/. To post to the 
     "saml-dev" mailing list, one must subscribe to it. To
     subscribe, send a message with the single word "subscribe" in
     the message body, to: [email-masked].

Intended usage: COMMON

Author/Change controller:
     The SAML specification sets are a work product of the OASIS
     Security Services Technical Committee (SSTC). OASIS and the
     SSTC have change control over the SAML specification sets.

Bibliography

     [LAP] ?         Liberty Alliance Project?. See
                    http://www.projectliberty.org/
                    
     [OASIS] ?       Organization for the Advancement of Structured
                    Information Systems?. See
                    http://www.oasis-open.org/
                    
     [RFC3023]      M. Murata, S. St.Laurent, D. Kohn, ?XML Media Types?,
                    IETF Request for Comments 3023, January 2001.
                    Available as
                    http://www.rfc-editor.org/rfc/rfc3023.txt
                    
     [SAMLv1.0]     OASIS Security Services Technical Committee,
                    ?Security Assertion Markup Language (SAML)
                    Version 1.0 Specification Set?. OASIS Standard
                    200205, November 2002. Available as
                    http://www.oasis-open.org/committees/download.php
                    /2290/oasis-sstc-saml-1.0.zip
                    
     [SAMLv1Bind]   Prateek Mishra et al., ?Bindings and Profiles for
                    the OASIS Security Assertion Markup Language
                    (SAML)?, OASIS, November 2002. Document ID
                    oasis-sstc-saml-bindings-1.0. See
                    http://www.oasis-open.org/committees/security/
                    
     [SAMLv1Core]   Phillip Hallam-Baker et al., ?Assertions and
                    Protocol for the OASIS Security Assertion Markup
                    Language (SAML)?, OASIS, November 2002. Document
                    ID oasis-sstc-saml-core-1.0. See
                    http://www.oasis-open.org/committees/security/
                    
     [SAMLv1Sec]    Chris McLaren et al., ?Security Considerations for
                    the OASIS Security Assertion Markup Language
                    (SAML)?, OASIS, November 2002. Document ID
                    oasis-sstc-saml-sec-consider-1.0. See
                    http://www.oasis-open.org/committees/security/
                    
     [SAMLv1.1]     OASIS Security Services Technical Committee,
                    ?Security Assertion Markup Language (SAML)
                    Version 1.1 Specification Set?. OASIS Standard
                    200308, August 2003. Available as
                    http://www.oasis-open.org/committees/download.php
                    /3400/oasis-sstc-saml-1.1-pdf-xsd.zip
                    
     [SAMLv11Bind]  E. Maler et al. ?Bindings and Profiles for the
                    OASIS Security Assertion Markup Language
                    (SAML)?. OASIS, September 2003. Document ID
                    oasis-sstc-saml-bindings-1.1.
                    http://www.oasis-open.org/committees/security/
                    
     [SAMLv11Core]  E. Maler et al. ?Assertions and Protocol for the
                    OASIS Security Assertion Markup Language
                    (SAML)?. OASIS, September 2003. Document ID
                    oasis-sstc-saml-core-1.1.
                    http://www.oasis-open.org/committees/security/
                    
     [SAMLv11Sec]   E. Maler et al. ?Security Considerations for the
                    OASIS Security Assertion Markup Language
                    (SAML)?. OASIS, September 2003. Document ID
                    oasis-sstc-saml-sec-consider-1.1.
                    http://www.oasis-open.org/committees/security/
                    
     [SAMLv2.0]     OASIS Security Services Technical Committee,
                    ?Security Assertion Markup Language (SAML)
                    Version 2.0 Specification Set?. WORK IN
                    PROGRESS. Available at
                    http://www.oasis-open.org/committees/security/
                    
     [SAMLv2Bind]   S. Cantor et al., ?Bindings for the OASIS Security
                    Assertion Markup Language (SAML) V2.0?. OASIS 
                    SSTC, August 2004. Document ID
                    sstc-saml-bindings-2.0-cd-01, WORK IN PROGRESS. 
                    See http://www.oasis-open.org/committees/security/
                    
     [SAMLv2Core]   S. Cantor et al., ?Assertions and Protocols for
                    the OASIS Security Assertion Markup Language
                    (SAML) V2.0?. OASIS SSTC, August 2004. Document
                    ID sstc-saml-core-2.0-cd-01, WORK IN PROGRESS.
                    See http://www.oasis-open.org/committees/security/
                    
     [SAMLv2Prof]   S. Cantor et al., ?Profiles for the OASIS Security
                    Assertion Markup Language (SAML) V2.0?. OASIS 
                    SSTC, August 2004. Document ID
                    sstc-saml-profiles-2.0-cd-01, WORK IN PROGRESS. 
                    See http://www.oasis-open.org/committees/security/
                    
     [SAMLv2Sec]    F. Hirsch et al., ?Security and Privacy
                    Considerations for the OASIS Security Assertion
                    Markup Language (SAML) V2.0?. OASIS SSTC, August
                    2004, WORK IN PROGRESS. Document ID
                    sstc-saml-sec-consider-2.0-cd-01. See
                    http://www.oasis-open.org/committees/security/
                    
     [SSTC]         ?OASIS Security Services Technical Committee?. See
                    http://www.oasis-open.org/committees/security/
                    
     [XML]          Bray, T., Paoli, J., Sperberg-McQueen, C.M. and 
                    E. Maler,"Extensible Markup Language (XML) 1.0 
                    (Second Edition)", World Wide Web Consortium
                    Recommendation REC-xml, October 2000, Available 
                    as http://www.w3.org/TR/REC-xml

---
end

From: chris at w3.org (Chris Lilley)
Date: Mon Sep 20 19:12:15 2004
Subject: Please review: DRAFT Reg of application/samlassertion+xml
In-Reply-To: <[email-masked]>
References: Chris Lilley <[email-masked]> 's message of  Mon, 20 Sep 2004 13:37:29 +0200 <[email-masked]>
Message-ID: <[email-masked]>

On Monday, September 20, 2004, 6:28:11 PM, Jeff wrote:

>> On Monday, September 20, 2004, 12:23:33 PM, Graham wrote:
>> 
>> GK> That wording looks OK to me.
>> 
>> GK> One additional point to consider, but I think it's marginal:  the case when
>> GK> the default namespace is a SAML namespace.  (In practice, I think anyone
>> GK> who knows enough about XML to use this stuff will understand that case is
>> GK> implied, but maybe it's better to be explicit.)
>> 
>> I agree (especially in a section on magic numbers and by extension,
>> magic strings) its better to avoid any mention of potentially magical
>> prefixes in the registration document.
>> 
>> Just state the URI of the namespace or namespaces. Since this is a +xml
>> type, its okay to assume that an XML processor is being used rather than
>> plain text regexps and so on. State the element local name and its
>> namespace, and you are all set.
>> 

JHKc> Ok, how about this...

JHKc> Magic number(s):
JHKc>     In general, the same as for application/xml [RFC3023]. In
JHKc>     particular, the XML root element of the returned object will be
JHKc>     <Assertion>, and will be in one of the version-specific SAML  
JHKc>     assertion XML namespaces, as defined by the appropriate version-
JHKc>     specific SAML "core" specification (see bibliography).

JHKc>     With SAMLv2.0 specifically, the root element of the returned
JHKc>     object may be either <saml:Assertion> or <saml:EncryptedAssertion>,
JHKc>     where "saml" represents any XML namspace prefix that maps to the
JHKc>     SAMLv2.0 assertion namespace URI: 

JHKc>        urn:oasis:names:tc:SAML:2.0:assertion.

Yeas, that is a lot better.

-- 
 Chris Lilley                    mailto:[email-masked]
 Chair, W3C SVG Working Group
 Member, W3C Technical Architecture Group

From: chris at w3.org (Chris Lilley)
Date: Tue Jan  3 16:22:49 2006
Subject: Please review: DRAFT Reg of application/samlassertion+xml
In-Reply-To: <[email-masked]>
References: Chris Lilley <[email-masked]> 's message of  Mon, 20 Sep 2004 13:37:29 +0200 <[email-masked]>
Message-ID: <[email-masked]>

On Monday, September 20, 2004, 6:28:11 PM, Jeff wrote:

>> On Monday, September 20, 2004, 12:23:33 PM, Graham wrote:
>> 
>> GK> That wording looks OK to me.
>> 
>> GK> One additional point to consider, but I think it's marginal:  the case when
>> GK> the default namespace is a SAML namespace.  (In practice, I think anyone
>> GK> who knows enough about XML to use this stuff will understand that case is
>> GK> implied, but maybe it's better to be explicit.)
>> 
>> I agree (especially in a section on magic numbers and by extension,
>> magic strings) its better to avoid any mention of potentially magical
>> prefixes in the registration document.
>> 
>> Just state the URI of the namespace or namespaces. Since this is a +xml
>> type, its okay to assume that an XML processor is being used rather than
>> plain text regexps and so on. State the element local name and its
>> namespace, and you are all set.
>> 

JHKc> Ok, how about this...

JHKc> Magic number(s):
JHKc>     In general, the same as for application/xml [RFC3023]. In
JHKc>     particular, the XML root element of the returned object will be
JHKc>     <Assertion>, and will be in one of the version-specific SAML  
JHKc>     assertion XML namespaces, as defined by the appropriate version-
JHKc>     specific SAML "core" specification (see bibliography).

JHKc>     With SAMLv2.0 specifically, the root element of the returned
JHKc>     object may be either <saml:Assertion> or <saml:EncryptedAssertion>,
JHKc>     where "saml" represents any XML namspace prefix that maps to the
JHKc>     SAMLv2.0 assertion namespace URI: 

JHKc>        urn:oasis:names:tc:SAML:2.0:assertion.

Yeas, that is a lot better.

-- 
 Chris Lilley                    mailto:[email-masked]
 Chair, W3C SVG Working Group
 Member, W3C Technical Architecture Group

From: Jeff.Hodges at KingsMountain.com ([email-masked])
Date: Mon Sep 20 18:28:18 2004
Subject: Please review: DRAFT Reg of application/samlassertion+xml 
In-Reply-To: Chris Lilley <[email-masked]> 's message of  Mon, 20 Sep 2004 13:37:29 +0200
Message-ID: <[email-masked]>

> On Monday, September 20, 2004, 12:23:33 PM, Graham wrote:
> 
> GK> That wording looks OK to me.
> 
> GK> One additional point to consider, but I think it's marginal:  the case when
> GK> the default namespace is a SAML namespace.  (In practice, I think anyone
> GK> who knows enough about XML to use this stuff will understand that case is
> GK> implied, but maybe it's better to be explicit.)
> 
> I agree (especially in a section on magic numbers and by extension,
> magic strings) its better to avoid any mention of potentially magical
> prefixes in the registration document.
> 
> Just state the URI of the namespace or namespaces. Since this is a +xml
> type, its okay to assume that an XML processor is being used rather than
> plain text regexps and so on. State the element local name and its
> namespace, and you are all set.
> 

Ok, how about this...

Magic number(s):
    In general, the same as for application/xml [RFC3023]. In
    particular, the XML root element of the returned object will be
    <Assertion>, and will be in one of the version-specific SAML  
    assertion XML namespaces, 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" represents any XML namspace prefix that maps to the
    SAMLv2.0 assertion namespace URI: 

       urn:oasis:names:tc:SAML:2.0:assertion.

JeffH

From: Jeff.Hodges at KingsMountain.com ([email-masked])
Date: Tue Jan  3 16:22:49 2006
Subject: Please review: DRAFT Reg of application/samlassertion+xml 
In-Reply-To: Chris Lilley <[email-masked]> 's message of  Mon, 20 Sep 2004 13:37:29 +0200
Message-ID: <[email-masked]>

> On Monday, September 20, 2004, 12:23:33 PM, Graham wrote:
> 
> GK> That wording looks OK to me.
> 
> GK> One additional point to consider, but I think it's marginal:  the case when
> GK> the default namespace is a SAML namespace.  (In practice, I think anyone
> GK> who knows enough about XML to use this stuff will understand that case is
> GK> implied, but maybe it's better to be explicit.)
> 
> I agree (especially in a section on magic numbers and by extension,
> magic strings) its better to avoid any mention of potentially magical
> prefixes in the registration document.
> 
> Just state the URI of the namespace or namespaces. Since this is a +xml
> type, its okay to assume that an XML processor is being used rather than
> plain text regexps and so on. State the element local name and its
> namespace, and you are all set.
> 

Ok, how about this...

Magic number(s):
    In general, the same as for application/xml [RFC3023]. In
    particular, the XML root element of the returned object will be
    <Assertion>, and will be in one of the version-specific SAML  
    assertion XML namespaces, 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" represents any XML namspace prefix that maps to the
    SAMLv2.0 assertion namespace URI: 

       urn:oasis:names:tc:SAML:2.0:assertion.

JeffH

From: chris at w3.org (Chris Lilley)
Date: Mon Sep 20 13:37:35 2004
Subject: Please review: DRAFT Reg of application/samlassertion+xml
In-Reply-To: <[email-masked]>
References: <[email-masked]>
Message-ID: <[email-masked]>

On Monday, September 20, 2004, 12:23:33 PM, Graham wrote:

GK> Jeff,

GK> That wording looks OK to me.

GK> One additional point to consider, but I think it's marginal:  the case when
GK> the default namespace is a SAML namespace.  (In practice, I think anyone
GK> who knows enough about XML to use this stuff will understand that case is
GK> implied, but maybe it's better to be explicit.)

I agree (especially in a section on magic numbers and by extension,
magic strings) its better to avoid any mention of potentially magical
prefixes in the registration document.

Just state the URI of the namespace or namespaces. Since this is a +xml
type, its okay to assume that an XML processor is being used rather than
plain text regexps and so on. State the element local name and its
namespace, and you are all set.

GK> #g
GK> --

GK> At 11:52 06/09/04 -0700, you wrote:
>> > 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

GK> ------------
GK> Graham Klyne
GK> For email:
GK> http://www.ninebynine.org/#Contact

-- 
 Chris Lilley                    mailto:[email-masked]
 Chair, W3C SVG Working Group
 Member, W3C Technical Architecture Group

From: chris at w3.org (Chris Lilley)
Date: Tue Jan  3 16:22:49 2006
Subject: Please review: DRAFT Reg of application/samlassertion+xml
In-Reply-To: <[email-masked]>
References: <[email-masked]>
Message-ID: <[email-masked]>

On Monday, September 20, 2004, 12:23:33 PM, Graham wrote:

GK> Jeff,

GK> That wording looks OK to me.

GK> One additional point to consider, but I think it's marginal:  the case when
GK> the default namespace is a SAML namespace.  (In practice, I think anyone
GK> who knows enough about XML to use this stuff will understand that case is
GK> implied, but maybe it's better to be explicit.)

I agree (especially in a section on magic numbers and by extension,
magic strings) its better to avoid any mention of potentially magical
prefixes in the registration document.

Just state the URI of the namespace or namespaces. Since this is a +xml
type, its okay to assume that an XML processor is being used rather than
plain text regexps and so on. State the element local name and its
namespace, and you are all set.

GK> #g
GK> --

GK> At 11:52 06/09/04 -0700, you wrote:
>> > 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

GK> ------------
GK> Graham Klyne
GK> For email:
GK> http://www.ninebynine.org/#Contact

-- 
 Chris Lilley                    mailto:[email-masked]
 Chair, W3C SVG Working Group
 Member, W3C Technical Architecture Group

From: gk at ninebynine.org (Graham Klyne)
Date: Tue Jan  3 16:22:49 2006
Subject: Please review: DRAFT Reg of application/samlassertion+xml 
Message-ID: <[email-masked]>

Jeff,

That wording looks OK to me.

One additional point to consider, but I think it's marginal:  the case when 
the default namespace is a SAML namespace.  (In practice, I think anyone 
who knows enough about XML to use this stuff will understand that case is 
implied, but maybe it's better to be explicit.)

#g
--

At 11:52 06/09/04 -0700, you wrote:
> > 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

------------
Graham Klyne
For email:
http://www.ninebynine.org/#Contact

From: ned.freed at mrochek.com ([email-masked])
Date: Thu Sep 16 17:52:14 2004
Subject: Registration for application/gdiff
In-Reply-To: "Your message dated Mon, 09 Aug 2004 09:22:16 -0700" <[email-masked]>
References: <[email-masked]>
Message-ID: <[email-masked]>

> I'm trying to register a MIME type officially for application/gdiff.
> This type was defined in a W3C NOTE several years ago:

> <http://www.w3.org/TR/NOTE-gdiff-19970901>

> That Note defines the MIME type but apparently the authors never
> registered the MIME type with IANA.  Now we'd like to use gdiff in
> applications where we'd be using the MIME type so having it officially
> registered would be nice.   For example:

> <http://www.ietf.org/internet-drafts/draft-dusseault-http-patch-03.txt>
>   (try -04 if -03 turns up not found)

> I submitted the registration through the IANA web form a couple weeks
> ago but haven't gotten a response other than the automated form
> submission response.

AFAIK it hasn't been passed on to me as media types reviewer. But if it had
been I would have had to reject it; media types in the standards tree have to 
be handled by the IESG. Under the new rules it is OK for such a media type not
to be specified in an RFC, but there has to be a document with a proper
registration form somewhere and the IESG has to approve it.

> Is this smoothly underway or is there anything
> else I need to or can optionally do to help this registration out?

The document you refer to doesn't contain a registration form. As such,
it cannot be registered as is. I see two possibilities:

(1) Revise the document to contain a proper registration form and contact
    the IESG to have it approved as a media type specified in a W3C
    specification.

(2) Revise the document as an I-D, adding a registration form, and have
    it published as an RFC.

				Ned
>From [email-masked]  Mon Sep 20 12:23:33 2004
From: gk at ninebynine.org (Graham Klyne)
Date: Mon Sep 20 13:29:40 2004
Subject: Please review: DRAFT Reg of application/samlassertion+xml 
Message-ID: <[email-masked]>

Jeff,

That wording looks OK to me.

One additional point to consider, but I think it's marginal:  the case when 
the default namespace is a SAML namespace.  (In practice, I think anyone 
who knows enough about XML to use this stuff will understand that case is 
implied, but maybe it's better to be explicit.)

#g
--

At 11:52 06/09/04 -0700, you wrote:
> > 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

------------
Graham Klyne
For email:
http://www.ninebynine.org/#Contact

From: ned.freed at mrochek.com ([email-masked])
Date: Tue Jan  3 16:22:49 2006
Subject: Registration for application/gdiff
In-Reply-To: "Your message dated Mon, 09 Aug 2004 09:22:16 -0700" <[email-masked]>
References: <[email-masked]>
Message-ID: <[email-masked]>

> I'm trying to register a MIME type officially for application/gdiff.
> This type was defined in a W3C NOTE several years ago:

> <http://www.w3.org/TR/NOTE-gdiff-19970901>

> That Note defines the MIME type but apparently the authors never
> registered the MIME type with IANA.  Now we'd like to use gdiff in
> applications where we'd be using the MIME type so having it officially
> registered would be nice.   For example:

> <http://www.ietf.org/internet-drafts/draft-dusseault-http-patch-03.txt>
>   (try -04 if -03 turns up not found)

> I submitted the registration through the IANA web form a couple weeks
> ago but haven't gotten a response other than the automated form
> submission response.

AFAIK it hasn't been passed on to me as media types reviewer. But if it had
been I would have had to reject it; media types in the standards tree have to 
be handled by the IESG. Under the new rules it is OK for such a media type not
to be specified in an RFC, but there has to be a document with a proper
registration form somewhere and the IESG has to approve it.

> Is this smoothly underway or is there anything
> else I need to or can optionally do to help this registration out?

The document you refer to doesn't contain a registration form. As such,
it cannot be registered as is. I see two possibilities:

(1) Revise the document to contain a proper registration form and contact
    the IESG to have it approved as a media type specified in a W3C
    specification.

(2) Revise the document as an I-D, adding a registration form, and have
    it published as an RFC.

				Ned

From: harald at alvestrand.no (Harald Tveit Alvestrand)
Date: Tue Jan  3 16:22:49 2006
Subject: Request For Registration of Media Type
In-Reply-To: <[email-masked]>
References: <[email-masked]>
Message-ID: <[email-masked]>

please check out the registration procedures in RFC 2048 - there's a form 
you need to fill out....

                  Harald

--On fredag, juli 30, 2004 21:17:44 -0400 Marc Clifton 
<[email-masked]> wrote:

> To whom it may concern,
>
> Based on RFC 1590, MyXaml Inc. is requesting the registration of the
> Media Type "myxaml".  This media type is specific for MyXaml markup and
> requires a plug in component for Internet Explorer and FireFox in order
> to present the user interface.  For example, the URL:
>
> http://www.myxaml.com/myxamlhost/helloworld.myxaml
>
> points to a myxaml file on the MyXaml server which contains the markup
> necesary to display "Hello World", hosted as a Microsoft .NET window in
> Internet Explorer using the IE plug-in component.
>
> For those that are interested, the markup can be viewed at:
> http://www.myxaml.com/wiki/ow.asp?HelloWorld.
>
> The purpose of the component is to provide the user with a thin but rich
> client experience beyond the capabilities of HTML within the context of a
> browser.  For further information on MyXaml, please visit:
> http://www.myxaml.com
>
> The Internet Explorer plug-in component has been completed, and the
> FireFox plug-in is under development.  This media type would be of
> specific use to corporations interested in developing rich client
> applications with MyXaml, with the application hosted on their own
> servers.
>
> Please let me know if you have any questions.  For email correspondence,
> please use:
> [email-masked]
>
> Regards,
>
> Marc Clifton
> President
> MyXaml Inc.
>

From: roni.even at polycom.co.il (Even, Roni)
Date: Thu Sep 16 09:17:47 2004
Subject: Comments on draft-freed-media-types-reg-01.txt
Message-ID: <[email-masked]>

Hi,

Reading the document and looking at the IANA database I noticed that the
media types do not include "data" and "control".

The current SDP draft has in section 9 

9.2.1  Media types ("media")
 
   The set of media types is intended to be small and SHOULD NOT be
   extended except under rare circumstances.  The same rules should
   apply for media names as for top-level MIME content types, and where
   possible the same name should be registered for SDP as for MIME.  For
   media other than existing MIME top-level content types, a
   standards-track RFC MUST be produced for a new top-level content type
   to be registered, and the registration MUST provide good
   justification why no existing media name is appropriate (the
   "Standards Action" policy of RFC 2434 [5].
 
   This memo registers the media types "audio", "video", "text",
   "application", "data" and "control".
 
So does it mean that in an RTP payload specification I will register a
payload type as application and use in SDP m line as data?
 
Roni Even

 

*************************************************************

Roni Even

Polycom Israel

Tel: +972-3-9251200

Cell: +972-54-5481099

Fax: +972-3-9211571

*****************************************************************

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://eikenes.alvestrand.no/pipermail/ietf-types/attachments/20040913/aac6999a/attachment-0001.htm
>From [email-masked]  Mon Sep 13 22:33:07 2004
From: csp at csperkins.org (Colin Perkins)
Date: Thu Sep 16 09:17:51 2004
Subject: [MMUSIC] Comments on draft-freed-media-types-reg-01.txt
In-Reply-To: <[email-masked]>
References: <[email-masked]>
Message-ID: <[email-masked]>

[Replies to the MMUSIC list only please, since this is an SDP issue]

On 13 Sep 2004, at 16:27, Even, Roni wrote:
> Reading the document and looking at the IANA database I noticed that 
> the media types do not include ?data? and ?control?.
>
> The current SDP draft has in section 9
>  ?
> 9.2.1? Media types ("media")
> ?
> ?? The set of media types is intended to be small and SHOULD NOT be
> ?? extended except under rare circumstances.? The same rules should
> ?? apply for media names as for top-level MIME content types, and where
> ?? possible the same name should be registered for SDP as for MIME.? 
> For
> ?? media other than existing MIME top-level content types, a
> ?? standards-track RFC MUST be produced for a new top-level content 
> type
> ?? to be registered, and the registration MUST provide good
> ?? justification why no existing media name is appropriate (the
> ?? "Standards Action" policy of RFC 2434 [5].
> ?
> ?? This memo registers the media types "audio", "video", "text",
> ?? "application", "data" and "control".
> ?
> So does it mean that in an RTP payload specification I will register a 
> payload type as application and use in SDP m line as data?

No. The "data" and "control" types are somewhat under-specified in SDP, 
but are intended to be used as alternatives to the other top-level 
media types. We should probably either remove them in favour of 
"application", or define new top-level MIME types if there's a need. 
Using "application" as the MIME type and "m=control" or "m=data" in SDP 
is wrong, though.

The simplest solution is to remove these in the next revision of 
sdp-new, and for them to be registered if there's a need later (unless 
someone is willing to contribute text to fix sdp-new).

Colin
>From [email-masked]  Thu Sep 16 11:47:10 2004
From: harald at alvestrand.no (Harald Tveit Alvestrand)
Date: Thu Sep 16 11:47:18 2004
Subject: Request For Registration of Media Type
In-Reply-To: <[email-masked]>
References: <[email-masked]>
Message-ID: <[email-masked]>

please check out the registration procedures in RFC 2048 - there's a form 
you need to fill out....

                  Harald

--On fredag, juli 30, 2004 21:17:44 -0400 Marc Clifton 
<[email-masked]> wrote:

> To whom it may concern,
>
> Based on RFC 1590, MyXaml Inc. is requesting the registration of the
> Media Type "myxaml".  This media type is specific for MyXaml markup and
> requires a plug in component for Internet Explorer and FireFox in order
> to present the user interface.  For example, the URL:
>
> http://www.myxaml.com/myxamlhost/helloworld.myxaml
>
> points to a myxaml file on the MyXaml server which contains the markup
> necesary to display "Hello World", hosted as a Microsoft .NET window in
> Internet Explorer using the IE plug-in component.
>
> For those that are interested, the markup can be viewed at:
> http://www.myxaml.com/wiki/ow.asp?HelloWorld.
>
> The purpose of the component is to provide the user with a thin but rich
> client experience beyond the capabilities of HTML within the context of a
> browser.  For further information on MyXaml, please visit:
> http://www.myxaml.com
>
> The Internet Explorer plug-in component has been completed, and the
> FireFox plug-in is under development.  This media type would be of
> specific use to corporations interested in developing rich client
> applications with MyXaml, with the application hosted on their own
> servers.
>
> Please let me know if you have any questions.  For email correspondence,
> please use:
> [email-masked]
>
> Regards,
>
> Marc Clifton
> President
> MyXaml Inc.
>

From: roni.even at polycom.co.il (Even, Roni)
Date: Tue Jan  3 16:22:48 2006
Subject: Comments on draft-freed-media-types-reg-01.txt
Message-ID: <[email-masked]>

Hi,

Reading the document and looking at the IANA database I noticed that the
media types do not include "data" and "control".

The current SDP draft has in section 9 

9.2.1  Media types ("media")
 
   The set of media types is intended to be small and SHOULD NOT be
   extended except under rare circumstances.  The same rules should
   apply for media names as for top-level MIME content types, and where
   possible the same name should be registered for SDP as for MIME.  For
   media other than existing MIME top-level content types, a
   standards-track RFC MUST be produced for a new top-level content type
   to be registered, and the registration MUST provide good
   justification why no existing media name is appropriate (the
   "Standards Action" policy of RFC 2434 [5].
 
   This memo registers the media types "audio", "video", "text",
   "application", "data" and "control".
 
So does it mean that in an RTP payload specification I will register a
payload type as application and use in SDP m line as data?
 
Roni Even

 

*************************************************************

Roni Even

Polycom Israel

Tel: +972-3-9251200

Cell: +972-54-5481099

Fax: +972-3-9211571

*****************************************************************

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.alvestrand.no/pipermail/ietf-types/attachments/20040913/aac6999a/attachment.html
>From [email-masked]  Mon Sep 13 22:33:07 2004
From: csp at csperkins.org (Colin Perkins)
Date: Tue Jan  3 16:22:49 2006
Subject: [MMUSIC] Comments on draft-freed-media-types-reg-01.txt
In-Reply-To: <[email-masked]>
References: <[email-masked]>
Message-ID: <[email-masked]>

[Replies to the MMUSIC list only please, since this is an SDP issue]

On 13 Sep 2004, at 16:27, Even, Roni wrote:
> Reading the document and looking at the IANA database I noticed that 
> the media types do not include ?data? and ?control?.
>
> The current SDP draft has in section 9
>  ?
> 9.2.1? Media types ("media")
> ?
> ?? The set of media types is intended to be small and SHOULD NOT be
> ?? extended except under rare circumstances.? The same rules should
> ?? apply for media names as for top-level MIME content types, and where
> ?? possible the same name should be registered for SDP as for MIME.? 
> For
> ?? media other than existing MIME top-level content types, a
> ?? standards-track RFC MUST be produced for a new top-level content 
> type
> ?? to be registered, and the registration MUST provide good
> ?? justification why no existing media name is appropriate (the
> ?? "Standards Action" policy of RFC 2434 [5].
> ?
> ?? This memo registers the media types "audio", "video", "text",
> ?? "application", "data" and "control".
> ?
> So does it mean that in an RTP payload specification I will register a 
> payload type as application and use in SDP m line as data?

No. The "data" and "control" types are somewhat under-specified in SDP, 
but are intended to be used as alternatives to the other top-level 
media types. We should probably either remove them in favour of 
"application", or define new top-level MIME types if there's a need. 
Using "application" as the MIME type and "m=control" or "m=data" in SDP 
is wrong, though.

The simplest solution is to remove these in the next revision of 
sdp-new, and for them to be registered if there's a need later (unless 
someone is willing to contribute text to fix sdp-new).

Colin

From: rey at panasonic.de (Jose Rey)
Date: Tue Jan  3 16:22:48 2006
Subject: Registration of media type text/3gpp-tt
Message-ID: <[email-masked]>

Hello,

please consider the following media type text/3gpp-tt for registration under
the IETF tree. This section is copied from the draft
http://www.ietf.org/internet-drafts/draft-ietf-avt-rtp-3gpp-timed-text-06.tx
t.

   MIME type: text

   MIME subtype: 3gpp-tt

   Required parameters

        rate:
                the RTP timestamp clockrate is equal to the clockrate of
                the media.  If RTP packets are generated out of a 3GP
                file, the clockrate of the text media MUST be copied
                from the 3GP file, i.e. the clockrate is the value of
                "timescale" parameter in the Media Header Box describing
                that text track.  Other tracks (audio/video/text) in the
                3GP file may have their own clockrates as indicated in
                their corresponding Media Header Box.  For live
                encoding, a clockrate of 1000 Hz is RECOMMENDED but
                other values MAY be used.  If a different timestamp rate
                value is used, this MUST be chosen carefully as per
                Section 3 in RFCXXXX.

        sver:
                The parameter "sver" contains a list of supported
                backwards-compatible versions of the timed text format
                specification (3GPP TS 26.245) that the sender accepts
                to receive (and which are the same that it would be
                willing to send).  The first value is the value
                preferred to be received ( or preferred to send).  The
                first value MAY be followed by a comma-separated list of
                versions that SHOULD be used as alternatives.  The order
                is meaningful, being first the most preferred and last
                the least preferred.  Each entry has the format
                Zi(xi*256+yi), where "Zi" is the number of the Release,
                "xi" and "yi" are taken from the 3GPP specification
                version, i.e. vZi.xi.yi.  For example, for 3GPP TS
                26.245 v6.0.0, Zi(xi*256+yi)=6(0), the version value is
                "60".  (Note that "60" is the concatenation of the
                values Zi=6 and (xi*256+yi)=0 and not its product.)

        width:
                This parameter indicates the width in pixels of the text
                track or area of the text being sent.  This is a 16 bit
                integer.

        height:
                This parameter indicates the height in pixels of the
                text track being sent.  This is a 16 bit integer.

        max-w:
                This parameter indicates display capabilities.  This is
                the maximum "width" value that the sender of this
                parameter supports.  This is a 16 bit unsigned integer.

        max-h:
                This parameter indicates display capabilities.  This is
                the maximum "height" value that the sender of this
                parameter supports.  This is a 16 bit unsigned integer.

        tx:
                This parameter indicates the horizontal translation
                offset in pixels of the text track with respect to the
                origin of the video track.  This is a 16 bit integer.

        ty:
                This parameter indicates the vertical translation offset
                in pixels of the text track with respect to the origin
                of the video track.  This is a 16 bit integer.

        layer:
                This parameter indicates the proximity of the text track
                to the viewer.  More negative values mean closer to the
                viewer.  This parameter has no units.  This is a 16 bit
                integer.

   Optional parameters:

        tx3g:
                This parameter MUST be used for conveying sample
                descriptions out-of-band.  It contains a comma-separated
                list of base64-encoded entries.  The entries of this
                list that MAY follow any particular order and the list
                MAY be empty.  The absence of this parameter is
                equivalent to an empty list of sample descriptions.
                Each entry is the result of running base64 encoding over
                the concatenation of the SIDX and the sample description
                for that SIDX, in this order.  The format of a sample
                description entry can be found in 3GPP TS 26.245 Release
                6 and later releases.  All servers and clients MUST
                understand this parameter and MUST be capable of using
                the sample description(s) contained in it.  Please refer
                to RFC 3548 [6] for details on the base64 encoding.

   Encoding considerations:

        RTP payloads complying with this payload format contain binary
        data.

        Note that this type is incompatible with the use of text media
        types in other protocols, e.g. text/html.  This is because in
        order to extract and decode any of the timed text media it is
        necessary understand the (binary) payload headers defined in
        RFCXXXX.

   Restrictions on usage:

        This type is only defined for transfer via RTP.

   Security considerations:

        Please refer to Section 10 of RFCXXXX.

   Interoperability considerations:

        The 3GPP Timed Text media format for which this payload format
        is defined is specified in Release 6 of 3GPP TS 26.245
        "Transparent end-to-end packet switched streaming service (PSS);
        Timed Text Format (Release 6)".  The 3GPP file format (3GP) and
        the SMIL language profile used can be found in Release 5 of 3GPP
        TS 26.234 and in the corresponding specifications for later
        Releases.  Note also that 3GPP may in future Releases specify
        extensions or updates to the media format in a backwards-
        compatible way, e.g. new modifier boxes or extensions to the
        sample descriptions.  The payload format defined in RFCXXXX

   Rey & Matsui                                              [Page 29]
   Internet Draft Payload Format for 3GPP Timed Text September 10, 2004

        allows for such extensions.  For future 3GPP Releases of the
        Timed Text Format, the parameter "sver" is used to identify the
        exact specification used.

   Published specification: RFC XXXX

   Applications which use this media type:

        Multimedia streaming applications.

   Additional information:

        the 3GPP Timed Text media format is specified in 3GPP TS 26.245
        "Transparent end-to-end packet switched streaming service (PSS);
        Timed Text Format (Release 6)".  This document and future
        extensions to the 3GPP Timed Text format are publicly available
        at http://www.3gpp.org.

        Magic number(s): None.

        File extension(s): None.

        Macintosh File Type Code(s): None.

   Person & email address to contact for further information:

        Jose Rey, [email-masked]
        Yoshinori Matsui, [email-masked]
        Audio/Video Transport Working Group.

   Intended usage: COMMON

   Author/Change controller:

        Jose Rey
        Yoshinori Matsui
        IETF AVT WG

Thank,

---------------------------------
Jose Rey
Mobile Multimedia Team
Panasonic R&D Center Germany GmbH
D-63225 Langen, Germany
Tel.:+49-6103-766-134
Fax :+49-6103-766-166
Email: [email-masked]
Web: www.prdcg.panasonic.de
---------------------------------

From: ned.freed at mrochek.com ([email-masked])
Date: Tue Jan  3 16:22:47 2006
Subject: Comments on draft-freed-media-types-reg-01.txt
In-Reply-To: "Your message dated Fri, 10 Sep 2004 12:24:23 +0300" <[email-masked]>
References: <[email-masked]>
Message-ID: <[email-masked]>

> I recently had the please of reading and trying to use the I-D and it is in
> very good shape. My "implementation experience" input is:

> * However robust the x. and x- discussion text becomes, it is essential that
> x. continues to be allowed so that well behaved applications can reject non
> registered types, without some other private agreement to use and x. instance.

OK.

> * I understand that the standards track RFC for Standards Tree registration
> can be a dedicated RFC (start life as a dedicated I-D) OR included in the IANA
> considerations section of a "not dedicated" RFC. Whether or not the latter case
> is allowed, please state this explicitly (it's not so clear). I definitely
> support allowing the MIME registration to be bundled with a wider purpose RFC
> as surely that's what the IANA considerations sections are meant for anyway?

I would have thought it obvious that registrations can either be standalone or
they can be part of a more general specification. However, I have no problem
making this explicit and will do in the next revision.

> * It would be helpful to state whether or not the "bundled RFC" (and a
> dedicated RFC) must use the syntax of the registration template or whether it
> is sufficient to cover all those items (in the whole RFC or specifically in the
> IANA considerations). As someone who has so far not registered any MIME types,
> I couldn't say from draft-freed-media-types-reg-01 whether the template is for
> a specific communication to IANA only (e.g. in an email).

Actually, this is explicit in the document: The section on publications
requirements says "Such specifications MUST contain an appropriate media type
registration template." I'll add a pointer to the actual template.

> * Which bring me to my final request, for a registration-newbie (like me) the
> registration process is something of a black art and a newbie does not know
> what action they must take. Does RFC Editor queue entry OR standards track RFC
> publication OR email from RFC author actually initiate the IANA registration
> process for Standards Tree? (i.e. does the individual or the IETF have to
> translate the I-D/RFC into a request to IANA?)

This is also fairly explicit in the current document. The section on 
registration procedures says "The normal IETF processes should be followed for
all IETF registrations in the standards tree, with the posting of an
internet-draft being a necessary first step." It is considerably beyond the
scope of this document to cover the process of moving a document from Internet
Draft to RFC.

				Ned

From: ned.freed at mrochek.com ([email-masked])
Date: Sat Sep 11 19:41:27 2004
Subject: [AVT] Re: Comments on draft-freed-media-types-reg-01.txt
In-Reply-To: "Your message dated Sat, 11 Sep 2004 11:35:29 +0100" <[email-masked]>
References: <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]>
Message-ID: <[email-masked]>

> On 8 Sep 2004, at 14:59, [email-masked] wrote:
> >> >> 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?
> >> >
> >> >
> >> > IMO if the parameter space is different the types are different. I
> >> don't
> >> > think it is appropriate to have domain-specific parameters, only
> >> > type-specific ones.
> >
> >> Okay, so registering the RTP payload format and a dedicated file
> >> format
> >> for the same codec needs to use two different media types, due to that
> >> that they partially needs to have different parameters?
> >
> > They most certainly do.

> I'm a little concerned about the strength of this rule. I agree when
> the parameter space is separate, but I can certainly envisage cases
> when the parameter space and data format for two different domains have
> a very high degree of overlap, and where it makes sense for them to use
> the same media type.

Data formats are either the same or they aren't. If they are the same only one
media type is required. If they aren't then different types are required
regardless of the disjointness of domains of applicability, the use of the same
underlying set of codecs, and so on.

Leakage between domains is just too common to relax this rule.

OTOH, parameters can be optional. I don't much care for it, but I suppose
there's nothing to prevent you from having a parameter that's optional in some
contexts and mandatory in others. (This could simply be spelled out in the
parameter specification language.) However, I would not want to  see language
prohibiting a particular parameter in some context; IMO this goes too far.
Having a single parameter with different domain-specific meanings is also
unacceptable.

> For example, there are several audio codecs where the RTP payload
> format can be summarised as "put frames into RTP packets in order" and
> the file format is "put frames into the file in order, following an
> initial magic number". In both cases there are common parameters:
> sampling rate, frame duration, and number of channels. However the RTP
> payload format needs an additional parameter: maximum frame duration
> (RTP packets have a size limit due to the path MTU, but the file format
> supports any frame size). I'm not sure it makes sense to require these
> to use different media types, since they're clearly the same format
> applied to different domains, yet the above rule would seem to require
> it.

And interop problems are likely if files are produced without the magic number
and software that checks the magic numbers is used. Similarly, treating the
magic number as audio data could, depending on the codec involved have some
interesting effects.

Now, nothing says you cannot use a naming convention of some sort to link the
two types in some way. But IMO they really need to be two different types.

				Ned
>From [email-masked]  Sun Sep 12 21:26:30 2004
From: ned.freed at mrochek.com ([email-masked])
Date: Sun Sep 12 21:38:54 2004
Subject: Comments on draft-freed-media-types-reg-01.txt
In-Reply-To: "Your message dated Fri, 10 Sep 2004 12:24:23 +0300"
	<[email-masked]>
References: <[email-masked]>
Message-ID: <[email-masked]>

> I recently had the please of reading and trying to use the I-D and it is in
> very good shape. My "implementation experience" input is:

> * However robust the x. and x- discussion text becomes, it is essential that
> x. continues to be allowed so that well behaved applications can reject non
> registered types, without some other private agreement to use and x. instance.

OK.

> * I understand that the standards track RFC for Standards Tree registration
> can be a dedicated RFC (start life as a dedicated I-D) OR included in the IANA
> considerations section of a "not dedicated" RFC. Whether or not the latter case
> is allowed, please state this explicitly (it's not so clear). I definitely
> support allowing the MIME registration to be bundled with a wider purpose RFC
> as surely that's what the IANA considerations sections are meant for anyway?

I would have thought it obvious that registrations can either be standalone or
they can be part of a more general specification. However, I have no problem
making this explicit and will do in the next revision.

> * It would be helpful to state whether or not the "bundled RFC" (and a
> dedicated RFC) must use the syntax of the registration template or whether it
> is sufficient to cover all those items (in the whole RFC or specifically in the
> IANA considerations). As someone who has so far not registered any MIME types,
> I couldn't say from draft-freed-media-types-reg-01 whether the template is for
> a specific communication to IANA only (e.g. in an email).

Actually, this is explicit in the document: The section on publications
requirements says "Such specifications MUST contain an appropriate media type
registration template." I'll add a pointer to the actual template.

> * Which bring me to my final request, for a registration-newbie (like me) the
> registration process is something of a black art and a newbie does not know
> what action they must take. Does RFC Editor queue entry OR standards track RFC
> publication OR email from RFC author actually initiate the IANA registration
> process for Standards Tree? (i.e. does the individual or the IETF have to
> translate the I-D/RFC into a request to IANA?)

This is also fairly explicit in the current document. The section on 
registration procedures says "The normal IETF processes should be followed for
all IETF registrations in the standards tree, with the posting of an
internet-draft being a necessary first step." It is considerably beyond the
scope of this document to cover the process of moving a document from Internet
Draft to RFC.

				Ned
>From [email-masked]  Tue Sep  7 13:56:26 2004
From: rey at panasonic.de (Jose Rey)
Date: Thu Sep 16 09:17:17 2004
Subject: Media Types in 3GPP Timed text draft (was: RE: [AVT] RTP
	andMediaTypes)
In-Reply-To: <[email-masked]>
Message-ID: <[email-masked]>

Colin,

Thanks for your answers. See inline.

> -----Original Message-----
> From: Colin Perkins [mailto:[email-masked]]
> 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)
>
>
> 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?

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.

> > 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?

Cheers,

Jose

> Colin
>
>

From: ned.freed at mrochek.com ([email-masked])
Date: Tue Jan  3 16:22:47 2006
Subject: [AVT] Re: Comments on draft-freed-media-types-reg-01.txt
In-Reply-To: "Your message dated Sat, 11 Sep 2004 11:35:29 +0100" <[email-masked]>
References: <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]>
Message-ID: <[email-masked]>

> On 8 Sep 2004, at 14:59, [email-masked] wrote:
> >> >> 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?
> >> >
> >> >
> >> > IMO if the parameter space is different the types are different. I
> >> don't
> >> > think it is appropriate to have domain-specific parameters, only
> >> > type-specific ones.
> >
> >> Okay, so registering the RTP payload format and a dedicated file
> >> format
> >> for the same codec needs to use two different media types, due to that
> >> that they partially needs to have different parameters?
> >
> > They most certainly do.

> I'm a little concerned about the strength of this rule. I agree when
> the parameter space is separate, but I can certainly envisage cases
> when the parameter space and data format for two different domains have
> a very high degree of overlap, and where it makes sense for them to use
> the same media type.

Data formats are either the same or they aren't. If they are the same only one
media type is required. If they aren't then different types are required
regardless of the disjointness of domains of applicability, the use of the same
underlying set of codecs, and so on.

Leakage between domains is just too common to relax this rule.

OTOH, parameters can be optional. I don't much care for it, but I suppose
there's nothing to prevent you from having a parameter that's optional in some
contexts and mandatory in others. (This could simply be spelled out in the
parameter specification language.) However, I would not want to  see language
prohibiting a particular parameter in some context; IMO this goes too far.
Having a single parameter with different domain-specific meanings is also
unacceptable.

> For example, there are several audio codecs where the RTP payload
> format can be summarised as "put frames into RTP packets in order" and
> the file format is "put frames into the file in order, following an
> initial magic number". In both cases there are common parameters:
> sampling rate, frame duration, and number of channels. However the RTP
> payload format needs an additional parameter: maximum frame duration
> (RTP packets have a size limit due to the path MTU, but the file format
> supports any frame size). I'm not sure it makes sense to require these
> to use different media types, since they're clearly the same format
> applied to different domains, yet the above rule would seem to require
> it.

And interop problems are likely if files are produced without the magic number
and software that checks the magic numbers is used. Similarly, treating the
magic number as audio data could, depending on the codec involved have some
interesting effects.

Now, nothing says you cannot use a naming convention of some sort to link the
two types in some way. But IMO they really need to be two different types.

				Ned

From: csp at csperkins.org (Colin Perkins)
Date: Sat Sep 11 12:35:42 2004
Subject: [AVT] Re: Comments on draft-freed-media-types-reg-01.txt
In-Reply-To: <[email-masked]>
References: <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]>
Message-ID: <[email-masked]>

On 8 Sep 2004, at 14:59, [email-masked] wrote:
>> >> 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?
>> >
>> >
>> > IMO if the parameter space is different the types are different. I 
>> don't
>> > think it is appropriate to have domain-specific parameters, only
>> > type-specific ones.
>
>> Okay, so registering the RTP payload format and a dedicated file 
>> format
>> for the same codec needs to use two different media types, due to that
>> that they partially needs to have different parameters?
>
> They most certainly do.

I'm a little concerned about the strength of this rule. I agree when 
the parameter space is separate, but I can certainly envisage cases 
when the parameter space and data format for two different domains have 
a very high degree of overlap, and where it makes sense for them to use 
the same media type.

For example, there are several audio codecs where the RTP payload 
format can be summarised as "put frames into RTP packets in order" and 
the file format is "put frames into the file in order, following an 
initial magic number". In both cases there are common parameters: 
sampling rate, frame duration, and number of channels. However the RTP 
payload format needs an additional parameter: maximum frame duration 
(RTP packets have a size limit due to the path MTU, but the file format 
supports any frame size). I'm not sure it makes sense to require these 
to use different media types, since they're clearly the same format 
applied to different domains, yet the above rule would seem to require 
it.

Colin

From: csp at csperkins.org (Colin Perkins)
Date: Tue Jan  3 16:22:47 2006
Subject: [AVT] Re: Comments on draft-freed-media-types-reg-01.txt
In-Reply-To: <[email-masked]>
References: <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]>
Message-ID: <[email-masked]>

On 8 Sep 2004, at 14:59, [email-masked] wrote:
>> >> 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?
>> >
>> >
>> > IMO if the parameter space is different the types are different. I 
>> don't
>> > think it is appropriate to have domain-specific parameters, only
>> > type-specific ones.
>
>> Okay, so registering the RTP payload format and a dedicated file 
>> format
>> for the same codec needs to use two different media types, due to that
>> that they partially needs to have different parameters?
>
> They most certainly do.

I'm a little concerned about the strength of this rule. I agree when 
the parameter space is separate, but I can certainly envisage cases 
when the parameter space and data format for two different domains have 
a very high degree of overlap, and where it makes sense for them to use 
the same media type.

For example, there are several audio codecs where the RTP payload 
format can be summarised as "put frames into RTP packets in order" and 
the file format is "put frames into the file in order, following an 
initial magic number". In both cases there are common parameters: 
sampling rate, frame duration, and number of channels. However the RTP 
payload format needs an additional parameter: maximum frame duration 
(RTP packets have a size limit due to the path MTU, but the file format 
supports any frame size). I'm not sure it makes sense to require these 
to use different media types, since they're clearly the same format 
applied to different domains, yet the above rule would seem to require 
it.

Colin

From: csp at csperkins.org (Colin Perkins)
Date: Sat Sep 11 12:06:02 2004
Subject: [AVT] Re: Comments on draft-freed-media-types-reg-01.txt
In-Reply-To: <[email-masked]>
References: <[email-masked]>
Message-ID: <[email-masked]>

On 10 Sep 2004, at 10:24, [email-masked] wrote:
> I recently had the please of reading and trying to use the I-D and it 
> is in very good shape. My "implementation experience" input is:
...
> * I understand that the standards track RFC for Standards Tree 
> registration can be a dedicated RFC (start life as a dedicated I-D) OR 
> included in the IANA considerations section of a "not dedicated" RFC. 
> Whether or not the latter case is allowed, please state this 
> explicitly (it's not so clear). I definitely support allowing the MIME 
> registration to be bundled with a wider purpose RFC as surely that's 
> what the IANA considerations sections are meant for anyway?

I hope so; this is how many RTP payload formats register their MIME 
type.

> * It would be helpful to state whether or not the "bundled RFC" (and a 
> dedicated RFC) must use the syntax of the registration template or 
> whether it is sufficient to cover all those items (in the whole RFC or 
> specifically in the IANA considerations). As someone who has so far 
> not registered any MIME types, I couldn't say from 
> draft-freed-media-types-reg-01 whether the template is for a specific 
> communication to IANA only (e.g. in an email).

I believe the template MUST be used in all cases.

> * Which bring me to my final request, for a registration-newbie (like 
> me) the registration process is something of a black art and a newbie 
> does not know what action they must take. Does RFC Editor queue entry 
> OR standards track RFC publication OR email from RFC author actually 
> initiate the IANA registration process for Standards Tree? (i.e. does 
> the individual or the IETF have to translate the I-D/RFC into a 
> request to IANA?)

The RFC Editor and IANA co-ordinate to ensure that registrations take 
place during the RFC publication process.  The author doesn't need to 
contact the IANA directly.

Colin

From: csp at csperkins.org (Colin Perkins)
Date: Tue Jan  3 16:22:47 2006
Subject: [AVT] Re: Comments on draft-freed-media-types-reg-01.txt
In-Reply-To: <[email-masked]>
References: <[email-masked]>
Message-ID: <[email-masked]>

On 10 Sep 2004, at 10:24, [email-masked] wrote:
> I recently had the please of reading and trying to use the I-D and it 
> is in very good shape. My "implementation experience" input is:
...
> * I understand that the standards track RFC for Standards Tree 
> registration can be a dedicated RFC (start life as a dedicated I-D) OR 
> included in the IANA considerations section of a "not dedicated" RFC. 
> Whether or not the latter case is allowed, please state this 
> explicitly (it's not so clear). I definitely support allowing the MIME 
> registration to be bundled with a wider purpose RFC as surely that's 
> what the IANA considerations sections are meant for anyway?

I hope so; this is how many RTP payload formats register their MIME 
type.

> * It would be helpful to state whether or not the "bundled RFC" (and a 
> dedicated RFC) must use the syntax of the registration template or 
> whether it is sufficient to cover all those items (in the whole RFC or 
> specifically in the IANA considerations). As someone who has so far 
> not registered any MIME types, I couldn't say from 
> draft-freed-media-types-reg-01 whether the template is for a specific 
> communication to IANA only (e.g. in an email).

I believe the template MUST be used in all cases.

> * Which bring me to my final request, for a registration-newbie (like 
> me) the registration process is something of a black art and a newbie 
> does not know what action they must take. Does RFC Editor queue entry 
> OR standards track RFC publication OR email from RFC author actually 
> initiate the IANA registration process for Standards Tree? (i.e. does 
> the individual or the IETF have to translate the I-D/RFC into a 
> request to IANA?)

The RFC Editor and IANA co-ordinate to ensure that registrations take 
place during the RFC publication process.  The author doesn't need to 
contact the IANA directly.

Colin

From: chris at w3.org (Chris Lilley)
Date: Sat Sep 11 08:57:19 2004
Subject: publication of FITS MIME Internet-Draft
In-Reply-To: <[email-masked]>
References: <[email-masked]> <[email-masked]>
Message-ID: <[email-masked]>

On Friday, September 10, 2004, 5:12:06 PM, Steve wrote:

SA> In accordance with the recommendation of the International
SA> Astronomical Union FITS Working Group (IAUFWG)

This is an interesting one. Clearly the International Astronomical Union
is a standards organization (for astronomical formats, which FITS is)
and thus, registration in the standards tree (previously the IETF tree)
is appropriate.

-- 
 Chris Lilley                    mailto:[email-masked]
 Chair, W3C SVG Working Group
 Member, W3C Technical Architecture Group

From: chris at w3.org (Chris Lilley)
Date: Tue Jan  3 16:22:47 2006
Subject: publication of FITS MIME Internet-Draft
In-Reply-To: <[email-masked]>
References: <[email-masked]> <[email-masked]>
Message-ID: <[email-masked]>

On Friday, September 10, 2004, 5:12:06 PM, Steve wrote:

SA> In accordance with the recommendation of the International
SA> Astronomical Union FITS Working Group (IAUFWG)

This is an interesting one. Clearly the International Astronomical Union
is a standards organization (for astronomical formats, which FITS is)
and thus, registration in the standards tree (previously the IETF tree)
is appropriate.

-- 
 Chris Lilley                    mailto:[email-masked]
 Chair, W3C SVG Working Group
 Member, W3C Technical Architecture Group

From: lisa at osafoundation.org (Lisa Dusseault)
Date: Tue Jan  3 16:22:47 2006
Subject: MIME registration for application/gdiff
Message-ID: <[email-masked]>

I'm trying to register a MIME type officially for application/gdiff.  
This type was defined in a W3C NOTE several years ago:

<http://www.w3.org/TR/NOTE-gdiff-19970901>

That Note defines the MIME type but apparently the authors never 
registered the MIME type with IANA.  Now we'd like to use gdiff in 
applications where we'd be using the MIME type so having it officially 
registered would be nice.   For example in:

<http://www.ietf.org/internet-drafts/draft-dusseault-http-patch-05.txt>

I submitted the registration through the IANA web form six weeks ago 
but haven't gotten a response other than the automated form submission 
response.  Is this smoothly underway or is there anything else I need 
to or can optionally do to help this registration out?  Is there 
anywhere to see the status of requests?

Thanks,
Lisa Dusseault

PS I had to subscribe to this list to get my posting accepted -- I 
first sent this message in August but it disappeared into a black hole.

Lisa

From: sla at ucolick.org (Steve Allen)
Date: Tue Jan  3 16:22:47 2006
Subject: publication of FITS MIME Internet-Draft
In-Reply-To: <[email-masked]>
References: <[email-masked]>
Message-ID: <[email-masked]>

In accordance with the recommendation of the International
Astronomical Union FITS Working Group (IAUFWG) I have requested that
the Internet-Draft with the name
<draft-allen-fitsmime-00.txt>
be considered for publication as an Informational RFC.

This Internet-Draft specifies two new top-level MIME media types,
image/fits and application/fits
The shepherd, Scott Hollenbeck, points out the requirement
that IETF-Types be involved.

Please review the content of <draft-allen-fitsmime-00.txt>
and the two media type applications within it.

Thank you.

Background information:

The process by which this document gained IAUFWG approval is
visible at
http://www.ucolick.org/~sla/fits/mime/

The archives of the IAUFWG are visible via
http://listmgr.cv.nrao.edu/pipermail/iaufwg/

The charter given to me by the IAUFWG is visible in the archives at
http://listmgr.cv.nrao.edu/pipermail/iaufwg/2004-July/000200.html

The vote results indicating unanimous approval for submission is at
http://listmgr.cv.nrao.edu/pipermail/iaufwg/2004-August/000212.html

--
Steve Allen          UCO/Lick Observatory       Santa Cruz, CA 95064
[email-masked]      Voice: +1 831 459 3046     http://www.ucolick.org/~sla
PGP: 1024/E46978C5   F6 78 D1 10 62 94 8F 2E    49 89 0E FE 26 B4 14 93

From: Rod.Walsh at nokia.com ([email-masked])
Date: Thu Sep 16 09:17:42 2004
Subject: Comments on draft-freed-media-types-reg-01.txt
Message-ID: <[email-masked]>

Hello all

I recently had the please of reading and trying to use the I-D and it is in very good shape. My "implementation experience" input is:

* However robust the x. and x- discussion text becomes, it is essential that x. continues to be allowed so that well behaved applications can reject non registered types, without some other private agreement to use and x. instance. 

* I understand that the standards track RFC for Standards Tree registration can be a dedicated RFC (start life as a dedicated I-D) OR included in the IANA considerations section of a "not dedicated" RFC. Whether or not the latter case is allowed, please state this explicitly (it's not so clear). I definitely support allowing the MIME registration to be bundled with a wider purpose RFC as surely that's what the IANA considerations sections are meant for anyway?

* It would be helpful to state whether or not the "bundled RFC" (and a dedicated RFC) must use the syntax of the registration template or whether it is sufficient to cover all those items (in the whole RFC or specifically in the IANA considerations). As someone who has so far not registered any MIME types, I couldn't say from draft-freed-media-types-reg-01 whether the template is for a specific communication to IANA only (e.g. in an email).

* Which bring me to my final request, for a registration-newbie (like me) the registration process is something of a black art and a newbie does not know what action they must take. Does RFC Editor queue entry OR standards track RFC publication OR email from RFC author actually initiate the IANA registration process for Standards Tree? (i.e. does the individual or the IETF have to translate the I-D/RFC into a request to IANA?)

(Apologies in advance for any overly stupid questions).

Cheers, Rod.
>From [email-masked]  Mon Sep 13 10:29:51 2004
From: rey at panasonic.de (Jose Rey)
Date: Thu Sep 16 09:17:45 2004
Subject: Registration of media type text/3gpp-tt
Message-ID: <[email-masked]>

Hello,

please consider the following media type text/3gpp-tt for registration under
the IETF tree. This section is copied from the draft
http://www.ietf.org/internet-drafts/draft-ietf-avt-rtp-3gpp-timed-text-06.tx
t.

   MIME type: text

   MIME subtype: 3gpp-tt

   Required parameters

        rate:
                the RTP timestamp clockrate is equal to the clockrate of
                the media.  If RTP packets are generated out of a 3GP
                file, the clockrate of the text media MUST be copied
                from the 3GP file, i.e. the clockrate is the value of
                "timescale" parameter in the Media Header Box describing
                that text track.  Other tracks (audio/video/text) in the
                3GP file may have their own clockrates as indicated in
                their corresponding Media Header Box.  For live
                encoding, a clockrate of 1000 Hz is RECOMMENDED but
                other values MAY be used.  If a different timestamp rate
                value is used, this MUST be chosen carefully as per
                Section 3 in RFCXXXX.

        sver:
                The parameter "sver" contains a list of supported
                backwards-compatible versions of the timed text format
                specification (3GPP TS 26.245) that the sender accepts
                to receive (and which are the same that it would be
                willing to send).  The first value is the value
                preferred to be received ( or preferred to send).  The
                first value MAY be followed by a comma-separated list of
                versions that SHOULD be used as alternatives.  The order
                is meaningful, being first the most preferred and last
                the least preferred.  Each entry has the format
                Zi(xi*256+yi), where "Zi" is the number of the Release,
                "xi" and "yi" are taken from the 3GPP specification
                version, i.e. vZi.xi.yi.  For example, for 3GPP TS
                26.245 v6.0.0, Zi(xi*256+yi)=6(0), the version value is
                "60".  (Note that "60" is the concatenation of the
                values Zi=6 and (xi*256+yi)=0 and not its product.)

        width:
                This parameter indicates the width in pixels of the text
                track or area of the text being sent.  This is a 16 bit
                integer.

        height:
                This parameter indicates the height in pixels of the
                text track being sent.  This is a 16 bit integer.

        max-w:
                This parameter indicates display capabilities.  This is
                the maximum "width" value that the sender of this
                parameter supports.  This is a 16 bit unsigned integer.

        max-h:
                This parameter indicates display capabilities.  This is
                the maximum "height" value that the sender of this
                parameter supports.  This is a 16 bit unsigned integer.

        tx:
                This parameter indicates the horizontal translation
                offset in pixels of the text track with respect to the
                origin of the video track.  This is a 16 bit integer.

        ty:
                This parameter indicates the vertical translation offset
                in pixels of the text track with respect to the origin
                of the video track.  This is a 16 bit integer.

        layer:
                This parameter indicates the proximity of the text track
                to the viewer.  More negative values mean closer to the
                viewer.  This parameter has no units.  This is a 16 bit
                integer.

   Optional parameters:

        tx3g:
                This parameter MUST be used for conveying sample
                descriptions out-of-band.  It contains a comma-separated
                list of base64-encoded entries.  The entries of this
                list that MAY follow any particular order and the list
                MAY be empty.  The absence of this parameter is
                equivalent to an empty list of sample descriptions.
                Each entry is the result of running base64 encoding over
                the concatenation of the SIDX and the sample description
                for that SIDX, in this order.  The format of a sample
                description entry can be found in 3GPP TS 26.245 Release
                6 and later releases.  All servers and clients MUST
                understand this parameter and MUST be capable of using
                the sample description(s) contained in it.  Please refer
                to RFC 3548 [6] for details on the base64 encoding.

   Encoding considerations:

        RTP payloads complying with this payload format contain binary
        data.

        Note that this type is incompatible with the use of text media
        types in other protocols, e.g. text/html.  This is because in
        order to extract and decode any of the timed text media it is
        necessary understand the (binary) payload headers defined in
        RFCXXXX.

   Restrictions on usage:

        This type is only defined for transfer via RTP.

   Security considerations:

        Please refer to Section 10 of RFCXXXX.

   Interoperability considerations:

        The 3GPP Timed Text media format for which this payload format
        is defined is specified in Release 6 of 3GPP TS 26.245
        "Transparent end-to-end packet switched streaming service (PSS);
        Timed Text Format (Release 6)".  The 3GPP file format (3GP) and
        the SMIL language profile used can be found in Release 5 of 3GPP
        TS 26.234 and in the corresponding specifications for later
        Releases.  Note also that 3GPP may in future Releases specify
        extensions or updates to the media format in a backwards-
        compatible way, e.g. new modifier boxes or extensions to the
        sample descriptions.  The payload format defined in RFCXXXX

   Rey & Matsui                                              [Page 29]
   Internet Draft Payload Format for 3GPP Timed Text September 10, 2004

        allows for such extensions.  For future 3GPP Releases of the
        Timed Text Format, the parameter "sver" is used to identify the
        exact specification used.

   Published specification: RFC XXXX

   Applications which use this media type:

        Multimedia streaming applications.

   Additional information:

        the 3GPP Timed Text media format is specified in 3GPP TS 26.245
        "Transparent end-to-end packet switched streaming service (PSS);
        Timed Text Format (Release 6)".  This document and future
        extensions to the 3GPP Timed Text format are publicly available
        at http://www.3gpp.org.

        Magic number(s): None.

        File extension(s): None.

        Macintosh File Type Code(s): None.

   Person & email address to contact for further information:

        Jose Rey, [email-masked]
        Yoshinori Matsui, [email-masked]
        Audio/Video Transport Working Group.

   Intended usage: COMMON

   Author/Change controller:

        Jose Rey
        Yoshinori Matsui
        IETF AVT WG

Thank,

---------------------------------
Jose Rey
Mobile Multimedia Team
Panasonic R&D Center Germany GmbH
D-63225 Langen, Germany
Tel.:+49-6103-766-134
Fax :+49-6103-766-166
Email: [email-masked]
Web: www.prdcg.panasonic.de
---------------------------------

From: Rod.Walsh at nokia.com ([email-masked])
Date: Tue Jan  3 16:22:48 2006
Subject: Comments on draft-freed-media-types-reg-01.txt
Message-ID: <[email-masked]>

Hello all

I recently had the please of reading and trying to use the I-D and it is in very good shape. My "implementation experience" input is:

* However robust the x. and x- discussion text becomes, it is essential that x. continues to be allowed so that well behaved applications can reject non registered types, without some other private agreement to use and x. instance. 

* I understand that the standards track RFC for Standards Tree registration can be a dedicated RFC (start life as a dedicated I-D) OR included in the IANA considerations section of a "not dedicated" RFC. Whether or not the latter case is allowed, please state this explicitly (it's not so clear). I definitely support allowing the MIME registration to be bundled with a wider purpose RFC as surely that's what the IANA considerations sections are meant for anyway?

* It would be helpful to state whether or not the "bundled RFC" (and a dedicated RFC) must use the syntax of the registration template or whether it is sufficient to cover all those items (in the whole RFC or specifically in the IANA considerations). As someone who has so far not registered any MIME types, I couldn't say from draft-freed-media-types-reg-01 whether the template is for a specific communication to IANA only (e.g. in an email).

* Which bring me to my final request, for a registration-newbie (like me) the registration process is something of a black art and a newbie does not know what action they must take. Does RFC Editor queue entry OR standards track RFC publication OR email from RFC author actually initiate the IANA registration process for Standards Tree? (i.e. does the individual or the IETF have to translate the I-D/RFC into a request to IANA?)

(Apologies in advance for any overly stupid questions).

Cheers, Rod.

From: ned.freed at mrochek.com ([email-masked])
Date: Tue Jan  3 16:22:47 2006
Subject: [AVT] Re: Comments on draft-freed-media-types-reg-01.txt
In-Reply-To: "Your message dated Thu, 09 Sep 2004 11:54:06 +0200" <[email-masked]>
References: <[email-masked]> <[email-masked]>
Message-ID: <[email-masked]>

> > > 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

From: rey at panasonic.de (Jose Rey)
Date: Thu Sep 16 09:17:38 2004
Subject: [AVT] Re: Comments on draft-freed-media-types-reg-01.txt
In-Reply-To: <[email-masked]>
Message-ID: <[email-masked]>

Hi,

I am the editor of the 3GPP timed text draft.  I have a question regarding
MW2.  THanks in advance
--snip--
> > 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?
>
> 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"?

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 [].  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.

Restrictions on usage:

This type is only defined for transfer via RTP."

Cheers,

Jose

--snip--

From: rey at panasonic.de (Jose Rey)
Date: Tue Jan  3 16:22:48 2006
Subject: [AVT] Re: Comments on draft-freed-media-types-reg-01.txt
In-Reply-To: <[email-masked]>
Message-ID: <[email-masked]>

Hi,

I am the editor of the 3GPP timed text draft.  I have a question regarding
MW2.  THanks in advance
--snip--
> > 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?
>
> 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"?

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 [].  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.

Restrictions on usage:

This type is only defined for transfer via RTP."

Cheers,

Jose

--snip--

From: klensin at jck.com (John C Klensin)
Date: Tue Jan  3 16:22:48 2006
Subject: [AVT] Re: Comments on draft-freed-media-types-reg-01.txt
In-Reply-To: <[email-masked]>
References: <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]>
Message-ID: <[email-masked]>

Hi.

For whatever the additional calibration is worth, my reactions
are in complete agreement with Ned's on all issues.  In
particular, the notion of registration by application, rather
than file (body part) content has been absolutely miserable and
a plague on interoperability.  Part of the reason is that, in
many situations, we can have application X that can handle file
formats A, B, and C, and application Y that can handle file
formats D, E, and B.  If the content types reflect the formats,
there is no problem -- both simply use B.  If they reflect the
applications, then there is an serious interoperability problem.

   john

--On Wednesday, 08 September, 2004 06:59 -0700
[email-masked] wrote:

>> Hi Ned,
> 
>> See below.
> 
>> [email-masked] wrote:
> 
>> >> 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
>> > But this is what the section already says:
>> > 
>> >   However, with the simplified registration procedures
>> >   described above for vendor and personal trees, it should
>> >   rarely, if ever, be necessary to use unregistered
>> >   experimental types, and as such use of both "x-" and "x."
>> >   forms is discouraged.
>> > 
>> > I think this is pretty clear already.
> 
>> I think one could use a stronger language in discouraging
>> people.
> 
> Then by all means suggest some.
> 
>> > 
>> >> 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?
>> > 
>> > 
>> > IMO if the parameter space is different the types are
>> > different. I don't think it is appropriate to have
>> > domain-specific parameters, only type-specific ones.
> 
>> Okay, so registering the RTP payload format and a dedicated
>> file format for the same codec needs to use two different
>> media types, due to that that they partially needs to have
>> different parameters?
> 
> They most certainly do.
> 
>> I have an example in the draft-ietf-avt-rtp-vmr-wb-03.txt
>> where we have RTP payload format that carries the different
>> audio frames. There is also a specification of a file format,
>> that also contains the same frames. The wrapping structure is
>> somewhat different due to that they are file format and RTP
>> payload format.
> 
> In other words, the bits are different as well. That means two
> media types are
> required regardless of whether or not the parameters are the
> same.
> 
> While it is nice to be able to cater to some extent to
> protocol-specific needs
> in our procedures, we cannot afford to compromise the core
> functionality media
> types provide. One of those core functions is that each type
> labels a single,
> canonical object format. Types don't label codecs, and it has
> long been the
> case that a single codec can give rise to multiple media
> types. (It is also
> possible for multiple codecs to be combined in a single type.)
> 
>> I understand. I might have not meant application really
>> correctly. What I mean is that if we update the RTP
>> registration rules for media types, we can define a string
>> that should be written into Restriction on usage if only RTP
>> is supported. That way we are not really being explicit about
>> application, but can ensure that we have a good definition on
>> what restriction we applies.
> 
> That may be the right thing to do for RTP, but we need to
> think more
> generally here. Of course nothing prevents RTP from specifying
> its
> own additional registrations requirements for media types it
> uses.
> The MIME specification is certainly going to do something
> along these
> lines once it is revised.
> 
>> >> 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?
>> > 
>> > 
>> > I guess I don't see the problem. The commonality of use of
>> > something has almost nothing to do with how usage is
>> > restricted. I could have a media type that's commonly used
>> > but only RTP. Or I could have an obsolete type that can be
>> > used anywhere. Any combination is possible.
>> > 
>> > Perhaps moving the restrictions on usage field below the
>> > intended usage field in the registration form and adding
>> > some text as to what goes in the restrictions on usage will
>> > help.
>> > 
> 
>> What could happen is that we have a media type that is for a
>> codec and with two defined usages, file format and RTP
>> payload format. The RTP payload format is after
>> standardization used, but later found unsuitable for usage.
>> Therefore a new RTP payload format is defined. However as
>> there is a deployed basis one can't simple use the same media
>> type for the new RTP payload format and defines a new one.
>> The previous name is still valid for the file format part,
>> while OBSOLETE for the RTP payload part.
> 
> In other words, having a media type that labels more than one
> sort of object can give rise to situations where the intended
> usage varies
> depending on where the type is employed. This is hardly
> surprising given
> that the initial premise violates the entire media type
> philosophy.
> 
> This is still more reason why having a single label for two
> very differnet
> things is TOTALLY unacceptable.
> 
> 				Ned

From: ned.freed at mrochek.com ([email-masked])
Date: Tue Jan  3 16:22:47 2006
Subject: [AVT] Re: Comments on draft-freed-media-types-reg-01.txt
In-Reply-To: "Your message dated Wed, 08 Sep 2004 15:06:07 +0200" <[email-masked]>
References: <[email-masked]> <[email-masked]> <[email-masked]>
Message-ID: <[email-masked]>

> Hi Ned,

> See below.

> [email-masked] wrote:

> >> 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
> > But this is what the section already says:
> >
> >   However, with the simplified registration procedures described above
> >   for vendor and personal trees, it should rarely, if ever, be
> >   necessary to use unregistered experimental types, and as such use of
> >   both "x-" and "x." forms is discouraged.
> >
> > I think this is pretty clear already.

> I think one could use a stronger language in discouraging people.

Then by all means suggest some.

> >
> >> 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?
> >
> >
> > IMO if the parameter space is different the types are different. I don't
> > think it is appropriate to have domain-specific parameters, only
> > type-specific ones.

> Okay, so registering the RTP payload format and a dedicated file format
> for the same codec needs to use two different media types, due to that
> that they partially needs to have different parameters?

They most certainly do.

> I have an example in the draft-ietf-avt-rtp-vmr-wb-03.txt where we have
> RTP payload format that carries the different audio frames. There is
> also a specification of a file format, that also contains the same
> frames. The wrapping structure is somewhat different due to that they
> are file format and RTP payload format.

In other words, the bits are different as well. That means two media types are
required regardless of whether or not the parameters are the same.

While it is nice to be able to cater to some extent to protocol-specific needs
in our procedures, we cannot afford to compromise the core functionality media
types provide. One of those core functions is that each type labels a single,
canonical object format. Types don't label codecs, and it has long been the
case that a single codec can give rise to multiple media types. (It is also
possible for multiple codecs to be combined in a single type.)

> I understand. I might have not meant application really correctly. What
> I mean is that if we update the RTP registration rules for media types,
> we can define a string that should be written into Restriction on usage
> if only RTP is supported. That way we are not really being explicit
> about application, but can ensure that we have a good definition on what
> restriction we applies.

That may be the right thing to do for RTP, but we need to think more
generally here. Of course nothing prevents RTP from specifying its
own additional registrations requirements for media types it uses.
The MIME specification is certainly going to do something along these
lines once it is revised.

> >> 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?
> >
> >
> > I guess I don't see the problem. The commonality of use of something
> > has almost nothing to do with how usage is restricted. I could have
> > a media type that's commonly used but only RTP. Or I could have
> > an obsolete type that can be used anywhere. Any combination is possible.
> >
> > Perhaps moving the restrictions on usage field below the intended usage
> > field in the registration form and adding some text as to what goes
> > in the restrictions on usage will help.
> >

> What could happen is that we have a media type that is for a codec and
> with two defined usages, file format and RTP payload format. The RTP
> payload format is after standardization used, but later found unsuitable
> for usage. Therefore a new RTP payload format is defined. However as
> there is a deployed basis one can't simple use the same media type for
> the new RTP payload format and defines a new one. The previous name is
> still valid for the file format part, while OBSOLETE for the RTP payload
> part.

In other words, having a media type that labels more than one sort of 
object can give rise to situations where the intended usage varies
depending on where the type is employed. This is hardly surprising given
that the initial premise violates the entire media type philosophy.

This is still more reason why having a single label for two very differnet
things is TOTALLY unacceptable.

				Ned

From: magnus.westerlund at ericsson.com (Magnus Westerlund)
Date: Tue Jan  3 16:22:47 2006
Subject: Comments on draft-freed-media-types-reg-01.txt
In-Reply-To: <[email-masked]>
References: <[email-masked]> <[email-masked]>
Message-ID: <[email-masked]>

Hi Ned,

See below.

[email-masked] wrote:

>> 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
> But this is what the section already says:
> 
>   However, with the simplified registration procedures described above
>   for vendor and personal trees, it should rarely, if ever, be
>   necessary to use unregistered experimental types, and as such use of
>   both "x-" and "x." forms is discouraged.
> 
> I think this is pretty clear already.

I think one could use a stronger language in discouraging people.

  [snip]

> 
>> 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?
> 
> 
> IMO if the parameter space is different the types are different. I don't
> think it is appropriate to have domain-specific parameters, only
> type-specific ones.

Okay, so registering the RTP payload format and a dedicated file format 
for the same codec needs to use two different media types, due to that 
that they partially needs to have different parameters?

I have an example in the draft-ietf-avt-rtp-vmr-wb-03.txt where we have 
RTP payload format that carries the different audio frames. There is 
also a specification of a file format, that also contains the same 
frames. The wrapping structure is somewhat different due to that they 
are file format and RTP payload format. In my view both format has 
advantages of using the parameters:

mode-set
channels
dtx
rate

While the RTP payload format also needs in addition the following:
ptime
maxptime
octet-align
interleaving

These parameter has all to do with how you configure the RTP payload 
format and how much media you aggregate together.

The basic common structure, and the need for the same media coder makes 
it reasonable from my perspective to use the same media type name for 
both usage. The context one receives the media type will make it clear 
what exact format that will be used.

Comments

> 
>> MW4: Section 4.3: Syntax rules for parameters? I think the syntax (ABNF)
[snip]
> The best I can do here is to say that specific transport may impose
> limits on the allowed syntax for parameter values. I will add words to
> that effect.

Okay

> 
>> 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.
> 
> 
> I'm really not sure we want to go here. Asking for people to specify an
> application names gets us onto a slippery slope towards having an 
> application
> name registrary. And AFAIK past experience with such registrations has been
> poor.

I understand. I might have not meant application really correctly. What 
I mean is that if we update the RTP registration rules for media types, 
we can define a string that should be written into Restriction on usage 
if only RTP is supported. That way we are not really being explicit 
about application, but can ensure that we have a good definition on what 
restriction we applies.

The fact is that RTP is not an application, it is a framework that 
different application can use.

> 
>> 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?
> 
> 
> I guess I don't see the problem. The commonality of use of something
> has almost nothing to do with how usage is restricted. I could have
> a media type that's commonly used but only RTP. Or I could have
> an obsolete type that can be used anywhere. Any combination is possible.
> 
> Perhaps moving the restrictions on usage field below the intended usage
> field in the registration form and adding some text as to what goes
> in the restrictions on usage will help.
> 

What could happen is that we have a media type that is for a codec and 
with two defined usages, file format and RTP payload format. The RTP 
payload format is after standardization used, but later found unsuitable 
for usage. Therefore a new RTP payload format is defined. However as 
there is a deployed basis one can't simple use the same media type for 
the new RTP payload format and defines a new one. The previous name is 
still valid for the file format part, while OBSOLETE for the RTP payload 
part.

The above is the reason I think one might need to consider to provide 
"intended usage" for different usages.

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: Jeff.Hodges at KingsMountain.com ([email-masked])
Date: Tue Sep  7 17:39:12 2004
Subject: draft-freed-mime-p4-04 is apparently superseded by.. 
In-Reply-To: [email-masked] 's message of  Mon, 06 Sep 2004 15:13:35 -0700
Message-ID: <[email-masked]>

>   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

From: Jeff.Hodges at KingsMountain.com ([email-masked])
Date: Tue Jan  3 16:22:47 2006
Subject: draft-freed-mime-p4-04 is apparently superseded by.. 
In-Reply-To: [email-masked] 's message of  Mon, 06 Sep 2004 15:13:35 -0700
Message-ID: <[email-masked]>

>   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

From: ned.freed at mrochek.com ([email-masked])
Date: Tue Sep  7 17:52:35 2004
Subject: Comments on draft-freed-media-types-reg-01.txt
In-Reply-To: "Your message dated Tue, 07 Sep 2004 16:39:59 +0200" <[email-masked]>
References: <[email-masked]>
Message-ID: <[email-masked]>

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

But this is what the section already says:

   However, with the simplified registration procedures described above
   for vendor and personal trees, it should rarely, if ever, be
   necessary to use unregistered experimental types, and as such use of
   both "x-" and "x." forms is discouraged.

I think this is pretty clear already.

> 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?

I would say it belongs in the registration document.

> 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?

IMO if the parameter space is different the types are different. I don't
think it is appropriate to have domain-specific parameters, only
type-specific ones.

> MW4: Section 4.3: Syntax rules for parameters? I think the syntax (ABNF)
> definition of the parameter values need to be properly defined.

That's impossible because there really isn't one. Parameter encoding is allowed
in MIME, with the result that parameters can be (a) Tagged with a particular
charset, and (b) If need be can be pure binary.

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

Mail at least allows binary parameter values.

The best I can do here is to say that specific transport may impose
limits on the allowed syntax for parameter values. I will add words to
that effect.

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

I'm really not sure we want to go here. Asking for people to specify an
application names gets us onto a slippery slope towards having an application
name registrary. And AFAIK past experience with such registrations has been
poor.

> 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?

I guess I don't see the problem. The commonality of use of something
has almost nothing to do with how usage is restricted. I could have
a media type that's commonly used but only RTP. Or I could have
an obsolete type that can be used anywhere. Any combination is possible.

Perhaps moving the restrictions on usage field below the intended usage
field in the registration form and adding some text as to what goes
in the restrictions on usage will help.

> 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?

I have no problem with splitting the field.

				Ned
>From [email-masked]  Wed Sep  8 15:06:07 2004
From: magnus.westerlund at ericsson.com (Magnus Westerlund)
Date: Wed Sep  8 15:06:20 2004
Subject: Comments on draft-freed-media-types-reg-01.txt
In-Reply-To: <[email-masked]>
References: <[email-masked]>
	<[email-masked]>
Message-ID: <[email-masked]>

Hi Ned,

See below.

[email-masked] wrote:

>> 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
> But this is what the section already says:
> 
>   However, with the simplified registration procedures described above
>   for vendor and personal trees, it should rarely, if ever, be
>   necessary to use unregistered experimental types, and as such use of
>   both "x-" and "x." forms is discouraged.
> 
> I think this is pretty clear already.

I think one could use a stronger language in discouraging people.

  [snip]

> 
>> 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?
> 
> 
> IMO if the parameter space is different the types are different. I don't
> think it is appropriate to have domain-specific parameters, only
> type-specific ones.

Okay, so registering the RTP payload format and a dedicated file format 
for the same codec needs to use two different media types, due to that 
that they partially needs to have different parameters?

I have an example in the draft-ietf-avt-rtp-vmr-wb-03.txt where we have 
RTP payload format that carries the different audio frames. There is 
also a specification of a file format, that also contains the same 
frames. The wrapping structure is somewhat different due to that they 
are file format and RTP payload format. In my view both format has 
advantages of using the parameters:

mode-set
channels
dtx
rate

While the RTP payload format also needs in addition the following:
ptime
maxptime
octet-align
interleaving

These parameter has all to do with how you configure the RTP payload 
format and how much media you aggregate together.

The basic common structure, and the need for the same media coder makes 
it reasonable from my perspective to use the same media type name for 
both usage. The context one receives the media type will make it clear 
what exact format that will be used.

Comments

> 
>> MW4: Section 4.3: Syntax rules for parameters? I think the syntax (ABNF)
[snip]
> The best I can do here is to say that specific transport may impose
> limits on the allowed syntax for parameter values. I will add words to
> that effect.

Okay

> 
>> 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.
> 
> 
> I'm really not sure we want to go here. Asking for people to specify an
> application names gets us onto a slippery slope towards having an 
> application
> name registrary. And AFAIK past experience with such registrations has been
> poor.

I understand. I might have not meant application really correctly. What 
I mean is that if we update the RTP registration rules for media types, 
we can define a string that should be written into Restriction on usage 
if only RTP is supported. That way we are not really being explicit 
about application, but can ensure that we have a good definition on what 
restriction we applies.

The fact is that RTP is not an application, it is a framework that 
different application can use.

> 
>> 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?
> 
> 
> I guess I don't see the problem. The commonality of use of something
> has almost nothing to do with how usage is restricted. I could have
> a media type that's commonly used but only RTP. Or I could have
> an obsolete type that can be used anywhere. Any combination is possible.
> 
> Perhaps moving the restrictions on usage field below the intended usage
> field in the registration form and adding some text as to what goes
> in the restrictions on usage will help.
> 

What could happen is that we have a media type that is for a codec and 
with two defined usages, file format and RTP payload format. The RTP 
payload format is after standardization used, but later found unsuitable 
for usage. Therefore a new RTP payload format is defined. However as 
there is a deployed basis one can't simple use the same media type for 
the new RTP payload format and defines a new one. The previous name is 
still valid for the file format part, while OBSOLETE for the RTP payload 
part.

The above is the reason I think one might need to consider to provide 
"intended usage" for different usages.

Cheers

Magnus Westerlund

Multimedia Technologies, Ericsson Research EAB/TVA/A
----------------------------------------------------------------------
Ericsson AB                | Phone +46 8 4048287
Torshamsgatan 23           | Fax   +46 8 7575550
S-164 80 Stockholm, Sweden | mailto: [email-masked]
>From [email-masked]  Wed Sep  8 15:59:54 2004
From: ned.freed at mrochek.com ([email-masked])
Date: Wed Sep  8 16:12:07 2004
Subject: [AVT] Re: Comments on draft-freed-media-types-reg-01.txt
In-Reply-To: "Your message dated Wed, 08 Sep 2004 15:06:07 +0200"
	<[email-masked]>
References: <[email-masked]>
	<[email-masked]> <[email-masked]>
Message-ID: <[email-masked]>

> Hi Ned,

> See below.

> [email-masked] wrote:

> >> 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
> > But this is what the section already says:
> >
> >   However, with the simplified registration procedures described above
> >   for vendor and personal trees, it should rarely, if ever, be
> >   necessary to use unregistered experimental types, and as such use of
> >   both "x-" and "x." forms is discouraged.
> >
> > I think this is pretty clear already.

> I think one could use a stronger language in discouraging people.

Then by all means suggest some.

> >
> >> 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?
> >
> >
> > IMO if the parameter space is different the types are different. I don't
> > think it is appropriate to have domain-specific parameters, only
> > type-specific ones.

> Okay, so registering the RTP payload format and a dedicated file format
> for the same codec needs to use two different media types, due to that
> that they partially needs to have different parameters?

They most certainly do.

> I have an example in the draft-ietf-avt-rtp-vmr-wb-03.txt where we have
> RTP payload format that carries the different audio frames. There is
> also a specification of a file format, that also contains the same
> frames. The wrapping structure is somewhat different due to that they
> are file format and RTP payload format.

In other words, the bits are different as well. That means two media types are
required regardless of whether or not the parameters are the same.

While it is nice to be able to cater to some extent to protocol-specific needs
in our procedures, we cannot afford to compromise the core functionality media
types provide. One of those core functions is that each type labels a single,
canonical object format. Types don't label codecs, and it has long been the
case that a single codec can give rise to multiple media types. (It is also
possible for multiple codecs to be combined in a single type.)

> I understand. I might have not meant application really correctly. What
> I mean is that if we update the RTP registration rules for media types,
> we can define a string that should be written into Restriction on usage
> if only RTP is supported. That way we are not really being explicit
> about application, but can ensure that we have a good definition on what
> restriction we applies.

That may be the right thing to do for RTP, but we need to think more
generally here. Of course nothing prevents RTP from specifying its
own additional registrations requirements for media types it uses.
The MIME specification is certainly going to do something along these
lines once it is revised.

> >> 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?
> >
> >
> > I guess I don't see the problem. The commonality of use of something
> > has almost nothing to do with how usage is restricted. I could have
> > a media type that's commonly used but only RTP. Or I could have
> > an obsolete type that can be used anywhere. Any combination is possible.
> >
> > Perhaps moving the restrictions on usage field below the intended usage
> > field in the registration form and adding some text as to what goes
> > in the restrictions on usage will help.
> >

> What could happen is that we have a media type that is for a codec and
> with two defined usages, file format and RTP payload format. The RTP
> payload format is after standardization used, but later found unsuitable
> for usage. Therefore a new RTP payload format is defined. However as
> there is a deployed basis one can't simple use the same media type for
> the new RTP payload format and defines a new one. The previous name is
> still valid for the file format part, while OBSOLETE for the RTP payload
> part.

In other words, having a media type that labels more than one sort of 
object can give rise to situations where the intended usage varies
depending on where the type is employed. This is hardly surprising given
that the initial premise violates the entire media type philosophy.

This is still more reason why having a single label for two very differnet
things is TOTALLY unacceptable.

				Ned
>From [email-masked]  Thu Sep  9 17:37:52 2004
From: ned.freed at mrochek.com ([email-masked])
Date: Thu Sep  9 18:39:16 2004
Subject: [AVT] Re: Comments on draft-freed-media-types-reg-01.txt
In-Reply-To: "Your message dated Thu, 09 Sep 2004 11:54:06 +0200"
	<[email-masked]>
References: <[email-masked]>
	<[email-masked]>
Message-ID: <[email-masked]>

> > > 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
>From [email-masked]  Fri Sep 10 17:12:06 2004
From: sla at ucolick.org (Steve Allen)
Date: Fri Sep 10 17:12:17 2004
Subject: publication of FITS MIME Internet-Draft
In-Reply-To: <[email-masked]>
References: <[email-masked]>
Message-ID: <[email-masked]>

In accordance with the recommendation of the International
Astronomical Union FITS Working Group (IAUFWG) I have requested that
the Internet-Draft with the name
<draft-allen-fitsmime-00.txt>
be considered for publication as an Informational RFC.

This Internet-Draft specifies two new top-level MIME media types,
image/fits and application/fits
The shepherd, Scott Hollenbeck, points out the requirement
that IETF-Types be involved.

Please review the content of <draft-allen-fitsmime-00.txt>
and the two media type applications within it.

Thank you.

Background information:

The process by which this document gained IAUFWG approval is
visible at
http://www.ucolick.org/~sla/fits/mime/

The archives of the IAUFWG are visible via
http://listmgr.cv.nrao.edu/pipermail/iaufwg/

The charter given to me by the IAUFWG is visible in the archives at
http://listmgr.cv.nrao.edu/pipermail/iaufwg/2004-July/000200.html

The vote results indicating unanimous approval for submission is at
http://listmgr.cv.nrao.edu/pipermail/iaufwg/2004-August/000212.html

--
Steve Allen          UCO/Lick Observatory       Santa Cruz, CA 95064
[email-masked]      Voice: +1 831 459 3046     http://www.ucolick.org/~sla
PGP: 1024/E46978C5   F6 78 D1 10 62 94 8F 2E    49 89 0E FE 26 B4 14 93
>From [email-masked]  Fri Sep 10 23:40:15 2004
From: lisa at osafoundation.org (Lisa Dusseault)
Date: Fri Sep 10 23:40:33 2004
Subject: MIME registration for application/gdiff
Message-ID: <[email-masked]>

I'm trying to register a MIME type officially for application/gdiff.  
This type was defined in a W3C NOTE several years ago:

<http://www.w3.org/TR/NOTE-gdiff-19970901>

That Note defines the MIME type but apparently the authors never 
registered the MIME type with IANA.  Now we'd like to use gdiff in 
applications where we'd be using the MIME type so having it officially 
registered would be nice.   For example in:

<http://www.ietf.org/internet-drafts/draft-dusseault-http-patch-05.txt>

I submitted the registration through the IANA web form six weeks ago 
but haven't gotten a response other than the automated form submission 
response.  Is this smoothly underway or is there anything else I need 
to or can optionally do to help this registration out?  Is there 
anywhere to see the status of requests?

Thanks,
Lisa Dusseault

PS I had to subscribe to this list to get my posting accepted -- I 
first sent this message in August but it disappeared into a black hole.

Lisa

From: ned.freed at mrochek.com ([email-masked])
Date: Tue Jan  3 16:22:47 2006
Subject: Comments on draft-freed-media-types-reg-01.txt
In-Reply-To: "Your message dated Tue, 07 Sep 2004 16:39:59 +0200" <[email-masked]>
References: <[email-masked]>
Message-ID: <[email-masked]>

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

But this is what the section already says:

   However, with the simplified registration procedures described above
   for vendor and personal trees, it should rarely, if ever, be
   necessary to use unregistered experimental types, and as such use of
   both "x-" and "x." forms is discouraged.

I think this is pretty clear already.

> 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?

I would say it belongs in the registration document.

> 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?

IMO if the parameter space is different the types are different. I don't
think it is appropriate to have domain-specific parameters, only
type-specific ones.

> MW4: Section 4.3: Syntax rules for parameters? I think the syntax (ABNF)
> definition of the parameter values need to be properly defined.

That's impossible because there really isn't one. Parameter encoding is allowed
in MIME, with the result that parameters can be (a) Tagged with a particular
charset, and (b) If need be can be pure binary.

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

Mail at least allows binary parameter values.

The best I can do here is to say that specific transport may impose
limits on the allowed syntax for parameter values. I will add words to
that effect.

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

I'm really not sure we want to go here. Asking for people to specify an
application names gets us onto a slippery slope towards having an application
name registrary. And AFAIK past experience with such registrations has been
poor.

> 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?

I guess I don't see the problem. The commonality of use of something
has almost nothing to do with how usage is restricted. I could have
a media type that's commonly used but only RTP. Or I could have
an obsolete type that can be used anywhere. Any combination is possible.

Perhaps moving the restrictions on usage field below the intended usage
field in the registration form and adding some text as to what goes
in the restrictions on usage will help.

> 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?

I have no problem with splitting the field.

				Ned

From: AAllison at nab.org (Allison, Art)
Date: Tue Jan  3 16:22:48 2006
Subject: [AVT] Comments on draft-freed-media-types-reg-01.txt
Message-ID: <[email-masked]>

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:[email-masked]]
Sent: Tuesday, September 07, 2004 10:40 AM
To: Ned Freed; John C Klensin; [email-masked]'
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: [email-masked]

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

From: magnus.westerlund at ericsson.com (Magnus Westerlund)
Date: Tue Jan  3 16:22:47 2006
Subject: Comments on draft-freed-media-types-reg-01.txt
Message-ID: <[email-masked]>

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

From: singer at apple.com (Dave Singer)
Date: Tue Jan  3 16:22:48 2006
Subject: Media Types in 3GPP Timed text draft (was: RE: [AVT] RTP  andMediaTypes)
In-Reply-To: <[email-masked]>
References: <[email-masked]> <[email-masked]> <p06100527bd636a030953@[153.96.168.130]> <[email-masked]>
Message-ID: <p06100529bd636cf6ba54@[153.96.168.130]>

At 3:46 PM +0200 9/7/04, Magnus Westerlund wrote:
>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.

agreed.  if you don't understand the payload-specific headers, it is 
no help to know that some of what you are looking at is expressed in 
textual 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]

-- 
David Singer
Apple Computer/QuickTime

From: magnus.westerlund at ericsson.com (Magnus Westerlund)
Date: Tue Sep  7 15:46:31 2004
Subject: Media Types in 3GPP Timed text draft (was: RE: [AVT] RTP andMediaTypes)
In-Reply-To: <p06100527bd636a030953@[153.96.168.130]>
References: <[email-masked]> <[email-masked]> <p06100527bd636a030953@[153.96.168.130]>
Message-ID: <[email-masked]>

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: [email-masked]
>From [email-masked]  Tue Sep  7 16:39:59 2004
From: magnus.westerlund at ericsson.com (Magnus Westerlund)
Date: Tue Sep  7 16:40:19 2004
Subject: Comments on draft-freed-media-types-reg-01.txt
Message-ID: <[email-masked]>

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

From: magnus.westerlund at ericsson.com (Magnus Westerlund)
Date: Tue Jan  3 16:22:47 2006
Subject: Media Types in 3GPP Timed text draft (was: RE: [AVT] RTP andMediaTypes)
In-Reply-To: <p06100527bd636a030953@[153.96.168.130]>
References: <[email-masked]> <[email-masked]> <p06100527bd636a030953@[153.96.168.130]>
Message-ID: <[email-masked]>

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

From: singer at apple.com (Dave Singer)
Date: Thu Sep 16 09:17:26 2004
Subject: Media Types in 3GPP Timed text draft (was: RE: [AVT] RTP  andMediaTypes)
In-Reply-To: <[email-masked]>
References: <[email-masked]> <[email-masked]>
Message-ID: <p06100527bd636a030953@[153.96.168.130]>

At 1:25 PM +0100 9/7/04, Colin Perkins wrote:
>Jose,
>
>On 7 Sep 2004, at 12:56, Jose Rey wrote:
>>>-----Original Message-----
>>>From: Colin Perkins [mailto:[email-masked]]
>>>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.

But text/html is not only rendering text, it is expressed in text. 
3GPP renders text, but it is expressed in binary.

>
>>>>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

-- 
David Singer
Apple Computer/QuickTime
>From [email-masked]  Tue Sep  7 15:50:15 2004
From: singer at apple.com (Dave Singer)
Date: Thu Sep 16 09:17:30 2004
Subject: Media Types in 3GPP Timed text draft (was: RE: [AVT] RTP 
 andMediaTypes)
In-Reply-To: <[email-masked]>
References: <[email-masked]>
	<[email-masked]>
	<p06100527bd636a030953@[153.96.168.130]>
	<[email-masked]>
Message-ID: <p06100529bd636cf6ba54@[153.96.168.130]>

At 3:46 PM +0200 9/7/04, Magnus Westerlund wrote:
>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.

agreed.  if you don't understand the payload-specific headers, it is 
no help to know that some of what you are looking at is expressed in 
textual 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]

-- 
David Singer
Apple Computer/QuickTime
>From [email-masked]  Tue Sep  7 16:54:59 2004
From: AAllison at nab.org (Allison, Art)
Date: Thu Sep 16 09:17:32 2004
Subject: [AVT] Comments on draft-freed-media-types-reg-01.txt
Message-ID: <[email-masked]>

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:[email-masked]]
Sent: Tuesday, September 07, 2004 10:40 AM
To: Ned Freed; John C Klensin; [email-masked]'
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: [email-masked]

_______________________________________________
Audio/Video Transport Working Group
[email-masked]
https://www1.ietf.org/mailman/listinfo/avt
>From [email-masked]  Thu Sep  9 05:35:10 2004
From: klensin at jck.com (John C Klensin)
Date: Thu Sep 16 09:17:35 2004
Subject: [AVT] Re: Comments on
 draft-freed-media-types-reg-01.txt
In-Reply-To: <[email-masked]>
References: <[email-masked]>
	<[email-masked]>
	<[email-masked]>
	<[email-masked]>
Message-ID: <[email-masked]>

Hi.

For whatever the additional calibration is worth, my reactions
are in complete agreement with Ned's on all issues.  In
particular, the notion of registration by application, rather
than file (body part) content has been absolutely miserable and
a plague on interoperability.  Part of the reason is that, in
many situations, we can have application X that can handle file
formats A, B, and C, and application Y that can handle file
formats D, E, and B.  If the content types reflect the formats,
there is no problem -- both simply use B.  If they reflect the
applications, then there is an serious interoperability problem.

   john

--On Wednesday, 08 September, 2004 06:59 -0700
[email-masked] wrote:

>> Hi Ned,
> 
>> See below.
> 
>> [email-masked] wrote:
> 
>> >> 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
>> > But this is what the section already says:
>> > 
>> >   However, with the simplified registration procedures
>> >   described above for vendor and personal trees, it should
>> >   rarely, if ever, be necessary to use unregistered
>> >   experimental types, and as such use of both "x-" and "x."
>> >   forms is discouraged.
>> > 
>> > I think this is pretty clear already.
> 
>> I think one could use a stronger language in discouraging
>> people.
> 
> Then by all means suggest some.
> 
>> > 
>> >> 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?
>> > 
>> > 
>> > IMO if the parameter space is different the types are
>> > different. I don't think it is appropriate to have
>> > domain-specific parameters, only type-specific ones.
> 
>> Okay, so registering the RTP payload format and a dedicated
>> file format for the same codec needs to use two different
>> media types, due to that that they partially needs to have
>> different parameters?
> 
> They most certainly do.
> 
>> I have an example in the draft-ietf-avt-rtp-vmr-wb-03.txt
>> where we have RTP payload format that carries the different
>> audio frames. There is also a specification of a file format,
>> that also contains the same frames. The wrapping structure is
>> somewhat different due to that they are file format and RTP
>> payload format.
> 
> In other words, the bits are different as well. That means two
> media types are
> required regardless of whether or not the parameters are the
> same.
> 
> While it is nice to be able to cater to some extent to
> protocol-specific needs
> in our procedures, we cannot afford to compromise the core
> functionality media
> types provide. One of those core functions is that each type
> labels a single,
> canonical object format. Types don't label codecs, and it has
> long been the
> case that a single codec can give rise to multiple media
> types. (It is also
> possible for multiple codecs to be combined in a single type.)
> 
>> I understand. I might have not meant application really
>> correctly. What I mean is that if we update the RTP
>> registration rules for media types, we can define a string
>> that should be written into Restriction on usage if only RTP
>> is supported. That way we are not really being explicit about
>> application, but can ensure that we have a good definition on
>> what restriction we applies.
> 
> That may be the right thing to do for RTP, but we need to
> think more
> generally here. Of course nothing prevents RTP from specifying
> its
> own additional registrations requirements for media types it
> uses.
> The MIME specification is certainly going to do something
> along these
> lines once it is revised.
> 
>> >> 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?
>> > 
>> > 
>> > I guess I don't see the problem. The commonality of use of
>> > something has almost nothing to do with how usage is
>> > restricted. I could have a media type that's commonly used
>> > but only RTP. Or I could have an obsolete type that can be
>> > used anywhere. Any combination is possible.
>> > 
>> > Perhaps moving the restrictions on usage field below the
>> > intended usage field in the registration form and adding
>> > some text as to what goes in the restrictions on usage will
>> > help.
>> > 
> 
>> What could happen is that we have a media type that is for a
>> codec and with two defined usages, file format and RTP
>> payload format. The RTP payload format is after
>> standardization used, but later found unsuitable for usage.
>> Therefore a new RTP payload format is defined. However as
>> there is a deployed basis one can't simple use the same media
>> type for the new RTP payload format and defines a new one.
>> The previous name is still valid for the file format part,
>> while OBSOLETE for the RTP payload part.
> 
> In other words, having a media type that labels more than one
> sort of object can give rise to situations where the intended
> usage varies
> depending on where the type is employed. This is hardly
> surprising given
> that the initial premise violates the entire media type
> philosophy.
> 
> This is still more reason why having a single label for two
> very differnet
> things is TOTALLY unacceptable.
> 
> 				Ned

From: singer at apple.com (Dave Singer)
Date: Tue Jan  3 16:22:48 2006
Subject: Media Types in 3GPP Timed text draft (was: RE: [AVT] RTP  andMediaTypes)
In-Reply-To: <[email-masked]>
References: <[email-masked]> <[email-masked]>
Message-ID: <p06100527bd636a030953@[153.96.168.130]>

At 1:25 PM +0100 9/7/04, Colin Perkins wrote:
>Jose,
>
>On 7 Sep 2004, at 12:56, Jose Rey wrote:
>>>-----Original Message-----
>>>From: Colin Perkins [mailto:[email-masked]]
>>>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.

But text/html is not only rendering text, it is expressed in text. 
3GPP renders text, but it is expressed in binary.

>
>>>>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

-- 
David Singer
Apple Computer/QuickTime

From: rey at panasonic.de (Jose Rey)
Date: Thu Sep 16 09:17:23 2004
Subject: Media Types in 3GPP Timed text draft (was: RE: [AVT] RTP andMediaTypes)
In-Reply-To: <[email-masked]>
Message-ID: <[email-masked]>

--cut--
> > 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.

It is just that in the MIME presentation in SD it says that text/t140 does
'arguably' comply with the traditional rules...what this 'arguably' means
was not clear to us.

--cut--
> >>> 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.
>

No. What I mean is what would be the use of having two for RTP, which in
this case is just confusing.

Jose

> Colin
>
>

From: rey at panasonic.de (Jose Rey)
Date: Tue Jan  3 16:22:48 2006
Subject: Media Types in 3GPP Timed text draft (was: RE: [AVT] RTP andMediaTypes)
In-Reply-To: <[email-masked]>
Message-ID: <[email-masked]>

--cut--
> > 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.

It is just that in the MIME presentation in SD it says that text/t140 does
'arguably' comply with the traditional rules...what this 'arguably' means
was not clear to us.

--cut--
> >>> 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.
>

No. What I mean is what would be the use of having two for RTP, which in
this case is just confusing.

Jose

> Colin
>
>

From: csp at csperkins.org (Colin Perkins)
Date: Tue Jan  3 16:22:47 2006
Subject: Media Types in 3GPP Timed text draft (was: RE: [AVT] RTP andMediaTypes)
In-Reply-To: <[email-masked]>
References: <[email-masked]>
Message-ID: <[email-masked]>

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

From: rey at panasonic.de (Jose Rey)
Date: Tue Jan  3 16:22:48 2006
Subject: Media Types in 3GPP Timed text draft (was: RE: [AVT] RTP andMediaTypes)
In-Reply-To: <[email-masked]>
Message-ID: <[email-masked]>

> -----Original Message-----
> From: Colin Perkins [mailto:[email-masked]]
> Sent: Tuesday, September 07, 2004 2:26 PM
> To: Jose Rey
> Cc: Magnus Westerlund; IETF-Types; IETF AVT WG; Dave Singer
> Subject: Re: Media Types in 3GPP Timed text draft (was: RE: [AVT] RTP
> andMediaTypes)
>
>
> Jose,
>
> On 7 Sep 2004, at 12:56, Jose Rey wrote:
> >> -----Original Message-----
> >> From: Colin Perkins [mailto:[email-masked]]
> >> 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.
>

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'?

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

I think that as Magnus says there may be more motivation to go for text/
because of the selectability. That and the above are good reasons for me.

Summarising, it seems that we agree to choose text/.  Great! I can change
the registration to text/ if this settles it and submit the new revision and
let the MIME people review it.

Cheers,

Jose

> > 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
>
>

From: magnus.westerlund at ericsson.com (Magnus Westerlund)
Date: Tue Sep  7 14:26:36 2004
Subject: Media Types in 3GPP Timed text draft (was: RE: [AVT] RTP andMediaTypes)
In-Reply-To: <[email-masked]>
References: <[email-masked]>
Message-ID: <[email-masked]>

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: [email-masked]
>From [email-masked]  Tue Sep  7 14:58:31 2004
From: csp at csperkins.org (Colin Perkins)
Date: Tue Sep  7 14:58:47 2004
Subject: Media Types in 3GPP Timed text draft (was: RE: [AVT] RTP
	andMediaTypes)
In-Reply-To: <[email-masked]>
References: <[email-masked]>
Message-ID: <[email-masked]>

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

From: magnus.westerlund at ericsson.com (Magnus Westerlund)
Date: Tue Jan  3 16:22:47 2006
Subject: Media Types in 3GPP Timed text draft (was: RE: [AVT] RTP andMediaTypes)
In-Reply-To: <[email-masked]>
References: <[email-masked]>
Message-ID: <[email-masked]>

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

From: csp at csperkins.org (Colin Perkins)
Date: Tue Sep  7 14:26:06 2004
Subject: Media Types in 3GPP Timed text draft (was: RE: [AVT] RTP andMediaTypes)
In-Reply-To: <[email-masked]>
References: <[email-masked]>
Message-ID: <[email-masked]>

Jose,

On 7 Sep 2004, at 12:56, Jose Rey wrote:
>> -----Original Message-----
>> From: Colin Perkins [mailto:[email-masked]]
>> 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

From: csp at csperkins.org (Colin Perkins)
Date: Tue Jan  3 16:22:47 2006
Subject: Media Types in 3GPP Timed text draft (was: RE: [AVT] RTP andMediaTypes)
In-Reply-To: <[email-masked]>
References: <[email-masked]>
Message-ID: <[email-masked]>

Jose,

On 7 Sep 2004, at 12:56, Jose Rey wrote:
>> -----Original Message-----
>> From: Colin Perkins [mailto:[email-masked]]
>> 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

From: rey at panasonic.de (Jose Rey)
Date: Tue Jan  3 16:22:48 2006
Subject: Media Types in 3GPP Timed text draft (was: RE: [AVT] RTP andMediaTypes)
In-Reply-To: <[email-masked]>
Message-ID: <[email-masked]>

Colin,

Thanks for your answers. See inline.

> -----Original Message-----
> From: Colin Perkins [mailto:[email-masked]]
> 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)
>
>
> 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?

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.

> > 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?

Cheers,

Jose

> Colin
>
>

From: singer at apple.com (Dave Singer)
Date: Thu Sep 16 09:17:20 2004
Subject: Media Types in 3GPP Timed text draft (was: RE: [AVT] RTP  andMediaTypes)
In-Reply-To: <[email-masked]>
References: <[email-masked]> <[email-masked]>
Message-ID: <p06100524bd6351a9544b@[153.96.168.130]>

At 11:02 AM +0100 9/7/04, Colin Perkins wrote:
>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/".

It's fundamentally for presenting visual information, but that visual 
information is achieved by rendering text.  It all depends on what 
the meaning of "text codec" is...

>
>>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

ah, OK.

for me, I don't mind which of text/ or video/ is chosen, provided it 
is only one of them!
-- 
David Singer
Apple Computer/QuickTime
>From [email-masked]  Tue Sep  7 14:54:39 2004
From: rey at panasonic.de (Jose Rey)
Date: Thu Sep 16 09:17:21 2004
Subject: Media Types in 3GPP Timed text draft (was: RE: [AVT] RTP
	andMediaTypes)
In-Reply-To: <[email-masked]>
Message-ID: <[email-masked]>

> -----Original Message-----
> From: Colin Perkins [mailto:[email-masked]]
> Sent: Tuesday, September 07, 2004 2:26 PM
> To: Jose Rey
> Cc: Magnus Westerlund; IETF-Types; IETF AVT WG; Dave Singer
> Subject: Re: Media Types in 3GPP Timed text draft (was: RE: [AVT] RTP
> andMediaTypes)
>
>
> Jose,
>
> On 7 Sep 2004, at 12:56, Jose Rey wrote:
> >> -----Original Message-----
> >> From: Colin Perkins [mailto:[email-masked]]
> >> 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.
>

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'?

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

I think that as Magnus says there may be more motivation to go for text/
because of the selectability. That and the above are good reasons for me.

Summarising, it seems that we agree to choose text/.  Great! I can change
the registration to text/ if this settles it and submit the new revision and
let the MIME people review it.

Cheers,

Jose

> > 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
>
>

From: singer at apple.com (Dave Singer)
Date: Tue Jan  3 16:22:48 2006
Subject: Media Types in 3GPP Timed text draft (was: RE: [AVT] RTP  andMediaTypes)
In-Reply-To: <[email-masked]>
References: <[email-masked]> <[email-masked]>
Message-ID: <p06100524bd6351a9544b@[153.96.168.130]>

At 11:02 AM +0100 9/7/04, Colin Perkins wrote:
>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/".

It's fundamentally for presenting visual information, but that visual 
information is achieved by rendering text.  It all depends on what 
the meaning of "text codec" is...

>
>>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

ah, OK.

for me, I don't mind which of text/ or video/ is chosen, provided it 
is only one of them!
-- 
David Singer
Apple Computer/QuickTime

From: csp at csperkins.org (Colin Perkins)
Date: Tue Sep  7 13:22:03 2004
Subject: Media Types in 3GPP Timed text draft (was: RE: [AVT] RTP andMediaTypes)
In-Reply-To: <[email-masked]>
References: <[email-masked]>
Message-ID: <[email-masked]>

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

From: csp at csperkins.org (Colin Perkins)
Date: Tue Jan  3 16:22:47 2006
Subject: Media Types in 3GPP Timed text draft (was: RE: [AVT] RTP andMediaTypes)
In-Reply-To: <[email-masked]>
References: <[email-masked]>
Message-ID: <[email-masked]>

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

From: ned.freed at mrochek.com ([email-masked])
Date: Tue Sep  7 00:13:53 2004
Subject: draft-freed-mime-p4-04 is apparently superseded by..
In-Reply-To: "Your message dated Mon, 06 Sep 2004 11:40:59 -0700" <[email-masked]>
References: <[email-masked]>
Message-ID: <[email-masked]>

> > 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?

Yes. I don't know of any others.

				Ned

From: ned.freed at mrochek.com ([email-masked])
Date: Tue Jan  3 16:22:47 2006
Subject: draft-freed-mime-p4-04 is apparently superseded by..
In-Reply-To: "Your message dated Mon, 06 Sep 2004 11:40:59 -0700" <[email-masked]>
References: <[email-masked]>
Message-ID: <[email-masked]>

> > 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?

Yes. I don't know of any others.

				Ned

From: Jeff.Hodges at KingsMountain.com ([email-masked])
Date: Mon Sep  6 20:52:44 2004
Subject: Please review: DRAFT Reg of application/samlassertion+xml 
In-Reply-To: Graham Klyne <[email-masked]> 's message of  Mon, 06 Sep 2004 16:41:16 +0100
Message-ID: <[email-masked]>

> 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

From: Jeff.Hodges at KingsMountain.com ([email-masked])
Date: Tue Jan  3 16:22:47 2006
Subject: Please review: DRAFT Reg of application/samlassertion+xml 
In-Reply-To: Graham Klyne <[email-masked]> 's message of  Mon, 06 Sep 2004 16:41:16 +0100
Message-ID: <[email-masked]>

> 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

From: Jeff.Hodges at KingsMountain.com ([email-masked])
Date: Mon Sep  6 20:41:06 2004
Subject: draft-freed-mime-p4-04 is apparently superseded by.. 
In-Reply-To: [email-masked] 's message of  Sun, 05 Sep 2004 07:45:58 -0700
Message-ID: <[email-masked]>

> 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

From: Jeff.Hodges at KingsMountain.com ([email-masked])
Date: Tue Jan  3 16:22:47 2006
Subject: draft-freed-mime-p4-04 is apparently superseded by.. 
In-Reply-To: [email-masked] 's message of  Sun, 05 Sep 2004 07:45:58 -0700
Message-ID: <[email-masked]>

> 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

From: GK at ninebynine.org (Graham Klyne)
Date: Mon Sep  6 18:20:04 2004
Subject: Please review: DRAFT Registration of application/samlmetadata+xml
In-Reply-To: <[email-masked]>
Message-ID: <[email-masked]>

At 09:10 01/09/04 -0700, [email-masked] wrote:
>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 one of <md:EntityDescriptor>,
>            <md:AffiliationDescriptor>, or <md:EntitiesDescriptor>.
>            where "md" maps to the SAML v2.0 metadata namespace:
>            urn:oasis:names:tc:SAML:2.0:metadata

See comment concerning application/samlassertion+xml, posted separately.

#g

------------
Graham Klyne
For email:
http://www.ninebynine.org/#Contact

From: GK at ninebynine.org (Graham Klyne)
Date: Tue Jan  3 16:22:46 2006
Subject: Please review: DRAFT Registration of application/samlmetadata+xml
In-Reply-To: <[email-masked]>
Message-ID: <[email-masked]>

At 09:10 01/09/04 -0700, [email-masked] wrote:
>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 one of <md:EntityDescriptor>,
>            <md:AffiliationDescriptor>, or <md:EntitiesDescriptor>.
>            where "md" maps to the SAML v2.0 metadata namespace:
>            urn:oasis:names:tc:SAML:2.0:metadata

See comment concerning application/samlassertion+xml, posted separately.

#g

------------
Graham Klyne
For email:
http://www.ninebynine.org/#Contact

From: GK at ninebynine.org (Graham Klyne)
Date: Tue Jan  3 16:22:46 2006
Subject: Please review: DRAFT Reg of application/samlassertion+xml
In-Reply-To: <[email-masked]>
Message-ID: <[email-masked]>

At 09:06 01/09/04 -0700, [email-masked] wrote:
>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" maps to a version-specific SAML
>            assertion namespace, 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"
>            maps to the SAMLv2.0 assertion namespace:
>            urn:oasis:names:tc:SAML:2.0:assertion

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.

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.
]]

#g

------------
Graham Klyne
For email:
http://www.ninebynine.org/#Contact

From: ned.freed at mrochek.com ([email-masked])
Date: Sun Sep  5 16:51:27 2004
Subject: draft-freed-mime-p4-04 is apparently superseded by..
In-Reply-To: "Your message dated Wed, 01 Sep 2004 10:01:52 +0900" <4.2.0.58.J.20040901095413.02b35558@localhost>
References: <[email-masked]> <[email-masked]> <[email-masked]> <4.2.0.58.J.20040901095413.02b35558@localhost>
Message-ID: <[email-masked]>

> Many thanks for your clarifications.

> Is there anything we can do to move draft-freed-media-type-reg-01.txt forward?
> You say that it will got to last call 'once it has been determined that
> the various issues have been dealt with in a satisfactory way'. Who will
> make this determination, and when?

The final determination will be made by the IESG, as always. However, I
also expected some discussion of the document by the AVT folks by now;
AFAIK this hasn't happened yet.

> Also, you refer to some concerns regarding text/red and related
> types. Can you provide pointers to these discussions? (You refer
> to the change log in draft-freed-media-type-reg-01.txt, and I
> have looked though it, but it is not clear which changes are
> related to the text/red concerns, and which changes are separate.)

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.

				Ned
>From [email-masked]  Mon Sep  6 17:41:16 2004
From: GK at ninebynine.org (Graham Klyne)
Date: Mon Sep  6 18:19:57 2004
Subject: Please review: DRAFT Reg of application/samlassertion+xml
In-Reply-To: <[email-masked]>
Message-ID: <[email-masked]>

At 09:06 01/09/04 -0700, [email-masked] wrote:
>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" maps to a version-specific SAML
>            assertion namespace, 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"
>            maps to the SAMLv2.0 assertion namespace:
>            urn:oasis:names:tc:SAML:2.0:assertion

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.

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.
]]

#g

------------
Graham Klyne
For email:
http://www.ninebynine.org/#Contact

From: ned.freed at mrochek.com ([email-masked])
Date: Tue Jan  3 16:22:46 2006
Subject: draft-freed-mime-p4-04 is apparently superseded by..
In-Reply-To: "Your message dated Wed, 01 Sep 2004 10:01:52 +0900" <4.2.0.58.J.20040901095413.02b35558@localhost>
References: <[email-masked]> <[email-masked]> <[email-masked]> <4.2.0.58.J.20040901095413.02b35558@localhost>
Message-ID: <[email-masked]>

> Many thanks for your clarifications.

> Is there anything we can do to move draft-freed-media-type-reg-01.txt forward?
> You say that it will got to last call 'once it has been determined that
> the various issues have been dealt with in a satisfactory way'. Who will
> make this determination, and when?

The final determination will be made by the IESG, as always. However, I
also expected some discussion of the document by the AVT folks by now;
AFAIK this hasn't happened yet.

> Also, you refer to some concerns regarding text/red and related
> types. Can you provide pointers to these discussions? (You refer
> to the change log in draft-freed-media-type-reg-01.txt, and I
> have looked though it, but it is not clear which changes are
> related to the text/red concerns, and which changes are separate.)

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.

				Ned

From: ylafon at w3.org (Yves Lafon)
Date: Tue Jan  3 16:22:46 2006
Subject: Submission of the application/xop+xml Media Type
Message-ID: <[email-masked]>

All,
The media type is defined in the W3C Candidate Recommandation of
"XML-binary Optimized Packaging" [1]
Below is a full test version for convenience [2]
Please direct comments to [email-masked].
Best regards,

[1] http://www.w3.org/TR/2004/CR-xop10-20040826/#N103C0
[2]
MIME media type name:

     application
MIME subtype name:

     xop+xml
Required parameters:

     type

         This parameter conveys the content type associated with the XML 
serialization of the XOP infoset, including parameters as appropriate.

Optional parameters:

     charset

         This parameter has identical semantics to the charset parameter of 
the "application/xml" media type as specified in RFC 3023
     [RFC3023].

Encoding considerations:

     Identical to those of "application/xml" as described in RFC 3023 
[RFC3023], section 3.2.
Security considerations:

     In addition to application-specific considerations, XOP has the same 
security considerations described in RFC3023 [RFC3023], section 10.
Interoperability considerations:

     There are no known interoperability issues.
Published specification:

     This document
Applications which use this media type:

     No known applications currently use this media type.
Additional information:

     File extension:

         XOP
     Fragment identifiers:

         Identical to that of "application/xml" as described in RFC 3023 
[RFC3023], section 5.
     Base URI:

         As specified in RFC 3023 [RFC3023], section 6.
     Macintosh File Type code:

         TEXT

Person and email address to contact for further information:

     Mark Nottingham <[email-masked]>
Intended usage:

     COMMON
Author/Change controller:

     The XOP specification is a work product of the World Wide Web 
Consortium's XML Protocol Working Group. The W3C has change control over 
this specification.

-- 
Yves Lafon - W3C
"Baroula que barouleras, au ti?u toujou t'entourneras."
>From [email-masked]  Thu Sep  2 21:32:45 2004
From: Jeff.Hodges at KingsMountain.com ([email-masked])
Date: Tue Jan  3 16:22:46 2006
Subject: Please review: DRAFT Reg of application/samlassertion+xml 
In-Reply-To: Martin Duerst <[email-masked]> 's message of 
	Thu, 02 Sep 2004 13:45:53 +0900
Message-ID: <[email-masked]>

> At 09:06 04/09/01 -0700, [email-masked] wrote:
> 
> >For an overview of the intricities involved when a non-IETF organization
> >registers a MIME media type in the "standards tree" (aka "IETF tree"),
> >please see http://www.w3.org/2002/06/registering-mediatype.html.
> 
> 
> Please note that this page is written and intended only for media
> types from the W3C. This has been clarified in the title.
> It is mainly concerned about synchronizing the W3C Recommendation
> Process and the media type registration, and is based on discussion
> between W3C and IETF. Other organizations have different processes,
> and it is dangerous for them to base on the above document.

Your concern is appreciated, thanks. However, I do clearly say "overview", and 
I believe that your webpage is salient and worth investigating for those folks 
who are wearing hat(s) of non-IETF stds dvlp org(s) and wishing to register 
MIME media types, if only to use as a model for determining and documenting 
the process relative to their non-IETF org.

JeffH

From: magnus.westerlund at ericsson.com (Magnus Westerlund)
Date: Tue Jan  3 16:22:46 2006
Subject: Pre review of 3GPP MIME type for RTP payload format
In-Reply-To: <[email-masked]>
References: <[email-masked]>
Message-ID: <[email-masked]>

Hi Larry,

Comments below

Larry Masinter wrote:

> Thanks, I now understand. The main thing is that
> SDP takes the MIME type and uses the top level type
> for signaling.
> 
> I wonder, though, whether you might instead register
> these things as "application", add a parameter, e.g.,
> "embedded-type", and then change the mapping
> between MIME types and SDP descriptions such that
> 
> application/whatever;embedded-type="video" 
>   =>   m=video
> 
> so as to avoid having to register N types for
> every wrapper mechanism.
> 

Do we actually gain anything with not registering the type in all 
relevant media type? The reason is for example if you are finding a SDP 
and it contains an unknown type audio/whatever. Then if you like to 
determine what the type actually are and goes to IANA. I would assume 
that you would go looking at audio in the tree, rather than application.

Secondly, most types even wrappers may actually need to consider what 
media types they should be used at all. We also have these types that 
are more specific, but still are useful in multiple media types, like 
RFC 2198, that are used both in audio and text.

Is there any gain by doing a single type, using parameters more than 
purely administrative compared to registering them in each necessary 
media type?

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: duerst at w3.org (Martin Duerst)
Date: Thu Sep  2 06:46:05 2004
Subject: Please review: DRAFT Reg of application/samlassertion+xml
In-Reply-To: <[email-masked]>
Message-ID: <4.2.0.58.J.20040902134117.051301e8@localhost>

At 09:06 04/09/01 -0700, [email-masked] wrote:

>For an overview of the intricities involved when a non-IETF organization
>registers a MIME media type in the "standards tree" (aka "IETF tree"),
>please see http://www.w3.org/2002/06/registering-mediatype.html.

Please note that this page is written and intended only for media
types from the W3C. This has been clarified in the title.
It is mainly concerned about synchronizing the W3C Recommendation
Process and the media type registration, and is based on discussion
between W3C and IETF. Other organizations have different processes,
and it is dangerous for them to base on the above document.

Regards,    Martin.
>From [email-masked]  Thu Sep  2 09:58:15 2004
From: magnus.westerlund at ericsson.com (Magnus Westerlund)
Date: Thu Sep  2 09:58:26 2004
Subject: Pre review of 3GPP MIME type for RTP payload format
In-Reply-To: <[email-masked]>
References: <[email-masked]>
Message-ID: <[email-masked]>

Hi Larry,

Comments below

Larry Masinter wrote:

> Thanks, I now understand. The main thing is that
> SDP takes the MIME type and uses the top level type
> for signaling.
> 
> I wonder, though, whether you might instead register
> these things as "application", add a parameter, e.g.,
> "embedded-type", and then change the mapping
> between MIME types and SDP descriptions such that
> 
> application/whatever;embedded-type="video" 
>   =>   m=video
> 
> so as to avoid having to register N types for
> every wrapper mechanism.
> 

Do we actually gain anything with not registering the type in all 
relevant media type? The reason is for example if you are finding a SDP 
and it contains an unknown type audio/whatever. Then if you like to 
determine what the type actually are and goes to IANA. I would assume 
that you would go looking at audio in the tree, rather than application.

Secondly, most types even wrappers may actually need to consider what 
media types they should be used at all. We also have these types that 
are more specific, but still are useful in multiple media types, like 
RFC 2198, that are used both in audio and text.

Is there any gain by doing a single type, using parameters more than 
purely administrative compared to registering them in each necessary 
media type?

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 Sep  2 16:38:31 2004
From: ylafon at w3.org (Yves Lafon)
Date: Thu Sep  2 16:39:15 2004
Subject: Submission of the application/xop+xml Media Type
Message-ID: <[email-masked]>

All,
The media type is defined in the W3C Candidate Recommandation of
"XML-binary Optimized Packaging" [1]
Below is a full test version for convenience [2]
Please direct comments to [email-masked].
Best regards,

[1] http://www.w3.org/TR/2004/CR-xop10-20040826/#N103C0
[2]
MIME media type name:

     application
MIME subtype name:

     xop+xml
Required parameters:

     type

         This parameter conveys the content type associated with the XML 
serialization of the XOP infoset, including parameters as appropriate.

Optional parameters:

     charset

         This parameter has identical semantics to the charset parameter of 
the "application/xml" media type as specified in RFC 3023
     [RFC3023].

Encoding considerations:

     Identical to those of "application/xml" as described in RFC 3023 
[RFC3023], section 3.2.
Security considerations:

     In addition to application-specific considerations, XOP has the same 
security considerations described in RFC3023 [RFC3023], section 10.
Interoperability considerations:

     There are no known interoperability issues.
Published specification:

     This document
Applications which use this media type:

     No known applications currently use this media type.
Additional information:

     File extension:

         XOP
     Fragment identifiers:

         Identical to that of "application/xml" as described in RFC 3023 
[RFC3023], section 5.
     Base URI:

         As specified in RFC 3023 [RFC3023], section 6.
     Macintosh File Type code:

         TEXT

Person and email address to contact for further information:

     Mark Nottingham <[email-masked]>
Intended usage:

     COMMON
Author/Change controller:

     The XOP specification is a work product of the World Wide Web 
Consortium's XML Protocol Working Group. The W3C has change control over 
this specification.

-- 
Yves Lafon - W3C
"Baroula que barouleras, au ti?u toujou t'entourneras."
>From [email-masked]  Thu Sep  2 21:32:45 2004
From: Jeff.Hodges at KingsMountain.com ([email-masked])
Date: Thu Sep  2 21:32:51 2004
Subject: Please review: DRAFT Reg of application/samlassertion+xml 
In-Reply-To: Martin Duerst <[email-masked]> 's message of 
	Thu, 02 Sep 2004 13:45:53 +0900
Message-ID: <[email-masked]>

> At 09:06 04/09/01 -0700, [email-masked] wrote:
> 
> >For an overview of the intricities involved when a non-IETF organization
> >registers a MIME media type in the "standards tree" (aka "IETF tree"),
> >please see http://www.w3.org/2002/06/registering-mediatype.html.
> 
> 
> Please note that this page is written and intended only for media
> types from the W3C. This has been clarified in the title.
> It is mainly concerned about synchronizing the W3C Recommendation
> Process and the media type registration, and is based on discussion
> between W3C and IETF. Other organizations have different processes,
> and it is dangerous for them to base on the above document.

Your concern is appreciated, thanks. However, I do clearly say "overview", and 
I believe that your webpage is salient and worth investigating for those folks 
who are wearing hat(s) of non-IETF stds dvlp org(s) and wishing to register 
MIME media types, if only to use as a model for determining and documenting 
the process relative to their non-IETF org.

JeffH

From: duerst at w3.org (Martin Duerst)
Date: Tue Jan  3 16:22:46 2006
Subject: Please review: DRAFT Reg of application/samlassertion+xml
In-Reply-To: <[email-masked]>
Message-ID: <4.2.0.58.J.20040902134117.051301e8@localhost>

At 09:06 04/09/01 -0700, [email-masked] wrote:

>For an overview of the intricities involved when a non-IETF organization
>registers a MIME media type in the "standards tree" (aka "IETF tree"),
>please see http://www.w3.org/2002/06/registering-mediatype.html.

Please note that this page is written and intended only for media
types from the W3C. This has been clarified in the title.
It is mainly concerned about synchronizing the W3C Recommendation
Process and the media type registration, and is based on discussion
between W3C and IETF. Other organizations have different processes,
and it is dangerous for them to base on the above document.

Regards,    Martin.

From: Jeff.Hodges at KingsMountain.com ([email-masked])
Date: Wed Sep  1 18:11:01 2004
Subject: Please review: DRAFT Registration of application/samlmetadata+xml
Message-ID: <[email-masked]>

<NOTE:

Registration of MIME media type application/samlmetadata+xml
sstc-saml-2.0-application-samlmetadata-registration-00
Jeff Hodges <[email-masked]>
23-Aug-2004

This document is intended to be included in
sstc-saml-metadata-2.0-cd-02 (ie the next time [SAMLv2Meta] is
rev'd), as an appendix. Please refer to the bibliography below. 

Please see http://www.w3.org/2002/06/registering-mediatype.html for
an overview of the intricities involved when a non-IETF organization
registers a MIME media type in the "standards tree" (aka "IETF
tree").

The below registration material is intended to satisfy the
requirements stated in draft-freed-media-type-reg-01.txt (which
superseded draft-freed-mime-p4-04.txt).

This "NOTE" is intended to be removed upon copying this document's
content into [SAMLv2Meta].

Acknowledgments: Thanks to Ned Freed and Larry Masinter for their
comments on a draft of a related registration. The security
considerations section leverages that of
http://www.iana.org/assignments/media-types/application/vnd.paos+xml,
by John Kemp.

>

To: [email-masked]
Subject: Registration of MIME media type application/samlmetadata+xml

Introduction
      This document defines a MIME media type --
      application/samlmetadata+xml -- for use with the XML
      serialization of Security Assertion Markup Language metadata.

      SAML is a work product of the OASIS Security Services Technical
      Committee [SSTC]. The SAML specifications define XML-based
      constructs with which one may make, and convey, security
      assertions. Using SAML, one can assert that an authentication
      event pertaining to some subject has occurred and convey said
      assertion to a relying party, for example.

      SAML profiles require agreements between system entities
      regarding identifiers, binding support, endpoints, certificates,
      keys, and so forth. Such information is treated as metadata by
      SAML v2.0. [SAMLv2Meta] specifies this metadata, as well as
      specifying metadata publication and resolution mechanisms. If
      the publishing protocol permits MIME-based identification of
      content types, then use of the application/samlmetadata+xml MIME
      media type is required.

MIME media type name: application

MIME subtype name: samlmetadata+xml

Required parameters: none

Optional parameters: charset
      Same as charset parameter of application/xml [RFC3023].

Encoding considerations:
      Same as for application/xml [RFC3023].

Security considerations:
      Per their specification, samlmetadata+xml typed objects do not
      contain executable content. However, these objects are XML-based
      [XML], and thus they have all of the general security
      considerations presented in section 10 of [RFC3023].

      SAML metadata [SAMLv2Meta] contains information whose integrity
      and authenticity is important – identity provider and service
      provider public keys and endpoint addresses, for example.

      To counter potential issues, the publisher may sign
      samlmetadata+xml typed objects. Any such signature should be
      verified by the recipient of the data - both as a valid
      signature, and as being the signature of the publisher.

      Additionally, various of the publication protocols, e.g.
      HTTP-over-TLS/SSL, offer means for ensuring the authenticity of
      the publishing party and for protecting the metadata in transit.
      [SAMLv2Meta] also defines prescriptive metadata caching
      directives, as well as guidance on handling HTTPS redirects,
      trust processing, server authentication, and related items.

      For a more detailed discussion of SAML v2.0 metadata and its
      security considerations, please see [SAMLv2Meta]. For a
      discussion of overall SAML v2.0 security considerations and
      specific security-related design features, please refer to the
      SAML v2.0 specifications listed in the below bibliography. The
      specifications containing security-specific information are
      explicitly listed.

Interoperability considerations:
      SAML v2.0 metadata explicitly supports identifying the protocols
      and versions supported by the identified entities. For example,
      an identity provider entity can be denoted as supporting SAML
      v2.0, SAML v1.1 [SAMLv1.1], Liberty ID-FF 1.2 [LAPFF], or even
      other protocols if they are unambiguously identifiable via URI
      [RFC2396]. This protocol support information is conveyed via the
      protocolSupportEnumeration attribute of metadata objects of the
      RoleDescriptorType.

Published specification:
      [SAMLv2Meta] explicitly specifies use of the
      application/samlmetadata+xml MIME media type.

Applications which use this media type:
      Potentially any application implementing SAML v2.0, as well as
      those applications implementing specifications based on SAML,
      e.g. those available from the Liberty Alliance [LAP].

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 one of <md:EntityDescriptor>,
           <md:AffiliationDescriptor>, or <md:EntitiesDescriptor>.
           where "md" maps to the SAML v2.0 metadata namespace:
           urn:oasis:names:tc:SAML:2.0:metadata

      File extension(s): none
      Macintosh File Type Code(s): none

Person & email address to contact for further information:
      This registration is made on behalf of the OASIS Security
      Services Technical Committee (SSTC) Please refer to the SSTC
      website for current information on committee chairperson(s) and
      their contact addresses:
      http://www.oasis-open.org/committees/security/. Committee
      members should submit comments and potential errata to the
      [email-masked] list. Others should submit
      them by filling out the web form located at
      http://www.oasis-open.org/committees/comments/form.php?wg_abbrev=s

      Additionally, the SAML developer community email distribution
      list, [email-masked], may be employed to discuss
      usage of the application/samlmetadata+xml MIME media type. The
      "saml-dev" mailing list is publicly archived here:
      http://lists.oasis-open.org/archives/saml-dev/. To post to the
      "saml-dev" mailing list, one must subscribe to it. To subscribe,
      send a message with the single word "subscribe" in the message
      body, to: [email-masked].

Intended usage: COMMON

Author/Change controller:
      The SAML specification sets are a work product of the OASIS
      Security Services Technical Committee (SSTC). OASIS and the SSTC
      have change control over the SAML specification sets.

Bibliography

      [LAP]          "Liberty Alliance Project". See
                     http://www.projectliberty.org/

      [LAPFF]        "Liberty Alliance Project: Federation Framework".
                     See http://www.projectliberty.org/resources/
                     specifications.php#box1

      [OASIS]        "Organization for the Advancement of Structured
                     Information Systems". See
                     http://www.oasis-open.org/

      [RFC2396]      T. Berners-Lee, R. Fielding, L. Masinter, Uniform
                     Resource Identifiers (URI): Generic Syntax. IETF
                     RFC 2396, August 1998. Available at
                     http://www.ietf.org/rfc/rfc2396.txt

      [RFC3023]      M. Murata, S. St.Laurent, D. Kohn, "XML Media Types",
                     IETF Request for Comments 3023, January 2001.
                     Available as
                     http://www.rfc-editor.org/rfc/rfc3023.txt

      [SAMLv1.1]     OASIS Security Services Technical Committee,
                     "Security Assertion Markup Language (SAML)
                     Version 1.1 Specification Set". OASIS Standard
                     200308, August 2003. Available as
                     http://www.oasis-open.org/committees/download.php
                     /3400/oasis-sstc-saml-1.1-pdf-xsd.zip

      [SAMLv2.0]     OASIS Security Services Technical Committee,
                     "Security Assertion Markup Language (SAML)
                     Version 2.0 Specification Set". WORK IN PROGRESS.
                     Available at
                     http://www.oasis-open.org/committees/security/

      [SAMLv2Bind]   S. Cantor et al., "Bindings for the OASIS Security
                     Assertion Markup Language (SAML) V2.0". OASIS
                     SSTC, August 2004. Document ID
                     sstc-saml-bindings-2.0-cd-01, WORK IN PROGRESS.
                     See
                     http://www.oasis-open.org/committees/security/

      [SAMLv2Core]   S. Cantor et al., "Assertions and Protocols for the
                     OASIS Security Assertion Markup Language (SAML)
                     V2.0". OASIS SSTC, August 2004. Document ID
                     sstc-saml-core-2.0-cd-01, WORK IN PROGRESS. See
                     http://www.oasis-open.org/committees/security/

      [SAMLv2Meta]   S. Cantor et al., Metadata for the OASIS Security
                     Assertion Markup Language (SAML) V2.0. OASIS
                     SSTC, August 2004. Document ID
                     sstc-saml-metadata-2.0-cd-01. See
                     http://www.oasis-open.org/committees/security/

      [SAMLv2Prof]   S. Cantor et al., "Profiles for the OASIS Security
                     Assertion Markup Language (SAML) V2.0". OASIS
                     SSTC, August 2004. Document ID
                     sstc-saml-profiles-2.0-cd-01, WORK IN PROGRESS.
                     See
                     http://www.oasis-open.org/committees/security/

      [SAMLv2Sec]    F. Hirsch et al., "Security and Privacy
                     Considerations for the OASIS Security Assertion
                     Markup Language (SAML) V2.0". OASIS SSTC, August
                     2004, WORK IN PROGRESS. Document ID
                     sstc-saml-sec-consider-2.0-cd-01. See
                     http://www.oasis-open.org/committees/security/

      [SSTC]         "OASIS Security Services Technical Committee". See
                     http://www.oasis-open.org/committees/security/

      [XML]          Bray, T., Paoli, J., Sperberg-McQueen, C.M. and E. Maler,
                     "Extensible Markup Language (XML) 1.0 (Second
                     Edition)", World Wide Web Consortium
                     Recommendation REC-xml, October 2000, Available
                     as http://www.w3.org/TR/REC-xml

---
end

From: Jeff.Hodges at KingsMountain.com ([email-masked])
Date: Tue Jan  3 16:22:46 2006
Subject: Please review: DRAFT Registration of application/samlmetadata+xml
Message-ID: <[email-masked]>

<NOTE:

Registration of MIME media type application/samlmetadata+xml
sstc-saml-2.0-application-samlmetadata-registration-00
Jeff Hodges <[email-masked]>
23-Aug-2004

This document is intended to be included in
sstc-saml-metadata-2.0-cd-02 (ie the next time [SAMLv2Meta] is
rev'd), as an appendix. Please refer to the bibliography below. 

Please see http://www.w3.org/2002/06/registering-mediatype.html for
an overview of the intricities involved when a non-IETF organization
registers a MIME media type in the "standards tree" (aka "IETF
tree").

The below registration material is intended to satisfy the
requirements stated in draft-freed-media-type-reg-01.txt (which
superseded draft-freed-mime-p4-04.txt).

This "NOTE" is intended to be removed upon copying this document's
content into [SAMLv2Meta].

Acknowledgments: Thanks to Ned Freed and Larry Masinter for their
comments on a draft of a related registration. The security
considerations section leverages that of
http://www.iana.org/assignments/media-types/application/vnd.paos+xml,
by John Kemp.

>

To: [email-masked]
Subject: Registration of MIME media type application/samlmetadata+xml

Introduction
      This document defines a MIME media type --
      application/samlmetadata+xml -- for use with the XML
      serialization of Security Assertion Markup Language metadata.

      SAML is a work product of the OASIS Security Services Technical
      Committee [SSTC]. The SAML specifications define XML-based
      constructs with which one may make, and convey, security
      assertions. Using SAML, one can assert that an authentication
      event pertaining to some subject has occurred and convey said
      assertion to a relying party, for example.

      SAML profiles require agreements between system entities
      regarding identifiers, binding support, endpoints, certificates,
      keys, and so forth. Such information is treated as metadata by
      SAML v2.0. [SAMLv2Meta] specifies this metadata, as well as
      specifying metadata publication and resolution mechanisms. If
      the publishing protocol permits MIME-based identification of
      content types, then use of the application/samlmetadata+xml MIME
      media type is required.

MIME media type name: application

MIME subtype name: samlmetadata+xml

Required parameters: none

Optional parameters: charset
      Same as charset parameter of application/xml [RFC3023].

Encoding considerations:
      Same as for application/xml [RFC3023].

Security considerations:
      Per their specification, samlmetadata+xml typed objects do not
      contain executable content. However, these objects are XML-based
      [XML], and thus they have all of the general security
      considerations presented in section 10 of [RFC3023].

      SAML metadata [SAMLv2Meta] contains information whose integrity
      and authenticity is important – identity provider and service
      provider public keys and endpoint addresses, for example.

      To counter potential issues, the publisher may sign
      samlmetadata+xml typed objects. Any such signature should be
      verified by the recipient of the data - both as a valid
      signature, and as being the signature of the publisher.

      Additionally, various of the publication protocols, e.g.
      HTTP-over-TLS/SSL, offer means for ensuring the authenticity of
      the publishing party and for protecting the metadata in transit.
      [SAMLv2Meta] also defines prescriptive metadata caching
      directives, as well as guidance on handling HTTPS redirects,
      trust processing, server authentication, and related items.

      For a more detailed discussion of SAML v2.0 metadata and its
      security considerations, please see [SAMLv2Meta]. For a
      discussion of overall SAML v2.0 security considerations and
      specific security-related design features, please refer to the
      SAML v2.0 specifications listed in the below bibliography. The
      specifications containing security-specific information are
      explicitly listed.

Interoperability considerations:
      SAML v2.0 metadata explicitly supports identifying the protocols
      and versions supported by the identified entities. For example,
      an identity provider entity can be denoted as supporting SAML
      v2.0, SAML v1.1 [SAMLv1.1], Liberty ID-FF 1.2 [LAPFF], or even
      other protocols if they are unambiguously identifiable via URI
      [RFC2396]. This protocol support information is conveyed via the
      protocolSupportEnumeration attribute of metadata objects of the
      RoleDescriptorType.

Published specification:
      [SAMLv2Meta] explicitly specifies use of the
      application/samlmetadata+xml MIME media type.

Applications which use this media type:
      Potentially any application implementing SAML v2.0, as well as
      those applications implementing specifications based on SAML,
      e.g. those available from the Liberty Alliance [LAP].

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 one of <md:EntityDescriptor>,
           <md:AffiliationDescriptor>, or <md:EntitiesDescriptor>.
           where "md" maps to the SAML v2.0 metadata namespace:
           urn:oasis:names:tc:SAML:2.0:metadata

      File extension(s): none
      Macintosh File Type Code(s): none

Person & email address to contact for further information:
      This registration is made on behalf of the OASIS Security
      Services Technical Committee (SSTC) Please refer to the SSTC
      website for current information on committee chairperson(s) and
      their contact addresses:
      http://www.oasis-open.org/committees/security/. Committee
      members should submit comments and potential errata to the
      [email-masked] list. Others should submit
      them by filling out the web form located at
      http://www.oasis-open.org/committees/comments/form.php?wg_abbrev=s

      Additionally, the SAML developer community email distribution
      list, [email-masked], may be employed to discuss
      usage of the application/samlmetadata+xml MIME media type. The
      "saml-dev" mailing list is publicly archived here:
      http://lists.oasis-open.org/archives/saml-dev/. To post to the
      "saml-dev" mailing list, one must subscribe to it. To subscribe,
      send a message with the single word "subscribe" in the message
      body, to: [email-masked].

Intended usage: COMMON

Author/Change controller:
      The SAML specification sets are a work product of the OASIS
      Security Services Technical Committee (SSTC). OASIS and the SSTC
      have change control over the SAML specification sets.

Bibliography

      [LAP]          "Liberty Alliance Project". See
                     http://www.projectliberty.org/

      [LAPFF]        "Liberty Alliance Project: Federation Framework".
                     See http://www.projectliberty.org/resources/
                     specifications.php#box1

      [OASIS]        "Organization for the Advancement of Structured
                     Information Systems". See
                     http://www.oasis-open.org/

      [RFC2396]      T. Berners-Lee, R. Fielding, L. Masinter, Uniform
                     Resource Identifiers (URI): Generic Syntax. IETF
                     RFC 2396, August 1998. Available at
                     http://www.ietf.org/rfc/rfc2396.txt

      [RFC3023]      M. Murata, S. St.Laurent, D. Kohn, "XML Media Types",
                     IETF Request for Comments 3023, January 2001.
                     Available as
                     http://www.rfc-editor.org/rfc/rfc3023.txt

      [SAMLv1.1]     OASIS Security Services Technical Committee,
                     "Security Assertion Markup Language (SAML)
                     Version 1.1 Specification Set". OASIS Standard
                     200308, August 2003. Available as
                     http://www.oasis-open.org/committees/download.php
                     /3400/oasis-sstc-saml-1.1-pdf-xsd.zip

      [SAMLv2.0]     OASIS Security Services Technical Committee,
                     "Security Assertion Markup Language (SAML)
                     Version 2.0 Specification Set". WORK IN PROGRESS.
                     Available at
                     http://www.oasis-open.org/committees/security/

      [SAMLv2Bind]   S. Cantor et al., "Bindings for the OASIS Security
                     Assertion Markup Language (SAML) V2.0". OASIS
                     SSTC, August 2004. Document ID
                     sstc-saml-bindings-2.0-cd-01, WORK IN PROGRESS.
                     See
                     http://www.oasis-open.org/committees/security/

      [SAMLv2Core]   S. Cantor et al., "Assertions and Protocols for the
                     OASIS Security Assertion Markup Language (SAML)
                     V2.0". OASIS SSTC, August 2004. Document ID
                     sstc-saml-core-2.0-cd-01, WORK IN PROGRESS. See
                     http://www.oasis-open.org/committees/security/

      [SAMLv2Meta]   S. Cantor et al., Metadata for the OASIS Security
                     Assertion Markup Language (SAML) V2.0. OASIS
                     SSTC, August 2004. Document ID
                     sstc-saml-metadata-2.0-cd-01. See
                     http://www.oasis-open.org/committees/security/

      [SAMLv2Prof]   S. Cantor et al., "Profiles for the OASIS Security
                     Assertion Markup Language (SAML) V2.0". OASIS
                     SSTC, August 2004. Document ID
                     sstc-saml-profiles-2.0-cd-01, WORK IN PROGRESS.
                     See
                     http://www.oasis-open.org/committees/security/

      [SAMLv2Sec]    F. Hirsch et al., "Security and Privacy
                     Considerations for the OASIS Security Assertion
                     Markup Language (SAML) V2.0". OASIS SSTC, August
                     2004, WORK IN PROGRESS. Document ID
                     sstc-saml-sec-consider-2.0-cd-01. See
                     http://www.oasis-open.org/committees/security/

      [SSTC]         "OASIS Security Services Technical Committee". See
                     http://www.oasis-open.org/committees/security/

      [XML]          Bray, T., Paoli, J., Sperberg-McQueen, C.M. and E. Maler,
                     "Extensible Markup Language (XML) 1.0 (Second
                     Edition)", World Wide Web Consortium
                     Recommendation REC-xml, October 2000, Available
                     as http://www.w3.org/TR/REC-xml

---
end

From: Jeff.Hodges at KingsMountain.com ([email-masked])
Date: Wed Sep  1 18:07:00 2004
Subject: Please review: DRAFT Reg of application/samlassertion+xml
Message-ID: <[email-masked]>

<NOTE:

Registration of MIME media type application/samlassertion+xml
sstc-saml-2.0-application-samlassertion-registration-00
Jeff Hodges <[email-masked]>
21-Aug-2004

This document supersedes draft-hodges-saml-mediatype-02.txt. It
is intended to be included in sstc-saml-bindings-2.0-cd-02 (ie the next
time [SAMLv2Bind] is rev'd) as an appendix. Please refer to the bibliography 
below.

For an overview of the intricities involved when a non-IETF organization
registers a MIME media type in the "standards tree" (aka "IETF tree"),
please see http://www.w3.org/2002/06/registering-mediatype.html.

The below registration material is intended to satisfy the requirements
stated in draft-freed-media-type-reg-01.txt (which supersedes
draft-freed-mime-p4-04.txt).

This "NOTE" is intended to be removed upon copying this document's
content into [SAMLv2Bind].

Acknowledgments: Thanks to Ned Freed and Larry Masinter for their
comments on a prior draft of this registration. The security
considerations section leverages that of
http://www.iana.org/assignments/media-types/application/vnd.paos+xml, by
John Kemp.

>

To: [email-masked]
Subject: Registration of MIME media type application/samlassertion+xml

Introduction
      This document defines a MIME media type --
      application/samlassertion+xml -- for use with the XML serialization
      of SAML (Security Assertion Markup Language) assertions.

      The SAML specification sets -- [SAMLv1.0], [SAMLv1.1], [SAMLv2.0] --
      are work products of the OASIS Security Services Technical Committee
      [SSTC]. The SAML specifications define XML-based constructs with
      which one may make, and convey, security assertions. Using SAML, one
      can assert that an authentication event pertaining to some subject
      has occured and convey said assertion to a relying party, for
      example.

      SAML assertions, which are explicitly versioned, are defined by
      [SAMLv1Core], [SAMLv11Core], and [SAMLv2Core].

MIME media type name: application

MIME subtype name: samlassertion+xml

Required parameters: none

Optional parameters: charset
      Same as charset parameter of application/xml [RFC3023].

Encoding considerations:
      Same as for application/xml [RFC3023].

Security considerations:
      Per their specification, samlassertion+xml typed objects do not
      contain executable content. However, SAML assertions are XML-based
      objects [XML]. As such, they have all of the general security
      considerations presented in section 10 of [RFC3023], as well as
      additional ones, since they are explicit security objects. For
      example, samlassertion+xml typed objects will often contain data
      that may identify or pertain to a natural person, and may be used as
      a basis for sessions and access control decisions.

      To counter potential issues, samlassertion+xml typed objects contain
      data that should be signed appropriately by the sender. Any such
      signature must be verified by the recipient of the data - both as a
      valid signature, and as being the signature of the sender. Issuers
      of samlassertion+xml objects containing SAMLv2 assertions may also
      encrypt all, or portions of, the assertions [SAMLv2Core].

      In addition, SAML profiles and protocol bindings specify use of
      secure channels as appropriate.

      [SAMLv2.0] incorporates various privacy-protection techniques in its
      design. For example: opaque handles, specific to interactions
      between specific system entities, are assigned to subjects. The
      handles are mappable to wider-context identifiers (e.g. email
      addresses, account identifiers, etc) by only the specific parties.

      For a more detailed discussion of SAML security considerations and
      specific security-related design techniques, please refer to the
      SAML specifications listed in the below bibliography. The
      specifications containing security-specific information have been
      explicitly listed for each version of SAML.

Interoperability considerations:
      SAML assertions are explicitly versioned. Relying parties should
      ensure that they observe assertion version information and behave
      accordingly. See "Chapter 4 SAML Versioning" in [SAMLv1Core],
      [SAMLv11Core], or [SAMLv2Core], as appropriate.

Published specification:
      [SAMLv2Bind] explicitly specifies use of the
      application/samlassertion+xml MIME media type. However, it is
      conceivable that non-SAMLv2 assertions (i.e. SAMLv1 and/or SAMLv1.1)
      might in practice be conveyed using SAMLv2 bindings.

Applications which use this media type:
      Potentially any application implementing SAML, as well as those
      applications implementing specifications based on SAML, e.g. those
      available from the Liberty Alliance [LAP].

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" maps to a version-specific SAML
           assertion namespace, 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"
           maps to the SAMLv2.0 assertion namespace:
           urn:oasis:names:tc:SAML:2.0:assertion

      File extension(s): none
      Macintosh File Type Code(s): none

Person & email address to contact for further information:
      This registration is made on behalf of the OASIS Security Services
      Technical Committee (SSTC) Please refer to the SSTC website for
      current information on committee chairperson(s) and their contact
      addresses: http://www.oasis-open.org/committees/security/. Committee
      members should submit comments and potential errata to the
      [email-masked] list. Others should submit
      them by filling out the web form located at
      http://www.oasis-open.org/committees/comments/form.php?wg_abbrev=secur

      Additionally, the SAML developer community email distribution list,
      [email-masked], may be employed to discuss usage of
      the application/samlassertion+xml MIME media type. The "saml-dev"
      mailing list is publicly archived here:
      http://lists.oasis-open.org/archives/saml-dev/. To post to the
      "saml-dev" mailing list, one must subscribe to it. To subscribe,
      send a message with the single word "subscribe" in the message body,
      to: [email-masked].

Intended usage: COMMON

Author/Change controller:
      The SAML specification sets are a work product of the OASIS Security
      Services Technical Committee (SSTC). OASIS and the SSTC have change
      control over the SAML specification sets.

Bibliography

      [LAP]          "Liberty Alliance Project". See
                     http://www.projectliberty.org/

      [OASIS]        "Organization for the Advancement of Structured
                     Information Systems". See http://www.oasis-open.org/

      [RFC3023]      M. Murata, S. St.Laurent, D. Kohn, "XML Media Types",
                     IETF Request for Comments 3023, January 2001. Available
                     as http://www.rfc-editor.org/rfc/rfc3023.txt

      [SAMLv1.0]     OASIS Security Services Technical Committee, "Security
                     Assertion Markup Language (SAML) Version 1.0
                     Specification Set". OASIS Standard 200205, November
                     2002. Available as
                     http://www.oasis-open.org/committees/download.php/2290/
                     oasis-sstc-saml-1.0.zip

      [SAMLv1Bind]   Prateek Mishra et al., "Bindings and Profiles for the
                     OASIS Security Assertion Markup Language (SAML)",
                     OASIS, November 2002. Document ID
                     oasis-sstc-saml-bindings-1.0. See
                     http://www.oasis-open.org/committees/security/

      [SAMLv1Core]   Phillip Hallam-Baker et al., "Assertions and Protocol
                     for the OASIS Security Assertion Markup Language
                     (SAML)", OASIS, November 2002. Document ID
                     oasis-sstc-saml-core-1.0. See
                     http://www.oasis-open.org/committees/security/

      [SAMLv1Sec]    Chris McLaren et al., "Security Considerations for the
                     OASIS Security Assertion Markup Language (SAML)",
                     OASIS, November 2002. Document ID
                     oasis-sstc-saml-sec-consider-1.0. See
                     http://www.oasis-open.org/committees/security/

      [SAMLv1.1]     OASIS Security Services Technical Committee, "Security
                     Assertion Markup Language (SAML) Version 1.1
                     Specification Set". OASIS Standard 200308, August
                     2003. Available as
                     http://www.oasis-open.org/committees/download.php/3400/
                     oasis-sstc-saml-1.1-pdf-xsd.zip

      [SAMLv11Bind]  E. Maler et al. "Bindings and Profiles for the OASIS
                     Security Assertion Markup Language (SAML)". OASIS,
                     September 2003. Document ID
                     oasis-sstc-saml-bindings-1.1.
                     http://www.oasis-open.org/committees/security/

      [SAMLv11Core]  E. Maler et al. "Assertions and Protocol for the OASIS
                     Security Assertion Markup Language (SAML)". OASIS,
                     September 2003. Document ID oasis-sstc-saml-core-1.1.
                     http://www.oasis-open.org/committees/security/

      [SAMLv11Sec]   E. Maler et al. "Security Considerations for the OASIS
                     Security Assertion Markup Language (SAML)". OASIS,
                     September 2003. Document ID
                     oasis-sstc-saml-sec-consider-1.1.
                     http://www.oasis-open.org/committees/security/

      [SAMLv2.0]     OASIS Security Services Technical Committee, "Security
                     Assertion Markup Language (SAML) Version 2.0
                     Specification Set". WORK IN PROGRESS. Available at
                     http://www.oasis-open.org/committees/security/

      [SAMLv2Bind]   S. Cantor et al., "Bindings for the OASIS Security
                     Assertion Markup Language (SAML) V2.0". OASIS SSTC,
                     August 2004. Document ID
                     sstc-saml-bindings-2.0-cd-01, WORK IN PROGRESS. See
                     http://www.oasis-open.org/committees/security/

      [SAMLv2Core]   S. Cantor et al., "Assertions and Protocols for the
                     OASIS Security Assertion Markup Language (SAML)
                     V2.0". OASIS SSTC, August 2004. Document ID
                     sstc-saml-core-2.0-cd-01, WORK IN PROGRESS. See
                     http://www.oasis-open.org/committees/security/

      [SAMLv2Prof]   S. Cantor et al., "Profiles for the OASIS Security
                     Assertion Markup Language (SAML) V2.0". OASIS SSTC,
                     August 2004. Document ID
                     sstc-saml-profiles-2.0-cd-01, WORK IN PROGRESS. See
                     http://www.oasis-open.org/committees/security/

      [SAMLv2Sec]    F. Hirsch et al., "Security and Privacy Considerations
                     for the OASIS Security Assertion Markup Language
                     (SAML) V2.0". OASIS SSTC, August 2004, WORK IN
                     PROGRESS. Document ID
                     sstc-saml-sec-consider-2.0-cd-01. See
                     http://www.oasis-open.org/committees/security/

      [SSTC]        "OASIS Security Services Technical Committee". See
                     http://www.oasis-open.org/committees/security/

      [XML]          Bray, T., Paoli, J., Sperberg-McQueen, C.M. and E. Maler,
                     "Extensible Markup Language (XML) 1.0 (Second
                     Edition)", World Wide Web Consortium Recommendation
                     REC-xml, October 2000, Available as
                     http://www.w3.org/TR/REC-xml

From: Jeff.Hodges at KingsMountain.com ([email-masked])
Date: Tue Jan  3 16:22:46 2006
Subject: Please review: DRAFT Reg of application/samlassertion+xml
Message-ID: <[email-masked]>

<NOTE:

Registration of MIME media type application/samlassertion+xml
sstc-saml-2.0-application-samlassertion-registration-00
Jeff Hodges <[email-masked]>
21-Aug-2004

This document supersedes draft-hodges-saml-mediatype-02.txt. It
is intended to be included in sstc-saml-bindings-2.0-cd-02 (ie the next
time [SAMLv2Bind] is rev'd) as an appendix. Please refer to the bibliography 
below.

For an overview of the intricities involved when a non-IETF organization
registers a MIME media type in the "standards tree" (aka "IETF tree"),
please see http://www.w3.org/2002/06/registering-mediatype.html.

The below registration material is intended to satisfy the requirements
stated in draft-freed-media-type-reg-01.txt (which supersedes
draft-freed-mime-p4-04.txt).

This "NOTE" is intended to be removed upon copying this document's
content into [SAMLv2Bind].

Acknowledgments: Thanks to Ned Freed and Larry Masinter for their
comments on a prior draft of this registration. The security
considerations section leverages that of
http://www.iana.org/assignments/media-types/application/vnd.paos+xml, by
John Kemp.

>

To: [email-masked]
Subject: Registration of MIME media type application/samlassertion+xml

Introduction
      This document defines a MIME media type --
      application/samlassertion+xml -- for use with the XML serialization
      of SAML (Security Assertion Markup Language) assertions.

      The SAML specification sets -- [SAMLv1.0], [SAMLv1.1], [SAMLv2.0] --
      are work products of the OASIS Security Services Technical Committee
      [SSTC]. The SAML specifications define XML-based constructs with
      which one may make, and convey, security assertions. Using SAML, one
      can assert that an authentication event pertaining to some subject
      has occured and convey said assertion to a relying party, for
      example.

      SAML assertions, which are explicitly versioned, are defined by
      [SAMLv1Core], [SAMLv11Core], and [SAMLv2Core].

MIME media type name: application

MIME subtype name: samlassertion+xml

Required parameters: none

Optional parameters: charset
      Same as charset parameter of application/xml [RFC3023].

Encoding considerations:
      Same as for application/xml [RFC3023].

Security considerations:
      Per their specification, samlassertion+xml typed objects do not
      contain executable content. However, SAML assertions are XML-based
      objects [XML]. As such, they have all of the general security
      considerations presented in section 10 of [RFC3023], as well as
      additional ones, since they are explicit security objects. For
      example, samlassertion+xml typed objects will often contain data
      that may identify or pertain to a natural person, and may be used as
      a basis for sessions and access control decisions.

      To counter potential issues, samlassertion+xml typed objects contain
      data that should be signed appropriately by the sender. Any such
      signature must be verified by the recipient of the data - both as a
      valid signature, and as being the signature of the sender. Issuers
      of samlassertion+xml objects containing SAMLv2 assertions may also
      encrypt all, or portions of, the assertions [SAMLv2Core].

      In addition, SAML profiles and protocol bindings specify use of
      secure channels as appropriate.

      [SAMLv2.0] incorporates various privacy-protection techniques in its
      design. For example: opaque handles, specific to interactions
      between specific system entities, are assigned to subjects. The
      handles are mappable to wider-context identifiers (e.g. email
      addresses, account identifiers, etc) by only the specific parties.

      For a more detailed discussion of SAML security considerations and
      specific security-related design techniques, please refer to the
      SAML specifications listed in the below bibliography. The
      specifications containing security-specific information have been
      explicitly listed for each version of SAML.

Interoperability considerations:
      SAML assertions are explicitly versioned. Relying parties should
      ensure that they observe assertion version information and behave
      accordingly. See "Chapter 4 SAML Versioning" in [SAMLv1Core],
      [SAMLv11Core], or [SAMLv2Core], as appropriate.

Published specification:
      [SAMLv2Bind] explicitly specifies use of the
      application/samlassertion+xml MIME media type. However, it is
      conceivable that non-SAMLv2 assertions (i.e. SAMLv1 and/or SAMLv1.1)
      might in practice be conveyed using SAMLv2 bindings.

Applications which use this media type:
      Potentially any application implementing SAML, as well as those
      applications implementing specifications based on SAML, e.g. those
      available from the Liberty Alliance [LAP].

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" maps to a version-specific SAML
           assertion namespace, 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"
           maps to the SAMLv2.0 assertion namespace:
           urn:oasis:names:tc:SAML:2.0:assertion

      File extension(s): none
      Macintosh File Type Code(s): none

Person & email address to contact for further information:
      This registration is made on behalf of the OASIS Security Services
      Technical Committee (SSTC) Please refer to the SSTC website for
      current information on committee chairperson(s) and their contact
      addresses: http://www.oasis-open.org/committees/security/. Committee
      members should submit comments and potential errata to the
      [email-masked] list. Others should submit
      them by filling out the web form located at
      http://www.oasis-open.org/committees/comments/form.php?wg_abbrev=secur

      Additionally, the SAML developer community email distribution list,
      [email-masked], may be employed to discuss usage of
      the application/samlassertion+xml MIME media type. The "saml-dev"
      mailing list is publicly archived here:
      http://lists.oasis-open.org/archives/saml-dev/. To post to the
      "saml-dev" mailing list, one must subscribe to it. To subscribe,
      send a message with the single word "subscribe" in the message body,
      to: [email-masked].

Intended usage: COMMON

Author/Change controller:
      The SAML specification sets are a work product of the OASIS Security
      Services Technical Committee (SSTC). OASIS and the SSTC have change
      control over the SAML specification sets.

Bibliography

      [LAP]          "Liberty Alliance Project". See
                     http://www.projectliberty.org/

      [OASIS]        "Organization for the Advancement of Structured
                     Information Systems". See http://www.oasis-open.org/

      [RFC3023]      M. Murata, S. St.Laurent, D. Kohn, "XML Media Types",
                     IETF Request for Comments 3023, January 2001. Available
                     as http://www.rfc-editor.org/rfc/rfc3023.txt

      [SAMLv1.0]     OASIS Security Services Technical Committee, "Security
                     Assertion Markup Language (SAML) Version 1.0
                     Specification Set". OASIS Standard 200205, November
                     2002. Available as
                     http://www.oasis-open.org/committees/download.php/2290/
                     oasis-sstc-saml-1.0.zip

      [SAMLv1Bind]   Prateek Mishra et al., "Bindings and Profiles for the
                     OASIS Security Assertion Markup Language (SAML)",
                     OASIS, November 2002. Document ID
                     oasis-sstc-saml-bindings-1.0. See
                     http://www.oasis-open.org/committees/security/

      [SAMLv1Core]   Phillip Hallam-Baker et al., "Assertions and Protocol
                     for the OASIS Security Assertion Markup Language
                     (SAML)", OASIS, November 2002. Document ID
                     oasis-sstc-saml-core-1.0. See
                     http://www.oasis-open.org/committees/security/

      [SAMLv1Sec]    Chris McLaren et al., "Security Considerations for the
                     OASIS Security Assertion Markup Language (SAML)",
                     OASIS, November 2002. Document ID
                     oasis-sstc-saml-sec-consider-1.0. See
                     http://www.oasis-open.org/committees/security/

      [SAMLv1.1]     OASIS Security Services Technical Committee, "Security
                     Assertion Markup Language (SAML) Version 1.1
                     Specification Set". OASIS Standard 200308, August
                     2003. Available as
                     http://www.oasis-open.org/committees/download.php/3400/
                     oasis-sstc-saml-1.1-pdf-xsd.zip

      [SAMLv11Bind]  E. Maler et al. "Bindings and Profiles for the OASIS
                     Security Assertion Markup Language (SAML)". OASIS,
                     September 2003. Document ID
                     oasis-sstc-saml-bindings-1.1.
                     http://www.oasis-open.org/committees/security/

      [SAMLv11Core]  E. Maler et al. "Assertions and Protocol for the OASIS
                     Security Assertion Markup Language (SAML)". OASIS,
                     September 2003. Document ID oasis-sstc-saml-core-1.1.
                     http://www.oasis-open.org/committees/security/

      [SAMLv11Sec]   E. Maler et al. "Security Considerations for the OASIS
                     Security Assertion Markup Language (SAML)". OASIS,
                     September 2003. Document ID
                     oasis-sstc-saml-sec-consider-1.1.
                     http://www.oasis-open.org/committees/security/

      [SAMLv2.0]     OASIS Security Services Technical Committee, "Security
                     Assertion Markup Language (SAML) Version 2.0
                     Specification Set". WORK IN PROGRESS. Available at
                     http://www.oasis-open.org/committees/security/

      [SAMLv2Bind]   S. Cantor et al., "Bindings for the OASIS Security
                     Assertion Markup Language (SAML) V2.0". OASIS SSTC,
                     August 2004. Document ID
                     sstc-saml-bindings-2.0-cd-01, WORK IN PROGRESS. See
                     http://www.oasis-open.org/committees/security/

      [SAMLv2Core]   S. Cantor et al., "Assertions and Protocols for the
                     OASIS Security Assertion Markup Language (SAML)
                     V2.0". OASIS SSTC, August 2004. Document ID
                     sstc-saml-core-2.0-cd-01, WORK IN PROGRESS. See
                     http://www.oasis-open.org/committees/security/

      [SAMLv2Prof]   S. Cantor et al., "Profiles for the OASIS Security
                     Assertion Markup Language (SAML) V2.0". OASIS SSTC,
                     August 2004. Document ID
                     sstc-saml-profiles-2.0-cd-01, WORK IN PROGRESS. See
                     http://www.oasis-open.org/committees/security/

      [SAMLv2Sec]    F. Hirsch et al., "Security and Privacy Considerations
                     for the OASIS Security Assertion Markup Language
                     (SAML) V2.0". OASIS SSTC, August 2004, WORK IN
                     PROGRESS. Document ID
                     sstc-saml-sec-consider-2.0-cd-01. See
                     http://www.oasis-open.org/committees/security/

      [SSTC]        "OASIS Security Services Technical Committee". See
                     http://www.oasis-open.org/committees/security/

      [XML]          Bray, T., Paoli, J., Sperberg-McQueen, C.M. and E. Maler,
                     "Extensible Markup Language (XML) 1.0 (Second
                     Edition)", World Wide Web Consortium Recommendation
                     REC-xml, October 2000, Available as
                     http://www.w3.org/TR/REC-xml

From: duerst at w3.org (Martin Duerst)
Date: Wed Sep  1 03:20:30 2004
Subject: draft-freed-mime-p4-04 is apparently superseded by..
In-Reply-To: <[email-masked]>
References: <"Your message dated Tue, 24 Aug 2004 09:58:15 -0700" <[email-masked]> <[email-masked]> <[email-masked]>
Message-ID: <4.2.0.58.J.20040901095413.02b35558@localhost>

Hello Ned,

Many thanks for your clarifications.

Is there anything we can do to move draft-freed-media-type-reg-01.txt forward?
You say that it will got to last call 'once it has been determined that
the various issues have been dealt with in a satisfactory way'. Who will
make this determination, and when?

Also, you refer to some concerns regarding text/red and related
types. Can you provide pointers to these discussions? (You refer
to the change log in draft-freed-media-type-reg-01.txt, and I
have looked though it, but it is not clear which changes are
related to the text/red concerns, and which changes are separate.)

Regards,    Martin.

At 17:13 04/08/28 -0700, [email-masked] wrote:
> > I didn't see a LAST CALL or a Protocol Action
>
> > http://www1.ietf.org/mail-archive/web/ietf-announce/current/index.html
>
>Which document are you referring to? If you're talking about
>draft-freed-mime-p4-03.txt, it was last called on 29-Sep-2003. The 
>announcement
>of that last call was posted to the IETF list in the usual way. The document
>was finally approved by the IESG on 28-Jan-2004; again with the usual
>announcement sent to the IETF list.
>
>However, various concerns relating to the registration of the text/red and
>related media types as part of the AVT WG activities caused the IESG to
>withdraw the document from the RFC Editor queue so additional changes to the
>media type registration procedures section could be made. Additionally, I
>suggested, and the IESG agreed, that it would be best to tease the media types
>stuff out of the MIME document set at this point since media types are used in
>lots of places besides MIME.
>
>Accordingly, I have moved the specification of the media type 
>specification and
>registration procedures to another, separate document,
>draft-freed-media-type-reg-01.txt. (The additional changes that have been made
>in response to AVT needs are listed in the document's appendix.) I presume a
>new last call will be needed to advance this specification to BCP at some 
>point
>in the future once it has been determined that the various issues have been
>dealt with in a satisfactory way.
>
>In the meantime draft-freed-mime-p4-03.txt has gone back into the RFC Editor
>queue - an entirely reasonably thing to do IMO given that all the remaining
>stuff is unchanged from what was approved back in January.
>
>It is also my understanding that the IESG is currently following and will
>continue to follow the revised procedures for registrations in the standards
>tree that were specified in  draft-freed-mime-p4-02.txt. The AVT issues and
>resulting changes are orthogonal IMO.
>
>                                 Ned

From: duerst at w3.org (Martin Duerst)
Date: Tue Jan  3 16:22:46 2006
Subject: draft-freed-mime-p4-04 is apparently superseded by..
In-Reply-To: <[email-masked]>
References: <"Your message dated Tue, 24 Aug 2004 09:58:15 -0700" <[email-masked]> <[email-masked]> <[email-masked]>
Message-ID: <4.2.0.58.J.20040901095413.02b35558@localhost>

Hello Ned,

Many thanks for your clarifications.

Is there anything we can do to move draft-freed-media-type-reg-01.txt forward?
You say that it will got to last call 'once it has been determined that
the various issues have been dealt with in a satisfactory way'. Who will
make this determination, and when?

Also, you refer to some concerns regarding text/red and related
types. Can you provide pointers to these discussions? (You refer
to the change log in draft-freed-media-type-reg-01.txt, and I
have looked though it, but it is not clear which changes are
related to the text/red concerns, and which changes are separate.)

Regards,    Martin.

At 17:13 04/08/28 -0700, [email-masked] wrote:
> > I didn't see a LAST CALL or a Protocol Action
>
> > http://www1.ietf.org/mail-archive/web/ietf-announce/current/index.html
>
>Which document are you referring to? If you're talking about
>draft-freed-mime-p4-03.txt, it was last called on 29-Sep-2003. The 
>announcement
>of that last call was posted to the IETF list in the usual way. The document
>was finally approved by the IESG on 28-Jan-2004; again with the usual
>announcement sent to the IETF list.
>
>However, various concerns relating to the registration of the text/red and
>related media types as part of the AVT WG activities caused the IESG to
>withdraw the document from the RFC Editor queue so additional changes to the
>media type registration procedures section could be made. Additionally, I
>suggested, and the IESG agreed, that it would be best to tease the media types
>stuff out of the MIME document set at this point since media types are used in
>lots of places besides MIME.
>
>Accordingly, I have moved the specification of the media type 
>specification and
>registration procedures to another, separate document,
>draft-freed-media-type-reg-01.txt. (The additional changes that have been made
>in response to AVT needs are listed in the document's appendix.) I presume a
>new last call will be needed to advance this specification to BCP at some 
>point
>in the future once it has been determined that the various issues have been
>dealt with in a satisfactory way.
>
>In the meantime draft-freed-mime-p4-03.txt has gone back into the RFC Editor
>queue - an entirely reasonably thing to do IMO given that all the remaining
>stuff is unchanged from what was approved back in January.
>
>It is also my understanding that the IESG is currently following and will
>continue to follow the revised procedures for registrations in the standards
>tree that were specified in  draft-freed-mime-p4-02.txt. The AVT issues and
>resulting changes are orthogonal IMO.
>
>                                 Ned