For review: application/atom+xml

[distobj at acm.org (Mark Baker)]

[ CC: IESG, since I suppose this counts as a last call comment ]

Mark,

Congrats on going to last call with the atompub format! -

http://www.ietf.org/internet-drafts/draft-ietf-atompub-format-08.txt

But I note that my comment[1] on the lack of any mention of the existing
use of application/atom+xml with the incompatible Atom 0.3 content
didn't make it in.  Though not widespread, my understanding (though I'd
be happy to be corrected!), at least at the time that you first drew up
this media type[2], was that it was in use[3].  I certainly don't feel
that this is a big enough problem to warrant a new media type, but I do
think it should be flagged to implementors.

Also, I noticed something else that I missed my first time through ...

On Wed, Apr 06, 2005 at 08:41:08PM -0700, Mark Nottingham wrote:
>    Additional information:
> 
>    Magic number(s): As specified for "application/xml" in [RFC3023],
>       section 3.2.

Based on my understanding of the purpose of magic numbers, I think
referencing another spec's magic number algorithm to be prima facie
incorrect.  What I think should be there is information that, as
uniquely as possible, identifies Atom documents, and RFC 3023 can, of
course, only help with identifying XML documents.  So I'd suggest either
adding something about the root namespace value (if indeed the spec
requires that the root element always be from the Atom namespace?) as I
did for XHTML[4], or else just saying "Magic Number: None" (as we did
for SOAP[5], in effect, by not providing an algorithm).

Cheers,

 [1] http://eikenes.alvestrand.no/pipermail/ietf-types/2005-April/000678.html
 [2] http://www.mnot.net/drafts/draft-nottingham-atom-format-02.html
 [3] http://diveintomark.org/archives/2003/12/13/atom03
 [4] http://www.ietf.org/rfc/rfc3236.txt
 [5] http://www.ietf.org/rfc/rfc3902.txt

Mark.
-- 
Mark Baker.   Ottawa, Ontario, CANADA.        http://www.markbaker.ca
>From [e-mail]  Wed Apr 20 20:58:28 2005
From: blilly at erols.com (Bruce Lilly)
Date: Wed Apr 20 20:58:45 2005
Subject: regarding your comments on proposed media type text/troff' to
	Informational RFC
In-Reply-To: <[e-mail]>
References: <[e-mail]>
	<[e-mail]>
	<[e-mail]>
Message-ID: <[e-mail]>

On Tue April 19 2005 15:14, Keith Moore wrote:
> > You cited an out-of-context excerpt from RFC 2046 section 4.5.1
> > (Octet-Stream Subtype), which is not directly relevant:
> > 
> > 1. it concerns application software implementation issues rather than
> >    media type definitions, parameters, content, or registration
> > 
> > 2. it is specific to the application/octet-stream media subtype, which
> >    is in a completely different media type category.
> 
> I've already explained why the text is relevant despite the above.

I don't buy your explanation; it seems to be predicated on an assumption
that a certain vendor will attempt automatic interpretation of parameter
value content -- that vendor not being likely to want to support troff,
which is a direct competitor to said vendor's products.

