Subject: I-D ACTION:draft-ietf-atompub-typeparam-00.txt

From: [email-masked]
Date: Tue, 02 Jan 2007 15:50:02 -0500

A New Internet-Draft is available from the on-line Internet-Drafts 
directories.
This draft is a work item of the Atom Publishing Format and Protocol Working Group of the IETF.

	Title		: The application/atom+xml Type Parameter
	Author(s)	: J. Snell
	Filename	: draft-ietf-atompub-typeparam-00.txt
	Pages		: 6
	Date		: 2007-1-2

   The Atom Syndication Format (RFC 4287) defines the 'application/
   atom+xml' media type to identify both Atom Feed and Atom Entry
   Documents.  This document defines an optional 'type' parameter used
   to differentiate the two types of Atom documents.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-atompub-typeparam-00.txt

To remove yourself from the I-D Announcement list, send a message to 
[email-masked] with the word unsubscribe in the body of 
the message. 
You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce 
to change your subscription settings.

Internet-Drafts are also available by anonymous FTP. Login with the 
username "anonymous" and a password of your e-mail address. After 
logging in, type "cd internet-drafts" and then 
"get draft-ietf-atompub-typeparam-00.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html 
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

Internet-Drafts can also be obtained by e-mail.

Send a message to:
	[email-masked].
In the body type:
	"FILE /internet-drafts/draft-ietf-atompub-typeparam-00.txt".
	
NOTE:	The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

---

From: "Bob Wyman" <[email-masked]>
Date: Tue, 2 Jan 2007 20:08:03 -0500

This document looks good on an initial quick read -- with one possible
exception. It says:

> Atom processors that do recognize the parameter SHOULD
> detect and report inconsistencies between the parameter's
> value and the actual type of the document's root element.

This would seem to be creating a directive concerning behavior which
is not directly related to interoperation between systems. (I'm
assuming that the destination of the "reports" is the user of the
application, a log file, or something like that.) Thus, it seems to me
that it might be inappropriate to use the SHOULD word since IETF apps
are supposed to be focused on interoperation and are supposed to avoid
constraining application behavior unnecessarily. May I suggest that
you rewrite this sentence in a manner similar to that below:

"It is strongly recommended that Atom processors that do recognize the
parameter detect and report ...."

bob wyman

---

From: James M Snell <[email-masked]>
Date: Thu, 04 Jan 2007 14:12:15 -0800

Hey Bob,

I have no problem with the rewording. Just waiting to see what others
may have to say about it.

- James

---

From: Asbjørn Ulsberg <[email-masked]>
Date: Fri, 05 Jan 2007 19:04:23 +0100

> may have to say about it.

I also like Bob's wording better.

-- 
Asbjørn Ulsberg     -=|=-    http://virtuelvis.com/quark/
«He's a loathsome offensive brute, yet I can't look away»

---

From: "Hugh Winkler" <[email-masked]>
Date: Wed, 10 Jan 2007 11:07:47 -0600

The draft makes no mention of file extensions.

"Atom Feed and Entry Documents can have different processing models
and there are situations where they need to be differentiated."

It would be good to enumerate some of those situations, and to examine
whether processing software depending on file extensions also requires
such differentiation. If ithe processing model is different enough to
require distinction in the mime type, it's important enough to require
distinction in the file system where mime types usually are forgotten.

Server software responsible for inserting correct Content-type header
can *possibly* set the correct value when serving a file, if the
type="entry" and type="feed" documents have distinct file extensions.
(I think this server behavior is an accident of implementation,
because I've never encountered a mime type parameter in any
"mime.types" file or in the Windows registry).

Client software receiving a file similarly consults a mime types
registry. I do not think any client software today would correctly be
able to save the file with the correct file extension, because it
would have had to have been programmed to parse all the parameters
(including possible parameters to be defined in the future). If the
client software has this entry in its registry:

application/atom+xml; type="entry"

and receives a file with this header:

Content-type: application/atom+xml; type="entry"
or this
Content-type: application/atom+xml; gdatakind="event"; type="entry"

there's little chance existing client software will assign the correct
file extension to the saved file.

On the other hand, if the draft assigned a new mime type to denote
entries, all existing processing software on server and client side
would correctly map content-type to file extension.

Hugh

-- 
Hugh Winkler
Wellstorm Development

http://www.wellstorm.com/
+1 512 694 4795 mobile (preferred)
+1 512 264 3998 office

---

From: Sylvain Hellegouarch <[email-masked]>
Date: Wed, 10 Jan 2007 17:44:51 +0000

> would correctly map content-type to file extension.

Fair point but it has been extensively discussed in a previous thread
and it appears that few people were keen on adding an entirely new media
type. While the type parameter may not be ideal it seemed to be lest
disruptive. I personally agree that a new media type would enforce the
correct and native distinction between entry and feed but most people
who have participated didn't feel like there was such a string requirement.

- Sylvain

---

From: Andreas Sewe <[email-masked]>
Date: Thu, 11 Jan 2007 11:41:36 +0100

> who have participated didn't feel like there was such a string requirement.

