tocol are really important.
Thank you.
bob wyman
rs,
then it would not be in conflict with RFC4288 since in both cases, "feed"
would be interpretted as being the value 'feed'...
bob wyman
etch feed documents to get atom:title values.) However, folk
really wanted to keep inheritance of the feed metadata and so we ended up
having to define something more complex.
bob wyman
the processing model for a single entry feed document...
bob wyman
they have rights not granted. The worst that can happen is that
readers don't know all the rights they have. This is acceptable, in my
opinion.
bob wyman
hat defines what "+xml" means?
bob wyman
recognize the
parameter detect and report "
bob wyman
this time can only be expressed as page-global.
(Yes, I realize this will take some time.)
bob wyman
ith significant market power, I
don't think that we can simply delegate the standards writing process to
such companies or modify standards to cover up their bugs. The fact that
Microsoft or any other company has done the wrong thing should not, in
itself, be sufficient to dictate the development of standards. Hopefully,
they will eventually see the error in their ways and correct them.
bob wyman
t might go in the envelope, but not as many as some folk
might think.
bob wyman
icit license
grant. Such rights may include fair-use rights, the right to create backups,
the implied right to syndicate, etc. As with Creative Commons licenses, I
believe our goal here should be to provide mechanisms to expand the rights
granted -- not to restrict them.
bob wyman
[1]
http://www.ietf.org/internet-drafts/draft-snell-atompub-feed-license-10.txt
a and those granted in entry metadata.
Forcing attachment of licenses to entries would also require using the
"undefined" license in more cases than is desirable.)
I've got a few other comments -- destined for other messages. Nonetheless,
this draft is looking much better than earlier drafts.
bob wyman
[1]
http://www.ietf.org/internet-drafts/draft-snell-atompub-feed-license-10.txt
is a "subtype." In some contexts, this
observation might be useful. I don't think, however, that such precision is
useful in the realm for which we normally are designing Atom...
bob wyman
y
good reason for doing it, we will simply have proven the often made claim
that standards groups simply can't be trusted with important specifications.
We will be encouraging more of the kind of "standards making" that resulted
in the mess that is RSS...
bob wyman
PS: Since Kyle poi
single entry as the semantic equivelant of a
single-entry feed. If a new media type is defined, such an application would
end up having to be modified. That's not right... APP is not the only
context within which Atom is used.
bob wyman
ation feeds. But, there is much that can be done to improve
on what they've done.
bob wyman
sense to me. We should
use the type parameter if anything is changed here.
bob wyman
he type parameter is [a] potentially more elegant
solution." Elegance is goodness. Let's insist on elegant solutions in the
absence of compelling reasons to be inelegant.
bob wyman
sonable (and sometimes efficient) for
people to subscribe to Entry documents, I don't think we should do anything
disruptive unless someone can establish actual harm being caused by the
current state of affairs.
bob wyman
aves "all
rights" reserved to the publisher and that only "fair use," "limited implied
license to syndicate," and "explicit license grants (like CC)" limit the
totality of those rights. With this in mind it might be best to change from
a "license" link to a "rights-grant" link... In other words, frame this link
type as something which can *only* be used to broaden rights, not restrict
them.
bob wyman
f an entry which contains an atom:source. To do so would make syndication,
aggregation, etc. a complete mess.
bob wyman
er some of the implied licenses that attach
to RSS/Atom syndicated content.[3]
bob wyman
[1] http://blogs.zdnet.com/Howell/?p=17
[2] http://blogs.zdnet.com/Howell/?p=18
[3] http://www.wyman.us/main/2006/09/magazine_or_mus.html
mmercial license has this effect when attached to a feed or
entry. I think it is in our interest to do what we can to avoid further
confusion by warning people of the limits of their assertions in the
specification. There will still be many who don't read the spec; however,
we'll be providing support to those who try to explain it...
bob wyman
od reason
to state their intention but an obligation to do so. Warning implementers
that the use of the license link may not, in at least some situations and in
some legal systems, create a legally enforceable binding is the right thing
to do.
bob wyman
considered to be part of the syndication process. Hopefully, my discussion
of the first sentence explains what this is all about.
My only suggestion for this sentence is that it might be less
strongly worded. Given that the law in this area is not settled, it might
make sense not to say "Nor can a license... restrict..." Rather, it might be
more accurate to say something like: "It is believed that a license ...
cannot restrict"
My apologies for such a long message...
bob wyman
be able to make more informed judgments if these distinctions
are clearly documented in the ID text.
bob wyman
eck do
people keep insisting that the industry continue to support new deployments
of RSS 2.0? This is just silliness.
bob wyman
a single entry or feed, is there any concept of precedence between the two?
For instance, if the text of the license is more or less restrictive than
what is in the atom:rights element, what should the reader assume about the
rights that are granted?
bob wyman
"226" response code...
bob wyman
[1] http://bobwyman.pubsub.com/main/2004/09/using_rfc3229_w.html
http://bobwyman.pubsub.com/main/2004/09/implementations.html
http://www.intertwingly.net/blog/2004/09/15/Syndication-with-RFC3229
[2] http://bobwyman.pubsub.com/main/2006/04/microsoft_to_su.html
sense to say something like: "It would not
be appropriate to apply the same timestamp to several entries unless they
were published simultaneously."
bob wyman
ing any rules of HTML and/or XHTML.
Data should be in the content element...
Bob wyman
[1] http://structuredblogging.org
Atom community.
http://bobwyman.pubsub.com/main/2005/09/joe_reger_shows.html
What can we do with Atom to make the vision of
Structured/Semantic publishing more real?
bob wyman
stion that lists-are-entries is much more useful than the alternative?
-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]
On Behalf Of Bob Wyman
Sent: Tuesday, August 30, 2005 5:10 PM
To: 'Mark Nottingham'
Cc: atom-syntax@imc.org
Subject: RE: "Top 10"
e alternative to using entries rather than feeds would be creating
multiple feeds per user. That strikes me as a solution which is ugly on its
face and unquestionably increases the complexity of the system for both
NetFlix and its customers. The "list-in-entry" solution is much more elegant
and much more powerful.
bob wyman
– they are feeds.
bob
wyman
you would only have to notify one service to
get pulled from them all -- a real benefit to users.) Or, we could define
extensions to Atom to express these things... There are many options.
Today, we do the best we can with what we have. Hopefully, we'll all
maintain enough interest in these issues to continue the process of working
them out.
bob wyman
ld is the process by which service or software
providers are educating their users. Services should work harder to educate
their users.
bob wyman
aping from blog's websites.) Thus, we filter out any feed
that comes from a service like Technorati since they scrape blogs and inject
scraped content into feeds without the explicit approval or consent of the
publishers of the sites they scraped.
bob wyman
[1] http://www.fondantfancies.com/apps/shrook/distfaq.php
uot; URI's found in tags,
tags and enclosures isn't crawling... Or... Is there something I'm
missing here?
bob wyman
conditional-gets, etc. and thus do all the things
necessary to reduce our load on publishers sites in the event that we
actually do fetch data from them. This is a good thing and not something
that robots.txt was intended to prevent.
bob wyman
-feed." We NEVER crawl. We're not a robot and thus I can't see why we
would even look at robots.txt. Does your browser look at robots.txt before
fetching a page? Does you desktop aggregator look at it before fetching a
feed? I don't think so! But, should a crawler like Google, Yah
nically and add them." If Walter is correct, then he must agree with me
that robots.txt does not apply to PubSub! (and, we should not be on his
"bad" list Walter? Please take us off the list...)
bob wyman
ants*
rights, it does not restrict, deny, or constrain them in any way. Thus, you
can't say: "The aggregator failed to respect the CC non-commercial use
attribute." You must say: "The aggregator failed to respect the copyright."
bob wyman
7;s point of view, an intermediary
aggregator like PubSub should be indistinguishable from the channel itself.
bob wyman
ides for robust error
recovery in that broken entries can be easily detected and discarded.
bob wyman
ll virtually
always ensure that any entry we publish has an atom:source element, one
could argue that we don't have to worry about this scope leakage. But, we're
a special case in this regard. The general issue of scope exists in cases
where the atom:source element is not present.
bob wyman
actually endless. We simply need to import some existing
knowledge about how to do partial document error recovery and we're where we
need to be.
bob wyman
s all
we need, lets not do something else unless there is a *very* good argument
to do so.
bob wyman
nd in all contexts.
Whatever... The point here is that Atom already has defined all that
appears to be needed in order to address the "Fat Ping" requirement whether
you prefer individual HTTP POSTs, POSTs over HTTP 1.1 connections, XMPP, or
raw open TCP/IP sockets. That is a good thing.
bob wyman
sider this
sort of thing to be very much like the cache control hints that folk insert
in the headers of HTTP packets. Sometimes, you have to give the
intermediaries like proxies, publish/subscriber routers or brokers, search
engines, etc. some hints to get them to work properly.)
bob wyman
idual parts. What you'd
have to do is create two distinct types of claim (one for collection and one
for item. That's messy.)
I'm sure that copyright and licenses aren't the only problematic
contexts here.
bob wyman
ts we can use the same parser for the stream
as we do for atom files. It works out nicely and elegantly.)
bob wyman
us, some server/client pairs would exchange
streams of Atom entries using the POST based Atom Publishing Protocol while
others would exchange essentially the same streams using a more efficient
transport mechanism such as streaming raw sockets or even "Atom over XMPP".
bob wyman
urce
element to include the extensions? (assuming there are no signatures...)
bob wyman
oblem with streaming basic Atom over TCP/IP, HTTP continuous sessions (probably
using chunked content) etc.? Is there any really good reason not just to use
Atom as defined?
bob wyman
feed itself
> d) completely unknown unless specified in the extension definition
I believe the correct answer is "e":
e) Unless otherwise specified, this information pertains to the feed only.
bob wyman
This is excellent news! Finally, we have an openly and formally defined
standard for syndication. Wonderful!
bob wyman
ry and those child elements are not present in the source
atom:entry."
I suggest that the Introduction cover atom:source in the "recommended"
section and highlight the case in which it is recommended.
bob wyman
-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL
What would the HTTP Accept Headers for Atom V1.0 look like?
i.e. if I want to tell the server that I want Atom V1.0 but do not want Atom
0.3?
bob wyman
Paul Hoffman wrote:
Now that I understand this better, I believe that our text should read:
Thank you for catching this. You've saved us major pain!
bob wyman
entries should strongly consider adding an atom:source element to
> those entries before signing them.
It looks good to me. Thanks!
bob wyman
IESG review, this should not cause
any delay beyond those that are already inevitable.
bob wyman
. would participate more but for whatever
reason, most have chosen to remain silent on these issues...
bob wyman
atures are all that is necessary and would result
in smaller, more bandwidth-efficient feeds.
bob wyman
element in
> all individually signed entries."
+1
bob wyman
folk until *after* it has been called out. We
will help matters greatly by at least providing a recommendation that source
elements be inserted in signed entries...
bob wyman
eferring this issue until the implementer's guide is written is likely
to defer it beyond the point at which common practice is established. The
result is likely to be that intermediaries and aggregators end up discarding
most signatures that appear in source feeds.
bob wyman
.
bob wyman
James M Snell wrote:
b. recommended inclusion of a source element in signed entries.
+1
bob wyman
at is signed. Referenced data may be under
different administrative control, may change independently of the signed
element, etc.
bob wyman
order to ensure that the
signed entry can be copied to other feeds without breaking the signature or
changing the semantics of the entry by allowing feed metadata from the
non-source feed to "bleed" into the entry.
bob wyman
that souce elements exist. The use of source
elements drastically simplifies this part of the canonicalization process.
bob wyman
in aggregated feeds. The mere act of
aggregation should not force a signature to be removed from an item. (Note:
Signed entries really *must* include source elements. Otherwise, aggregators
will be forced to strip off the signatures in order to insert the source
elements.)
bob wyman
ng the language of the
specifications themselves. It is only by developing a common understanding
of the various use cases that we can understand how the future work, if any,
of the working group should be defined.
bob wyman
sers the benefits of reduced bandwidth, reduced session
management, and reduced latency. Broad client-based support makes sense even
if similarly broad server-based support does not.
bob wyman
tom
Internet Draft. The word "next" doesn't even appear in the ID... If they
aren't there, how can you call them "Atom as it is now"? I thought Henry
Story was proposing these as extensions.
bob wyman
" and "next" tags
and encourage folk who need to keep up with high volume streams to use Atom
over XMPP. Lowered bandwidth utilization, reduced latency and simplicity are
good things.
bob wyman
overhead of creating so
many TCP/IP connections, however, at that point, you might as well have a
continuous push socket open...)
The push solution conserves network bandwidth, delivers data with
much less latency and is simpler to implement.
Polling sucks! (that was a pun...)
bob wyman
ll with Atom and Atom over XMPP gives you the best of both
worlds. You get very efficient and low latency publishing of new entries to
clients as well as efficient downloading of "catchup" files. What more could
you want? :-)
bob wyman
[1] http://www.xmpp.org/drafts/draft
he-whole, the efforts by
Google to popularize the Sitemap process and "syndication" by non-blogs is
absolutely wonderful! I'm only grumbling about the formats...
bob wyman
roprietary format. If we don't
convince folk to use Atom, then we're going to find that Sitemaps provides a
"good enough" solution and it will be very hard to convince people to
convert to the more expressive Atom format in the future.
bob wyman
ogle could provide a touch of
explanation...
bob wyman
uld be incorporated into the
autodiscovery specification?
bob wyman
.
bob wyman
solution is *not* superior, in any useful sense,
to a less elegant but implemented solution that delivers the same result.
bob wyman
etrieved the entry directly from the intermediary rather than from
someone who had copied it from the intermediary.
There are a number of interesting possibilities here
bob wyman
facilitate the interchange or translation of
documents between NewsML, NITF, etc. formats and Atom.
bob wyman
Antone Roundy wrote re the issue of DOS attacks:
> I've been a bit surprised that you [Bob Wyman] haven't
> been more active in taking the lead on pushing the conversation
> forward and ensuring that threads addressing the issue don't die
> out, given the strength of
her feeds or multiple authors.
bob wyman
RSS that will
have profound impact on our ability to build better applications for our
users.
bob wyman
I’ll be making a presentation on Tuesday which will
include a slide on how Atom improves on RSS. If you have any thoughts on this
subject, I would appreciate hearing them…
bob wyman
y focused on
the contents of the Atom feed -- which is all that PubSub is concerned with.
Nonetheless, the proposed texts should resolve your issues while allowing
PubSub to do its job.
bob wyman
if the users expect to always see the "most recent" instance?
bob wyman
As said before, I fully intend to "trust" publishers and fully
expect that if people produce entries that don't have the correct data in
any element that those entries will get treated in potentially unexpected
ways. I expect to conform to the specification. Others who wish to have
their data processed in a predictable way should also conform. Those who
don't conform -- screw 'em.
bob wyman
e in the core. It is inevitable that
extensions will not be as broadly implemented as elements of the core. The
practical implication of forcing something to be an extension is to ensure
that it is never broadly implemented.
bob wyman
works in the manner that your blog works. That
is not reasonable. To argue that the standard should make it possible for
you to do things the way you want is quite reasonable. But, you should give
to others the same consideration you apparently demand from them.
bob wyman
he signatures on the entries you published.
The "archive" method you describe does not produce a "superset" of
what you published; it is a different set of data from that which you
published. This is not necessary.
bob wyman
multiple ID" issue in that the
problem is exacerbated by permitting multiple instances of a single entry in
a single feed document. Whether or not it is relevant in other contexts is
largely irrelevant since it appears that addressing the issue in one context
will resolve it in other contexts as well.
bob wyman
be
addressed and dealt with by the Atom format. Atom:updated only addresses the
needs of publishers.
bob wyman
available that you might be able to
understand if you apply yourself and read carefully. If you need any help in
understanding what is written in the books, please feel free to send me a
mail asking for help deciphering the more difficult parts...
bob wyman
1 - 100 of 210 matches
Mail list logo