> What I meant (as if you couldn't figure this out) is that it doesn't have
> to be defined the way you want it to be defined in order for the type to
> be useful.

Would you really be happier if it were defined as a strictly human-readable
text value?
 
> It is well established that email may be used to send executable content,
> but we try to discourage having ways that make it easy for the email
> reader to distinguish executable content from non-executable content
> and execute it.

Surely one would like to encourage, rather than discourage, easy
differentiation of executable and non-executable content.

> > Since the parameter is human-readable
> > information about the media type, *in* a parameter (which is not executable),
> 
> The purpose of content-type parameters is for machine interpretation rather 
> than human readability.

There is nothing in the core MIME RFCs or draft successors that requires
machine interpretation. RFC 2048 says "to convey additional information";
its draft successor uses the same phrase.  If a parameter is defined as
human-readable information, then the appropriate action for a UA is to
display the content to the user.

Each defined media type and subtype may specify any number of parameters,
and behavior is indicated by each specification.  A given parameter in a
given Content-Type field for a specified media type and subtype has to
be interpreted per the parameter specification for that subtype or type
(in the case of an inherited parameter). As noted in RFC 2045 "There are
NO globally-meaningful parameters that apply to all media types."
>From [e-mail]  Wed Apr 20 20:58:28 2005
From: blilly at erols.com (Bruce Lilly)
Date: Wed Apr 20 20:58:49 2005
Subject: regarding your comments on proposed media type text/troff' to
	Informational RFC
In-Reply-To: <[e-mail]>
References: <[e-mail]>
	<[e-mail]>
	<[e-mail]>
Message-ID: <[e-mail]>

On Tue April 19 2005 15:14, Keith Moore wrote:
> > You cited an out-of-context excerpt from RFC 2046 section 4.5.1
> > (Octet-Stream Subtype), which is not directly relevant:
> > 
> > 1. it concerns application software implementation issues rather than
> >    media type definitions, parameters, content, or registration
> > 
> > 2. it is specific to the application/octet-stream media subtype, which
> >    is in a completely different media type category.
> 
> I've already explained why the text is relevant despite the above.

I don't buy your explanation; it seems to be predicated on an assumption
that a certain vendor will attempt automatic interpretation of parameter
value content -- that vendor not being likely to want to support troff,
which is a direct competitor to said vendor's products.

> What I meant (as if you couldn't figure this out) is that it doesn't have
> to be defined the way you want it to be defined in order for the type to
> be useful.

Would you really be happier if it were defined as a strictly human-readable
text value?
 
> It is well established that email may be used to send executable content,
> but we try to discourage having ways that make it easy for the email
> reader to distinguish executable content from non-executable content
> and execute it.

Surely one would like to encourage, rather than discourage, easy
differentiation of executable and non-executable content.

> > Since the parameter is human-readable
> > information about the media type, *in* a parameter (which is not executable),
> 
> The purpose of content-type parameters is for machine interpretation rather 
> than human readability.

There is nothing in the core MIME RFCs or draft successors that requires
machine interpretation. RFC 2048 says "to convey additional information";
its draft successor uses the same phrase.  If a parameter is defined as
human-readable information, then the appropriate action for a UA is to
display the content to the user.

Each defined media type and subtype may specify any number of parameters,
and behavior is indicated by each specification.  A given parameter in a
given Content-Type field for a specified media type and subtype has to
be interpreted per the parameter specification for that subtype or type
(in the case of an inherited parameter). As noted in RFC 2045 "There are
NO globally-meaningful parameters that apply to all media types."
>From [e-mail]  Wed Apr 20 21:24:05 2005
From: tony at att.com (Tony Hansen)
Date: Wed Apr 20 21:24:22 2005
Subject: regarding your comments on proposed media type text/troff' to
 Informational RFC
In-Reply-To: <[e-mail]>
References: <[e-mail]>	<[e-mail]>	<[e-mail]>
	<[e-mail]>
Message-ID: <[e-mail]>

 From a process point of view, can we declare consensus on removing the 
process= parameter?

I see lots of arguments by lots of people against the process= 
parameter. Bruce, the author, is the only one who seems to be arguing 
for the parameter.

There seems to be consensus on the rest of the document moving forward 
essentially as written.

Bruce, would you be willing to declare that the skirmish was lost, but 
the battle won, and republish the document without the process= parameter?

	Tony Hansen
	[e-mail]
>From [e-mail]  Wed Apr 20 21:32:02 2005
From: blilly at erols.com (Bruce Lilly)
Date: Wed Apr 20 21:32:12 2005
Subject: regarding your comments on proposed media type
	text/troff'toInformational RFC
In-Reply-To: <[e-mail]>
References: <[e-mail]>
Message-ID: <[e-mail]>

On Tue April 19 2005 23:22, Larry Masinter wrote:

> You give, as your justification for having a process
> parameter for text/troff, the use case that the receiver
> might automatically determine whether remote content
> is processable, and avoid downloading content that it
> couldn't process.

I believe that I did not say "automatically".  I meant that a
human recipient could decide whether or not to retrieve content
based on information supplied.
 
> > See the issues regarding retrieval of sizable remote content.
> 
> However, this use case doesn't make any sense. If,
> as you assert, the receiver isn't going to automatically
> process the content anyway, but rely on a person to
> type in the process parameter after somehow verifying
> its safety, then there isn't generally a good ability
> to determine processability. After all, the user, if
> the user wants the content, may very will download
> and install the appropriate macro or processing capabilities.

Due to copyright issues, policy issues, economics, etc., a user might
be unable to install some resource.
 
> You're right that the problem with MIME parameters is
> general. In general, I think it's a bad idea to put
> information in MIME parameters that isn't absolutely
> necessary for automatic processing.

Surely you're not suggesting that a "filename" parameter should be
used in a purely automated manner (i.e. w/o at minimum user veto
power)?

> In general, users 
> *don't* have a file system with multiple text/plain files
> which differ by charset.

I can't speak for the general case, but most files that I generate are
in US-ASCII, a few in iso-8859-1, and a smaller number in other
charsets.  Those that I have in my file systems as obtained from other
sources are in a wide variety of charsets (utf-8, euc-kr, GB2312, utf-7,
etc.).
>From [e-mail]  Wed Apr 20 21:32:02 2005
From: blilly at erols.com (Bruce Lilly)
Date: Wed Apr 20 21:32:18 2005
Subject: regarding your comments on proposed media type
	text/troff'toInformational RFC
In-Reply-To: <[e-mail]>
References: <[e-mail]>
Message-ID: <[e-mail]>

On Tue April 19 2005 23:22, Larry Masinter wrote:

> You give, as your justification for having a process
> parameter for text/troff, the use case that the receiver
> might automatically determine whether remote content
> is processable, and avoid downloading content that it
> couldn't process.

I believe that I did not say "automatically".  I meant that a
human recipient could decide whether or not to retrieve content
based on information supplied.
 
> > See the issues regarding retrieval of sizable remote content.
> 
> However, this use case doesn't make any sense. If,
> as you assert, the receiver isn't going to automatically
> process the content anyway, but rely on a person to
> type in the process parameter after somehow verifying
> its safety, then there isn't generally a good ability
> to determine processability. After all, the user, if
> the user wants the content, may very will download
> and install the appropriate macro or processing capabilities.

Due to copyright issues, policy issues, economics, etc., a user might
be unable to install some resource.
 
> You're right that the problem with MIME parameters is
> general. In general, I think it's a bad idea to put
> information in MIME parameters that isn't absolutely
> necessary for automatic processing.

Surely you're not suggesting that a "filename" parameter should be
used in a purely automated manner (i.e. w/o at minimum user veto
power)?

> In general, users 
> *don't* have a file system with multiple text/plain files
> which differ by charset.

I can't speak for the general case, but most files that I generate are
in US-ASCII, a few in iso-8859-1, and a smaller number in other
charsets.  Those that I have in my file systems as obtained from other
sources are in a wide variety of charsets (utf-8, euc-kr, GB2312, utf-7,
etc.).
>From [e-mail]  Wed Apr 20 22:07:38 2005
From: moore at cs.utk.edu (Keith Moore)
Date: Wed Apr 20 22:07:45 2005
Subject: regarding your comments on proposed media type text/troff' to
 Informational RFC
In-Reply-To: <[e-mail]>
References: <[e-mail]>
	<[e-mail]>
	<[e-mail]>
	<[e-mail]>
Message-ID: <[e-mail]>

> On Tue April 19 2005 15:14, Keith Moore wrote:
> > > You cited an out-of-context excerpt from RFC 2046 section 4.5.1
> > > (Octet-Stream Subtype), which is not directly relevant:
> > > 
> > > 1. it concerns application software implementation issues rather than
> > >    media type definitions, parameters, content, or registration
> > > 
> > > 2. it is specific to the application/octet-stream media subtype, which
> > >    is in a completely different media type category.
> > 
> > I've already explained why the text is relevant despite the above.
> 
> I don't buy your explanation; it seems to be predicated on an assumption
> that a certain vendor will attempt automatic interpretation of parameter
> value content -- that vendor not being likely to want to support troff,
> which is a direct competitor to said vendor's products.

Your assumptions about my assumptions are incorrect.

> Would you really be happier if it were defined as a strictly human-readable
> text value?

If you defined it in such a way that it could say whatever it wanted to
a human (and not, say, as a command that the human was expected to type),
yes, that would be more acceptable.  Since parameters are rarely 
presented to humans, it wouldn't IMHO be very useful to have such a 
parameter.

> > It is well established that email may be used to send executable content,
> > but we try to discourage having ways that make it easy for the email
> > reader to distinguish executable content from non-executable content
> > and execute it.
> 
> Surely one would like to encourage, rather than discourage, easy
> differentiation of executable and non-executable content.

Not when you look at what actually happens in practice when you do that.

> > The purpose of content-type parameters is for machine interpretation rather 
> > than human readability.
> 
> There is nothing in the core MIME RFCs or draft successors that requires
> machine interpretation.

true.  

> If a parameter is defined as
> human-readable information, then the appropriate action for a UA is to
> display the content to the user.

It's not going to happen, as UAs don't special-case handling of most
content-types.  (now maybe the plugin for the content-type could 
display such content to the user, but that doesn't seem much more
likely given common practices).

Keith
>From [e-mail]  Wed Apr 20 22:07:38 2005
From: moore at cs.utk.edu (Keith Moore)
Date: Wed Apr 20 22:07:51 2005
Subject: regarding your comments on proposed media type text/troff' to
 Informational RFC
In-Reply-To: <[e-mail]>
References: <[e-mail]>
	<[e-mail]>
	<[e-mail]>
	<[e-mail]>
Message-ID: <[e-mail]>

> On Tue April 19 2005 15:14, Keith Moore wrote:
> > > You cited an out-of-context excerpt from RFC 2046 section 4.5.1
> > > (Octet-Stream Subtype), which is not directly relevant:
> > > 
> > > 1. it concerns application software implementation issues rather than
> > >    media type definitions, parameters, content, or registration
> > > 
> > > 2. it is specific to the application/octet-stream media subtype, which
> > >    is in a completely different media type category.
> > 
> > I've already explained why the text is relevant despite the above.
> 
> I don't buy your explanation; it seems to be predicated on an assumption
> that a certain vendor will attempt automatic interpretation of parameter
> value content -- that vendor not being likely to want to support troff,
> which is a direct competitor to said vendor's products.

Your assumptions about my assumptions are incorrect.

> Would you really be happier if it were defined as a strictly human-readable
> text value?

If you defined it in such a way that it could say whatever it wanted to
a human (and not, say, as a command that the human was expected to type),
yes, that would be more acceptable.  Since parameters are rarely 
presented to humans, it wouldn't IMHO be very useful to have such a 
parameter.

> > It is well established that email may be used to send executable content,
> > but we try to discourage having ways that make it easy for the email
> > reader to distinguish executable content from non-executable content
> > and execute it.
> 
> Surely one would like to encourage, rather than discourage, easy
> differentiation of executable and non-executable content.

Not when you look at what actually happens in practice when you do that.

> > The purpose of content-type parameters is for machine interpretation rather 
> > than human readability.
> 
> There is nothing in the core MIME RFCs or draft successors that requires
> machine interpretation.

true.  

> If a parameter is defined as
> human-readable information, then the appropriate action for a UA is to
> display the content to the user.

It's not going to happen, as UAs don't special-case handling of most
content-types.  (now maybe the plugin for the content-type could 
display such content to the user, but that doesn't seem much more
likely given common practices).

Keith
>From [e-mail]  Thu Apr 21 05:34:31 2005
From: mankin at psg.com (Allison Mankin)
Date: Thu Apr 21 05:34:36 2005
Subject: Transport Area requests Media Type review for
	application/conference-info+xml
Message-ID: <[e-mail]>


The Transport Area requests a Media Type review for the 
proposed new type application/conference-info+xml, intended
for the IETF tree, as a Proposed Standard, specified in 
draft-ietf-sipping-conference-package-10.txt

Please provide any comments by 4 May 2005.

Thanks,

Allison