The OP has a (different) point, though: Recommending distinct file 
extensions for "application/atom+xml; type=entry" and 
application/atom+xml; type=feed" is worthwhile.

If, e.g., the mime.types shipped with Apache already contains 
appropriate entries, this would aid the fast adoption of the new, 
parameterized "application/atom+xml". Hence it would be worthwhile to 
include file extension recommendations in the I-D.

Regards,

Andreas

---

From: James M Snell <[email-masked]>
Date: Thu, 11 Jan 2007 07:44:08 -0800

+1

---

From: "Eric Larson" <[email-masked]>
Date: Thu, 11 Jan 2007 11:10:05 -0600

+1

---

From: Asbjørn Ulsberg <[email-masked]>
Date: Sun, 14 Jan 2007 02:31:50 +0100

> include file extension recommendations in the I-D.

Indeed. +1.

---

From: Andreas Sewe <[email-masked]>
Date: Fri, 19 Jan 2007 14:56:31 +0100

While RFC 2045 specifically allows quoted parameter values and defines 
application/atom+xml;type="feed" to be equivalent to 
application/atom+xml;type=feed, RFC 4288 states that '[t]here is no 
defined syntax for parameter values. Therefore registrations MUST 
specify parameter value syntax.'

So, it looks like that quoting the type parameter's values is no longer 
allowed; draft-ietf-atompub-typeparam-00.txt defines the following:

# type = "entry" / "feed"

But is this intentional? And, even if backed by RFC 4288 (I think so) 
and being intentional (I don't think so ;-), would it be worth to at 
least add a note to the parameter registration which explicitly states 
that quotes around "feed" or "entry" are disallowed?

Regards,

Andreas

---

From: Bjoern Hoehrmann <[email-masked]>
Date: Fri, 19 Jan 2007 15:12:13 +0100

>that quotes around "feed" or "entry" are disallowed?

You would apply the grammar above on the parameter value. In type="feed"
the parameter value is 'feed' which matches the grammar. Compare this to
XML attributes, if the attribute value must match /^[0-9]+$/ then you
also wouldn't conclude that the attribute value must not be "quoted".
-- 
Björn Höhrmann · mailto:[email-masked] · http://bjoern.hoehrmann.de
Weinh. Str. 22 · Telefon: +49(0)621/4309674 · http://www.bjoernsworld.de
68309 Mannheim · PGP Pub. KeyID: 0xA4357E78 · http://www.websitedev.de/

---

From: "Bob Wyman" <[email-masked]>
Date: Fri, 19 Jan 2007 16:21:07 -0500

On 1/19/07, Andreas Sewe <[email-masked]> wrote:
> So, it looks like that quoting the type parameter's values is no
> longer allowed;
Are the quotes part of the parameter value? Or, are quotes merely delimiters
of the value? If RFC045 is read to indicate that the quotes are delimiters,
then it would not be in conflict with RFC4288 since in both cases, "feed"
would be interpretted as being the value 'feed'...

bob wyman

---

From: James M Snell <[email-masked]>
Date: Fri, 19 Jan 2007 13:35:01 -0800

+1. The way I read it the quotes do not matter.

- James

Bob Wyman wrote:
> On 1/19/07, *Andreas Sewe* <[email-masked]
> <mailto:[email-masked]>> wrote:
> Are the quotes part of the parameter value? Or, are quotes merely
> delimiters of the value? If RFC045 is read to indicate that the quotes
> are delimiters, then it would not be in conflict with RFC4288 since in
> both cases, "feed" would be interpretted as being the value 'feed'...
> 
> bob wyman
>

---

From: Andreas Sewe <[email-masked]>
Date: Sun, 21 Jan 2007 13:28:26 +0100

James M Snell wrote:
>> delimiters of the value? If RFC045 is read to indicate that the
>> quotes are delimiters, then it would not be in conflict with
>> RFC4288 since in both cases, "feed" would be interpretted as being
>> the value 'feed'...
>

OK, you have convinced me; I simply misinterpreted RFC 4288.

This raises the question, however, whether it would be worth pointing 
out in the I-D that quoting a parameter value is allowed. Implementors 
might otherwise produce code that does treat 
application/atom+xml;type="feed" and application/atom+xml;type=feed as 
different.

James, can you add a note to this effect to your I-D? It doesn't do any 
harm and might to be useful (at least to people like me ;-).

Andreas

---

From: Bjoern Hoehrmann <[email-masked]>
Date: Sun, 21 Jan 2007 13:54:20 +0100

>harm and might to be useful (at least to people like me ;-).

It actually does harm. First, unless carefully phrased that might be
misread to suggest application/atom+xml;type="'feed'" or similar is
allowed, and it would suggest a false sense of completeness. As an
example, RFC 2616 would also allow you to use type="f\eed" or use of
MIME word encoding in the quoted string ala type="=?...?=". It seems
this is better left to a test suite.
-- 
Björn Höhrmann · mailto:[email-masked] · http://bjoern.hoehrmann.de
Weinh. Str. 22 · Telefon: +49(0)621/4309674 · http://www.bjoernsworld.de
68309 Mannheim · PGP Pub. KeyID: 0xA4357E78 · http://www.websitedev.de/