important.
Thank you.
bob wyman
,
then it would not be in conflict with RFC4288 since in both cases, feed
would be interpretted as being the value 'feed'...
bob wyman
happen is that
readers don't know all the rights they have. This is acceptable, in my
opinion.
bob wyman
...
bob wyman
, folk
really wanted to keep inheritance of the feed metadata and so we ended up
having to define something more complex.
bob wyman
formalized in some RFC? I know we all
*think* that tacking +xml onto the end of something means that it is some
use of XML, however, if I remember correctly, this little bit of syntax has
never actually been formalized... Or have I missed something? Is there an
RFC that defines what +xml means?
bob wyman
and report
bob wyman
some time.)
bob wyman
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
in the envelope, but not as many as some folk
might think.
bob wyman
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
,
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
distinct instance of the atom type can be described in similar manners, it
would mean that every atom instance 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
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 points out that GData, a Google product, is potentially
impacted by the results of this discussion, I should state that I
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
here.
bob wyman
. But, there is much that can be done to improve
on what they've done.
bob wyman
anything
disruptive unless someone can establish actual harm being caused by the
current state of affairs.
bob wyman
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
be
more accurate to say something like: It is believed that a license ...
cannot restrict
My apologies for such a long message...
bob wyman
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
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
so would make syndication,
aggregation, etc. a complete mess.
bob wyman
people keep insisting that the industry continue to support new deployments
of RSS 2.0? This is just silliness.
bob wyman
judgments if these distinctions
are clearly documented in the ID text.
bob wyman
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
in fetching updates to Atom feeds. Also,
Microsoft will be supporting RFC3229+feed in their browsers[2], thus, we can
anticipate that support for fetching delta-feeds will soon be considered
expected. The only issue with Apache is that Apache *still* does not
support the 226 response code...
bob
something like: It would not
be appropriate to apply the same timestamp to several entries unless they
were published simultaneously.
bob wyman
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
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 and other lists should
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
.
Im sorry but I simply cant
see that it makes sense to encourage folk to break important rules of Atom by
redefining feeds to be lists. If we want lists we should define
what they look like and put them in entries. Keep your hands off the feeds.
Feeds arent lists they are feeds.
bob
wyman
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, Yahoo! or
Technorati respect robots.txt? YES!
bob wyman
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
... Or... Is there something I'm
missing here?
bob wyman
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
are educating their users. Services should work harder to educate
their users.
bob wyman
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
, an intermediary
aggregator like PubSub should be indistinguishable from the channel itself.
bob wyman
. 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
does not apply to PubSub! (and, we should not be on his
bad list Walter? Please take us off the list...)
bob wyman
and provides for robust error
recovery in that broken entries can be easily detected and discarded.
bob wyman
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
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
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
the extensions? (assuming there are no signatures...)
bob wyman
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
and elegantly.)
bob wyman
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
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
something else unless there is a *very* good argument
to do so.
bob wyman
This is excellent news! Finally, we have an openly and formally defined
standard for syndication. Wonderful!
bob wyman
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
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
will help matters greatly by at least providing a recommendation that source
elements be inserted in signed entries...
bob wyman
individually signed entries.
+1
bob wyman
and would result
in smaller, more bandwidth-efficient feeds.
bob wyman
to remain silent on these issues...
bob wyman
review, this should not cause
any delay beyond those that are already inevitable.
bob wyman
consider adding an atom:source element to
those entries before signing them.
It looks good to me. Thanks!
bob wyman
James M Snell wrote:
b. recommended inclusion of a source element in signed entries.
+1
bob wyman
.
bob wyman
) that is signed. Referenced data may be under
different administrative control, may change independently of the signed
element, etc.
bob wyman
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
of the reasons 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
bandwidth, reduced session
management, and reduced latency. Broad client-based support makes sense even
if similarly broad server-based support does not.
bob wyman
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
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
.
bob wyman
... 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
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-saintandre-atompub-notify-02.html
[2] http://www.pubsub.com/downloads.php
[3
wonderful! I'm only grumbling about the formats...
bob wyman
into the
autodiscovery specification?
bob wyman
...
bob wyman
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 your comments on the issue
Ill 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
applications for our
users.
bob wyman
.
bob wyman
it. If you insist on
objecting to it then let the darn thing be optional -- but instead of trying
to impose your personal vision on the process, just let the rest of us get
on with doing the work we need to do in the way we know we have to do it.
bob wyman
themselves as bits on the wire people: The specification should
specify the meaning of the bits on the wire -- not what one does with the
bits after receiving them.
bob wyman
not addressed -- I
think it would be both wise and appropriate to provide text in a Security
Concerns section that describes the vulnerability of systems that rely on
Atom documents to this particular attack.
bob wyman
should support atom:modified to permit the temporal-ordering of
members of sets that share the same atom:id and atom:updated values. This
has nothing to do with versioning.
bob wyman
contain multiple elements that
share common atom:id and atom:updated values.
I believe this was communicated when I wrote:
Atom should support atom:modified to permit the temporal-ordering of
members of sets that share the same atom:id and atom:updated values.
bob wyman
values.
I repeat (with a few added words to make it even more clear):
Atom should support atom:modified to permit the temporal-ordering of
members of sets whose members share the same atom:id and atom:updated
values.
bob wyman
, atom:modified is clearly distinguished from
atom:updated *by definition!* Atom:modified indicates that last time an
entry was modified. Atom:updated indicates the last time it was modified in
a way that the publisher considered significant. This is a very clear
distinction.
bob wyman
with by the Atom format. Atom:updated only addresses the
needs of publishers.
bob wyman
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
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
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
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
with.
Nonetheless, the proposed texts should resolve your issues while allowing
PubSub to do its job.
bob wyman
in the
future and Microsoft should be commended for supporting the adoption of
openly defined standards for syndication.
For more info (and some heated comments...) see:
http://bobwyman.pubsub.com/main/2005/05/microsoft_to_su.html
bob wyman
FeedBurner, there
should be a way to point people to the location of my preferred feeds.
bob wyman
services in multiple layers of the stack is
a reasonable thing to do as long as the semantics vary at least slightly
between the layers and the reasons for the variances are related to the
nature of the layers.
bob wyman
thing to do.
bob wyman
is.
bob wyman
a
relation of the new HTML document as a whole?
Personally, I think there is a serious scoping problem here. We've
got attributes of separable components of a page establishing metadata for
the page as a whole. Not good.
bob wyman
1 - 100 of 157 matches
Mail list logo
