tomsvc+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 Gregoriohttp://bitworking.org
es
when those media types represent XML MIME (Multipurpose Internet Mail
Extensions) entities.""
-joe
--
Joe Gregoriohttp://bitworking.org
y.
See microformats.
It may be that I'm just having trouble accepting that the WG fully
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
ite up an I-D 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
een the new-media-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.
+1 to what Bob said.
-joe
--
Joe Gregoriohttp://bitworking.org
tml
This is the documented consensus of the WG. The next draft will have
verbage 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
tion of the resource.
- Sam Ruby
--
Joe Gregoriohttp://bitworking.org
ients authenticate once and then stop sending authentication
information automatically and it just works because of cookies. Also we'd
experienced this as an interoperability problem in WebDAV interoperability
tests where some server implementors insisted that certain WebDAV clients
were completely broken in not supporting cookies.
Are there assumptions that sessions will be maintained through persistent
connections? I believe there should be none. That is, if you're a client
implementor thinking that the first request will contain authorization and
subsequent requests on the same connection have no authorization, think
again.
I've stated my piece on authentication and the IETF requirements.
Just let me know the boiler plate that needs to be put in there
and i'll do it. I have no more energy for the subject.
ANCHOR sections
It's not clear to me that the RFC Editor will know what to do with all the
[[anchor... ]] sections. Most difficult of all, "anchor37" says "incomplete
section". For the rest, sometimes the RFC Editor may need to know what to
replace with what on publication. I'm sure the doc editors know what they
meant but I personally was left guessing.
Agreed, will clean up.
Lisa
Thanks again for the close reading.
-joe
--
Joe Gregoriohttp://bitworking.org
tion%2Fatom%5C%2Bxml&btnG=Search
(50 results)
Perl:
http://google.com/codesearch?hl=en&lr=&q=lang%3Aperl+application%2Fatom%5C%2Bxml&btnG=Search
(100 results)
C#:
http://google.com/codesearch?hl=en&lr=&q=lang%3Ac%23+application%2Fatom%5C%2Bxml&btnG=Search
(9 results)
--
Jo
that will obsolete RFC3548, which 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
--Inte
eter to the mime-type:
application/atom+xml; doc=entry
-joe
--
Joe Gregoriohttp://bitworking.org
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.go
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 loca
w.w3.org/TR/REC-html40/struct/links.html#adef-rel
I.e. the values are all orthogonal.
-joe
--
Joe Gregoriohttp://bitworking.org
e autodiscovery is unambiguous on what such
a link points to. Now to match RFC 4287 that 'feed' ought to
be 'Feed', but that is a rather minor change.
-joe
--
Joe Gregoriohttp://bitworking.org
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/
is is not too stupid,
>
> Manuzhai
>
> [1] http://www.ietf.org/internet-drafts/draft-ietf-atompub-protocol-05.txt
>
>
--
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 d
nts to point at XMDP documents[1].
-joe
[1] http://www.gmpg.org/xmdp/
--
Joe Gregoriohttp://bitworking.org
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"
t the document to remind myself of which "next"
> means, because either makes just as much sense to me.
True, but I don't think that means that the terms have to be
abandoned, but that these examples need to be supported by spec text.
That is, define 'next' as pointing to the next document in a series
of documents, the whole series of documents containing
a series of Atom Entries whose order is specific to the service
providing it.
-joe
--
Joe Gregoriohttp://bitworking.org
either end of the
> list, which could surprise some.
Eric,
It's like deja-vu all over again.
http://bitworking.org/news/Atom_Auto_Sub_How_To
:)
-joe
--
Joe Gregoriohttp://bitworking.org
ng
> functionality they offer 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
of the specs. So I guess I was
> mistaken.
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
iscussion 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
/bitworking.org/news/Not_Invented_Here
-joe
--
Joe Gregoriohttp://bitworking.org
xample,
take one of your
heavy search feeds, convert it to HTML via XSLT and include that via iframe
in my 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, 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
> >>> wish
ream. The
never 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
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 i
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
Why not POST the Atom Entry, ala the Atom Publishing Protocol?
-joe
--
Joe Gregoriohttp://bitworking.org
oneously insert whitespace around
> > values 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
rely that's outside
> the scope of the format spec itself.
>
> Cheers,
> Danny.
>
> --
>
> http://dannyayers.com
>
>
--
Joe Gregoriohttp://bitworking.org
hnology,
and the participants, I would expect [atom-syntax] to have the
longevity of [xml-dev].
-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.&q
acticality,
of switching protocols (HTTP to XMPP).
Thanks,
-joe
--
Joe Gregoriohttp://bitworking.org
is, if the type component
of the mime-type is equal to "text", or if the mime-type is one the
XML Media Types [XMLMIME], or the mime-type's sub-type ends with "+xml",
the content SHOULD be local; that is to say, no "src" attribute should
be provided.
-joe
--
Joe Gregoriohttp://bitworking.org
ntent-Type for each collection as well,
> but I'm not sure that would be necessary.
This document is just the 'basic' protocol, where we are describing
the basic mechanisms and collection types. We are expecting to produce
a further specification that covers editing collections of other types
of documents, such as templates, etc.
Thanks,
-joe
--
Joe Gregoriohttp://bitworking.org
> 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.
>
>
>
>
--
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
an autodiscovery
> > spec that takes advantage of the syntax *and semantics* 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
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
e,
today some feeds are full-content, others are abbreviated. If I
produce both kinds
of feeds, do I use the same atom:id for both? What if one feed is delivered via
email and the other via HTTP, should they both use the same atom:id?
-joe
--
Joe Gregoriohttp://bitworking.org
lternate doesn't matter a whole lot.
For me David Nesting's example of an Atom document as
an email attachment was the most convincing that @alternate
doesn't need to be a MUST.
I agree here with Bill and personally prefer to see atom:id lifted
to a MUST.
-joe
--
Joe Gregoriohttp://bitworking.org
tp://www.w3.org/2001/05/xslt
Now the generated HTML may 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
rmat of the date has a granularity of one second.
Are you 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
n 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.
>
>
>
>
--
Joe Gregoriohttp://bitworking.org
haracters?
-joe
[1] http://www.gbiv.com/protocols/uri/rfc/rfc3986.html#reserved
--
Joe Gregoriohttp://bitworking.org
(3.2.2) and the "uri" attribute of
> > "atom:generator" (4.2.5).
> >
> > In both cases they're not actually URIs, they're IRIs, so the name is
> > WRONG,
>
> Keeping the name atom:uri is exactly what Martin, author of RFC3987 and
> PaceIRI, suggested.
This is the reason I'm +1 on keeping it 'atom:uri'.
-joe
--
Joe Gregoriohttp://bitworking.org
l:base/xml:lang on any element
regardless of the namespace the element sits in.
-joe
--
Joe Gregoriohttp://bitworking.org
es 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://bitworking.org
rom sites like ietf.webav.org.
While it might be interesting to compare and constrast Atom and
WebDAV, please realize the Atom Publishing Protocol was
always intended to be a lightweight protocol that did one thing
and did it well.
-joe
--
Joe Gregoriohttp://bitworking.org
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
. The usage of
a URI in no way mandates 'dereferenceability'.
-joe
--
Joe Gregoriohttp://bitworking.org
an Atom Feed Document."""
There is no reason to even mention how the CLIENT presents the order
of the entries
in this spec.
-joe
--
Joe Gregoriohttp://bitworking.org
Without ever changing the namespace.
+1
And +1 to PaceRemoveVersionAttr, particularly in light
of Atom being a Must Understand vocabulary.
--
Joe Gregoriohttp://bitworking.org
into the
> protocol spec. This would essentially de-couple the publication process.
+1
--
Joe Gregoriohttp://bitworking.org
ExtendingAtom restrictive? It only spells out a Must Ignore
policy and nothing else. Am I missing something?
-joe
--
Joe Gregoriohttp://bitworking.org
arguing about IETF vs. W3C, mnot said "in the IETF,
> it's easier to shut down a solo raving loony." In the threads on
> atom:info, it seems I am playing the role of solo raving loony. So,
> let's have the process take over.
>
> Robert Sayre
>
>
--
Joe Gregoriohttp://bitworking.org
ck.
As I've stated before, referencing the security sections of these two
documents will not be helpful to an implementer.
Also, you have dropped all references to CSS.
-joe
--
Joe Gregoriohttp://bitworking.org
I had updated PaceFormatSecuruty based on feedback, removing all
the proscriptive prose about removing elements and just pointing out
potential security problems.
-joe
--
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:
>
> > Anonymous (from IP: aaa.bbb.ccc.)
>
> Well yes, and there's always:
>
>
> The title of
e could dereference
Identity URIs. As such, Identity Construct URIs MUST be
constructed in a manner that dereferencing such URIs MUST NOT cause
any ill effects.""
But I'm not sure if that belongs in the security section, 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
in Atom I could just as easily set the atom:name element to:
Anonymous
or
Anonymous (from IP: aaa.bbb.ccc.)
-joe
--
Joe Gregoriohttp://bitworking.org
treme length, and no new arguments have been
> brought forward. Rough consensus does not mean absolute consensus.
+1
-joe
--
Joe Gregoriohttp://bitworking.org
On Sat, 29 Jan 2005 06:06:54 +0100, Asbjørn Ulsberg
<[EMAIL PROTECTED]> wrote:
> On Fri, 28 Jan 2005 13:21:08 -0800, Tim Bray <[EMAIL PROTECTED]> wrote:
>
> > Whereas you could technically get by with warning-by-reference, I think
> > that it's OK and fact probably essential to point out that an
ersus the ones I outline in the Pace. If there were a
good reference of all the problems that HTML can cause when used in
email, *that* would be more in line with what we need, but I was
unable to find such a reference myself. Maybe someone else has better
google-fu than me.
-joe
--
Joe Gregoriohttp://bitworking.org
taken into account. See Section 8 of RFC 3987.
}}}
== Impacts ==
== Notes ==
CategoryProposals
Thanks,
-joe
--
Joe Gregoriohttp://bitworking.org
we might try to protect people against.
+1, and the same goes for 'id', just leave it as an item for the security
considerations.
-joe
--
Joe Gregoriohttp://bitworking.org
examples beyond RDF, which, as I asserted,
can be covered by an XSLT transformation. Since no others have been
supplied I'll stick to my -1.
-joe
>
> Henry Story
>
> On 25 Jan 2005, at 02:25, Joe Gregorio wrote:
> > -1 Ick.
> >
> > The only example given of a
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 dis
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
; Not yet taken up by the WG, depends on the discussion that comes with
> this call. Same rules as all the others: there has to be a positive WG
> consensus that it adds to the base specification. -Tim
>
>
--
Joe Gregoriohttp://bitworking.org
ived lots
> of friendly remarks and suggestions for improvement, which have been
> incorporated. Absent some convincing -1s, it probably goes in. -Tim
>
>
--
Joe Gregoriohttp://bitworking.org
objections.
> -Tim
>
>
--
Joe Gregoriohttp://bitworking.org
get anywhere near
> enough support to call rough consensus in previous go-arounds. -Tim
>
>
--
Joe Gregoriohttp://bitworking.org
e a positive WG
> consensus that each adds to the base specification. -Tim
>
>
--
Joe Gregoriohttp://bitworking.org
round. Consensus can
> still be found here. -Tim
>
>
--
Joe Gregoriohttp://bitworking.org
quot;
-joe
On Mon, 24 Jan 2005 16:17:42 -0800, Tim Bray <[EMAIL PROTECTED]> wrote:
>
> If there were no further discussion: Like PaceSupersede, this model of
> publishing does not (so far) enjoy consensus support. -Tim
>
>
--
Joe Gregoriohttp://bitworking.org
AIL 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
discussion: This has received no -1s, but also
> not a lot of wild enthusiasm. Support at the moment is a bit marginal,
> but some +1s from implementors would probably make it a slam-dunk.
> -Tim
>
>
--
Joe Gregoriohttp://bitworking.org
> the goal line, but if there is a wave of enthusiasm, there didn't seem
> to be that much opposition. -Tim
>
>
--
Joe Gregoriohttp://bitworking.org
; redundant but perhaps is actually useful. Useful enough to be
> mandatory, perhaps?
Yes, being mandatory would be helpful:
http://bitworking.org/news/Atom_Auto_Sub_How_To
-joe
--
Joe Gregoriohttp://bitworking.org
t; support and lots of detractors. Thank you. You may now return to your
> regularly scheduled programming. -Tim
Yay! I'm glad this goes down with more than me
as the lone detractor.
-joe
--
Joe Gregoriohttp://bitworking.org
server will need to keep a table in this form;
>
> [ 'snapshot15': ['entry111','entry112'],
>'snapshot14': ['entry100' ... 'entry110'],
>...
> ]
>
> where each snapshot corresponds to a Feed Document Resource (FDR?).
> Once enough entries is added to the most recent snapshot (15 here),
> another is created. So, when someone requests the latest feed, it will
> get a 'this' of http://www.example.com/feeddb?id=snapshot15 and a
> 'prev' of http://www.example.com/feeddb?id=snapshot14.
>
The part about this that makes me nervous is that this seems to be
veering closer to atom protocol stuff and not just syndication.
-joe
--
Joe Gregoriohttp://bitworking.org
//example.org/feed.cgi?start=91
http://example.org/feed.cgi?start=11
http://example.org/feed.cgi?start=1
Not the most efficient mechanism, but certainly plausible and it
causes problems with your spidering heuristic. Best leave it up to the
client.
Thanks,
-joe
--
Joe Gregoriohttp://bitworking.org
comparison of @rel values. Let's make progress a little at a time
> rather than holding back on ANY progress until we've got it perfect.
> We've been doing that in some areas for long enough.
+1 on the accepting the Pace as is and a big +1 to the
sentiment of making pr
I believe that
should hold no matter the validation method, either schema, DTD
or mustUnderstand.
-joe
--
Joe Gregoriohttp://bitworking.org
89 matches
Mail list logo
