Subject: I-D ACTION:draft-ietf-atompub-protocol-13.txt

From: [email-masked]
Date: Tue, 13 Feb 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 Atom Publishing Protocol
	Author(s)	: B. de Hora, J. Gregorio
	Filename	: draft-ietf-atompub-protocol-13.txt
	Pages		: 59
	Date		: 2007-2-13
	
The Atom Publishing Protocol (APP) is an application-level protocol
   for publishing and editing Web resources.  The protocol is based on
   HTTP transport of Atom-formatted representations.  The Atom format is
   documented in the Atom Syndication Format [RFC4287].

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-atompub-protocol-13.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-protocol-13.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-protocol-13.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: Julian Reschke <[email-masked]>
Date: Tue, 13 Feb 2007 22:21:13 +0100

[email-masked] schrieb:
> ...

Hmmm, didn't we have agreement to change 'application/atomserv+xml' to 
'application/atomsvc+xml'?

Best regards, Julian

---

From: James M Snell <[email-masked]>
Date: Tue, 13 Feb 2007 13:33:17 -0800

I was going to say ship it but I noticed one major problem: the
app:categories element is defined twice: once in section 7 and again in
8.2.5. I realize that these are different contexts (e.g. categories as a
standalone doc vs. an element in the service doc) but it's entirely
unnecessary to define 'em in both places.

- James

[email-masked] wrote:
> [snip]

---

From: "Joe Gregorio" <[email-masked]>
Date: Tue, 13 Feb 2007 16:48:02 -0500

> 'application/atomsvc+xml'?

A consensus call was asked for [1]
but I didn't receive one from
the chairs, even after asking off-list,
so I left it unchanged.

[1] http://www.imc.org/atom-protocol/mail-archive/msg07457.html

   Sorry,
   -joe

-- 
Joe Gregorio        http://bitworking.org

---

From: "Hugh Winkler" <[email-masked]>
Date: Thu, 15 Feb 2007 08:54:09 -0600

Re the type parameter (sec. 12): I earlier suggested to define file
extensions for feed and entry documents, and that suggestion got some
+1s and no objections.

Let me reiterate points:

1. If the "different processing models" models require we be able to
distinguish feeds from entries by mime types, then i we'll want to be
able to distinguish them using file extensions.  RFC 4288 has a place
for you to fill it in.

2. When you do that exercise you'll see that no existing software will
be able to map the mime type to the correct file extension. Existing
software can choose a file extension based on the major type/subtype
pair -- it will not parse out parameters looking for one named "type".
The transformation is not reversible -- we can go from file extensions
to mime types but not the other way.

3.  There will be no such problem if you simply choose a new subtype
to describe entry documents.

Hugh

-- 
Hugh Winkler
Wellstorm Development

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