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 Gregoriohttp://bitworking.org
.
-joe
--
Joe Gregoriohttp://bitworking.org
understands this and has still come to consensus that this is a great way to
proceed.
Like I stated previously, this has been discussed ad infinitum on the list
and the consensus supports it.
-joe
--
Joe Gregoriohttp://bitworking.org
-type option and the media-type-parameter option.
If a few people were to put up their hands and say yeah what Bob said
your co-chairs would probably do a hasty consensus grab./co-chair-mode
+1 to what Bob said.
-joe
--
Joe Gregoriohttp://bitworking.org
this week.
Please let me know which of the two approaches below y'all prefer...
Option A) Optional Type Param
application/atom+xml; type=entry
application/atom+xml; type=feed
+1
-joe
--
Joe Gregoriohttp://bitworking.org
of the resource.
- Sam Ruby
--
Joe Gregoriohttp://bitworking.org
that makes this position clearer. If some implementations
find that too loose and want octet-for-octet storage they can use
always WebDAV.
[1] http://www.imc.org/atom-protocol/mail-archive/msg05415.html
Thanks,
-joe
--
Joe Gregoriohttp://bitworking.org
, will clean up.
Lisa
Thanks again for the close reading.
-joe
--
Joe Gregoriohttp://bitworking.org
is
referenced by a couple APPS area RFCs: XMPP (RFC3920) and Atom Syntax
(RFC4287).
Yep, this definitely breaks RFC4287 in the way Joe predicted. Time for
a revision.
I'm confused. What breaks?
--Paul Hoffman, Director
--Internet Mail Consortium
--
Joe Gregoriohttp://bitworking.org
that 'feed' ought to
be 'Feed', but that is a rather minor change.
-joe
--
Joe Gregoriohttp://bitworking.org
orthogonal.
-joe
--
Joe Gregoriohttp://bitworking.org
On 1/19/06, Eric Scheid [EMAIL PROTECTED] wrote:
On 20/1/06 8:08 AM, Joe Gregorio [EMAIL PROTECTED] wrote:
The purpose of Atom autodiscovery is for clients who know the URI of a
web page to find the location of that page's associated Atom feed.
Not an entry but a feed
On 1/19/06, Phil Ringnalda [EMAIL PROTECTED] wrote:
On 1/19/06, Joe Gregorio [EMAIL PROTECTED] wrote:
Because rel is a space separated list of link types:
http://www.w3.org/TR/REC-html40/struct/links.html#adef-rel
https://mail.google.com/mail/
I.e. the values are all orthogonal
:
application/atom+xml; doc=entry
-joe
--
Joe Gregoriohttp://bitworking.org
Collections use atom:updated while Generic
Collections need app:updated.
That may seem like a minor nit, but it just seems, well, illogical.
Hope this is not too stupid,
Manuzhai
[1] http://www.ietf.org/internet-drafts/draft-ietf-atompub-protocol-05.txt
--
Joe Gregoriohttp
Sorry, that URI should have been:
http://bitworking.org/projects/atom/draft-ietf-atompub-protocol-06.html
-joe
On 10/31/05, Joe Gregorio [EMAIL PROTECTED] wrote:
The latest draft is -06 and is available here:
http://bitworking.org/projects/atom/atomapi/draft-ietf-atompub-protocol
documents[1].
-joe
[1] http://www.gmpg.org/xmdp/
--
Joe Gregoriohttp://bitworking.org
On 10/24/05, James M Snell [EMAIL PROTECTED] wrote:
Joe Gregorio wrote:
I would prefer a [EMAIL PROTECTED]'profile' as it provides a nice symmetry
with (X)HTML, in particular the microformat use of such
link elements to point at XMDP documents[1].
-joe
[1] http://www.gmpg.org/xmdp
On 10/19/05, Mark Nottingham [EMAIL PROTECTED] wrote:
Perhaps people could +1/-1 the following options:
* Reconstructing a feed should use:
a) a specific relation, e.g., prev-archive
-1
b) a generic relation, e.g., previous
+1
-joe
--
Joe Gregoriohttp://bitworking.org
--
Joe Gregoriohttp://bitworking.org
provides a solution to paging in the protocol
and are generally useful across a broad variety of feed application
cases. Regardless, it would be very good to see these registered.
+1
-joe
--
Joe Gregoriohttp://bitworking.org
/Atom_Auto_Sub_How_To
:)
-joe
--
Joe Gregoriohttp://bitworking.org
.
It's in there:
http://bitworking.org/projects/atom/draft-gregorio-09.html#rfc.section.5.4.1
So -1 to draft-nottingham-atompub-feed-history-04.txt for not using
a link tag of rel=prev.
-joe
--
Joe Gregoriohttp://bitworking.org
by PaceAppDocuments2:
PaceAppDocuments
PaceCollectionClasses
As always, discussion of these paces should occur on the atom protocol
list, with a subject line identifying which pace you are expressing an
opinion on.
- Sam Ruby
--
Joe Gregoriohttp://bitworking.org
-joe
--
Joe Gregoriohttp://bitworking.org
home page. *That* traffic is going to be a lot worse than an aggregator
subscription and wouldn't fit the definition of 'aggregation'.
-joe
--
Joe Gregoriohttp://bitworking.org
On 8/22/05, Sam Ruby [EMAIL PROTECTED] wrote:
Joe Gregorio wrote:
Why not POST the Atom Entry, ala the Atom Publishing Protocol?
Essentially, LiveJournal is making this data available to anybody who
wishes to access it, without any need to register or to invent a unique API.
Ahh, I had
ending feed has the advantage that you are only initializing
a SAX parser instance just once.
Interestingly enough the FF separated entries method would also work
when storing a large quantity of entries in a single flat file where
appending an entry needs to be fast.
-joe
--
Joe Gregorio
On 8/22/05, Justin Fletcher [EMAIL PROTECTED] wrote:
On Mon, 22 Aug 2005, Tim Bray wrote:
On Aug 22, 2005, at 7:26 AM, Joe Gregorio wrote:
Essentially, LiveJournal is making this data available to anybody who
wishes to access it, without any need to register or to invent a unique
On 8/21/05, Bob Wyman [EMAIL PROTECTED] wrote:
Joe Gregorio wrote:
Why not POST the Atom Entry, ala the Atom Publishing Protocol?
This would be an excellent idea if what we were talking about was a
low volume site. However, a site like LiveJournal generates hundreds of
updates per
by default, and such implementations will emit invalid Atom.
Nice clear wording.
+1 with MUST be no changed to MUST NOT be, as suggested by Aristotle.
+1 with the MUST NOT change incorporated.
-joe
--
Joe Gregoriohttp://bitworking.org
).
At the application level we're back to Postel again - publishers
shouldn't pump this stuff out, but liberal clients may find it useful
to trim whitespace from IRI and date fields. But surely that's outside
the scope of the format spec itself.
Cheers,
Danny.
--
http://dannyayers.com
--
Joe
--
Joe Gregoriohttp://bitworking.org
On 6/17/05, Bob Wyman [EMAIL PROTECTED] wrote:
Joe Gregorio wrote:
The one thing missing from the analysis is the overhead, and
practicality, of switching protocols (HTTP to XMPP).
I'm not aware of anything that might be called overhead.
I was referring to switching both the client
; that is to say, no src attribute should
be provided.
-joe
--
Joe Gregoriohttp://bitworking.org
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.
--
Joe Gregoriohttp
--
Joe Gregoriohttp://bitworking.org
* given in HTML 4.
Your specification should be consistent with HTML 4, not contradictory
to it.
The autodiscovery spec is a reasonable interpretation of the *one
line* definition of the 'alternate' relation. It is not contradictory.
+1
--
Joe Gregoriohttp://bitworking.org
On 5/4/05, Robert Sayre [EMAIL PROTECTED] wrote:
Mark's draft does an excellent job of documenting that reality.
+1
-joe
--
Joe Gregoriohttp://bitworking.org
On Apr 11, 2005 3:23 PM, Norman Walsh [EMAIL PROTECTED] wrote:
I don't really want to have to rev the Atom format
spec when XHTML 2.0 comes out.
+1
-joe
--
Joe Gregoriohttp://bitworking.org
not be optimal but I hope this
shows that barrier to generating an HTML 'alternate' is
not onerous, and that the link should remain a MUST.
Thanks,
-joe
--
Joe Gregoriohttp://bitworking.org
to a MUST.
-joe
--
Joe Gregoriohttp://bitworking.org
requesting that dates SHOULD be *accurate* to the second by
whatever process is generating the Atom document?
If that is correct, how does adding this restriction increase interop?
-joe
--
Joe Gregoriohttp://bitworking.org
implementation to automatically retrieve the ASCII version of the
Internet-Draft.
--
Joe Gregoriohttp://bitworking.org
regardless of the namespace the element sits in.
-joe
--
Joe Gregoriohttp://bitworking.org
document, new schemes which have been proposed as internet-drafts
are being processed with limited review.
___
IETF-Announce mailing list
IETF-Announce@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf-announce
--
Joe Gregoriohttp
On Thu, 17 Feb 2005 12:12:49 -0500, Norman Walsh [EMAIL PROTECTED] wrote:
Any chance we could change those attribute values to text, html,
and xhtml?
+1
-joe
--
Joe Gregoriohttp://bitworking.org
to be a lightweight protocol that did one thing
and did it well.
-joe
--
Joe Gregoriohttp://bitworking.org
example. The usage of
a URI in no way mandates 'dereferenceability'.
-joe
--
Joe Gregoriohttp://bitworking.org
the CLIENT presents the order
of the entries
in this spec.
-joe
--
Joe Gregoriohttp://bitworking.org
to PaceRemoveVersionAttr, particularly in light
of Atom being a Must Understand vocabulary.
--
Joe Gregoriohttp://bitworking.org
policy and nothing else. Am I missing something?
-joe
--
Joe Gregoriohttp://bitworking.org
. This would essentially de-couple the publication process.
+1
--
Joe Gregoriohttp://bitworking.org
On Tue, 1 Feb 2005 10:58:52 +0100, Danny Ayers [EMAIL PROTECTED] wrote:
On Sun, 30 Jan 2005 22:51:21 -0500, Joe Gregorio [EMAIL PROTECTED] wrote:
atom:nameAnonymous (from IP: aaa.bbb.ccc.)/atom:name
Well yes, and there's always:
atom
The title of this feed is The Stuff
brought forward. Rough consensus does not mean absolute consensus.
+1
-joe
--
Joe Gregoriohttp://bitworking.org
, or if we even skip it
completely and just lean on the reference to the security section of RFC 3986.
-joe
--
Joe Gregoriohttp://bitworking.org
goes for 'id', just leave it as an item for the security
considerations.
-joe
--
Joe Gregoriohttp://bitworking.org
.
}}}
== Impacts ==
== Notes ==
CategoryProposals
Thanks,
-joe
--
Joe Gregoriohttp://bitworking.org
PROTECTED] wrote:
If there were no further discussion: Hasn't got enough support so far,
but also has had no opposition we can find. -Tim
--
Joe Gregoriohttp://bitworking.org
be found here. -Tim
--
Joe Gregoriohttp://bitworking.org
that each adds to the base specification. -Tim
--
Joe Gregoriohttp://bitworking.org
support to call rough consensus in previous go-arounds. -Tim
--
Joe Gregoriohttp://bitworking.org
--
Joe Gregoriohttp://bitworking.org
for improvement, which have been
incorporated. Absent some convincing -1s, it probably goes in. -Tim
--
Joe Gregoriohttp://bitworking.org
On Mon, 24 Jan 2005 17:08:45 -0800, Tim Bray [EMAIL PROTECTED] wrote:
On Jan 24, 2005, at 5:02 PM, Joe Gregorio wrote:
It reads like more of a guideline than a Pace. Inspecting the format
for conformance to these guidelines and generating Paces for
non-conformances seems like a better
On Mon, 24 Jan 2005 20:41:40 -0500, Sam Ruby [EMAIL PROTECTED] wrote:
Joe Gregorio wrote:
+1 to the general Pace, but I would prefer to see
the 'Simple Extension' dropped. It adds a level of complexity
that isn't requried. and for no discernable benefit.
For example, the Pace states
stuff and not just syndication.
-joe
--
Joe Gregoriohttp://bitworking.org
67 matches
Mail list logo
