Antone Roundy wrote:
+1.
...oh, and the wording I just suggested for part of
PaceTextShouldBeProvided would depend on this also being accepted.
With deep regret, I'm going to express my -1 on PaceOptionalSummary.
Not because I object to the text expressed in the proposal section.
In fact, I
On 9 May 2005, at 1:19 pm, Sam Ruby wrote:
I also feel the need to express deep dismay at the way that author of
PaceOptionalSummary has been pursuing a scorched earth approach
whereby
everybody who expresses an opinion to the contrary is viciously
attacked
for doing so. I believe that this
A. Pagaltzis wrote:
* Thomas Broyer [EMAIL PROTECTED] [2005-05-03 19:35]:
This means type=text content is a single paragraph of text.
If you need paragraphs, lists or any other structural
formatting, you have to use type=html or type=xhtml with
the appropriate content.
Or type=text/plain, Id
http://www.intertwingly.net/wiki/pie/PaceNoAlternateForFeed
== Abstract ==
Allow publishers to indicate when they have no alternate link for a feed.
Author: BillDehora
== Status ==
Open
Incept: 2005-05-09
Written against:
http://www.ietf.org/internet-drafts/draft-ietf-atompub-format-08.txt
==
The pace adds this under atom:feed:
atom:feed elements that contain no child atom:id element
MUST contain an atom:link element with a relation of self.
That could just as well be:
atom:feed elements that contain no child atom:link element
with a relation of self
Bill de hÓra wrote:
...
{{{
o atom:feed elements MUST contain either and cannot contain both
- one or more atom:link elements with a relation of alternate.
- one and only one atom:link element with a relation of
no-alternate.
}}}
...
link rel=no-alternate /
...
Is this meant to
Bill de hÓra wrote:
...
Currently you MUST provide an alternate feed link. People are saying
they don't always have one to provide, which encourages garbage out.
That satisfying a spec constraint for its own sake. This addition allows
someone to say there is no alternate for this link. It's
On 5/6/05, Bill de hÓra [EMAIL PROTECTED] wrote:
-1.
I agree with Robert; it conflicts with PaceOptionalSummary and I doubt
it would exist if PaceOptionalSummary had not make the cut.
-1 as well. Doesn't solve a technical problem. It's just gamesmanship.
Robert Sayre
Some sites are beginning to serve
their feeds via intermediaries like FeedBurner. They are doing this, in part,
to make it easier for them to get better statistics on their use of the feeds,
to off-load bandwidth requirements, or to take advantage of the advertising insertion
and
Bob Wyman wrote:
Some sites are beginning to serve their feeds via intermediaries like
FeedBurner. They are doing this, in part, to make it easier for them to get
better statistics on their use of the feeds, to off-load bandwidth
requirements, or to take advantage of the advertising insertion and
On 5/6/05, Martin Duerst [EMAIL PROTECTED] wrote:
At 11:50 05/05/06, Sam Ruby wrote:
Tim Bray wrote:
+1
There are people who want to publish feeds without rel=alternate
links. I'm against telling people they can't do something they want to do
without strong reasons, as in loss of
On Monday, May 9, 2005, at 10:27 AM, Anne van Kesteren wrote:
Bob Wyman wrote:
Some sites are beginning to serve their feeds via intermediaries like
FeedBurner. They are doing this, in part, to make it easier for them
to get
better statistics on their use of the feeds, to off-load bandwidth
Antone Roundy wrote:
302 would result in feed readers (that follow the HTTP spec) continuing
to hit the publisher's site every time they checked the feed, and then
going to FeedBurner.
As it would not be a very large hit of say, 25 to 50 KiB; I guess people
can live with that.
2) Not everyone
On May 9, 2005, at 8:13 AM, Bill de hÓra wrote:
Why can't ve just leave a protocol element out if we don't have
information for it???
Because it allows someone to assert there is no alternate link for
their feed. That's different from leaving an alternate link out.
What observable difference in
Anne van Kesteren wrote:
Sites could also use a HTTP 302 link on their own site that points
to FeedBurner in the end. When FeedBurner dies or when they no longer
have desire to use the service, they switch the location of the
temporary redirect and all is fine.
While 302 is an
Off-list, I've been told some it would help to explain my view that
PaceTextShouldBeProvided and PaceOptionalSummary are incompatible.
---
First, remember that PaceOptionalSummary does one thing--make
content/summary optional. This means that Atom Processors
Tim Bray wrote:
On May 9, 2005, at 8:13 AM, Bill de hÓra wrote:
Why can't ve just leave a protocol element out if we don't have
information for it???
Because it allows someone to assert there is no alternate link for
their feed. That's different from leaving an alternate link out.
What
On 10/5/05 12:50 AM, Antone Roundy [EMAIL PROTECTED] wrote:
I didn't change the Pace, since such a change could conceivably change
the opinions of people who've expressed an opinion on it already. But
I would be interested to know whether people think this would be an
improvement, make it
On 10/5/05 1:14 AM, Antone Roundy [EMAIL PROTECTED] wrote:
http://www.intertwingly.net/wiki/pie/PaceRenameImageToLogo
+1
Hi Guys!
Did you see this email? Did you notice all the questions about the
technical basis of your position? Maybe you should answer them.
Also, I'm having trouble reconciling your road lying with the
assertion that the two proposals are compatible. How can they be if
their outcomes are so
On 5/9/05, Sam Hartman [EMAIL PROTECTED] wrote:
At least based on the discussion the IESG has been copied on, it
doesn't sound like the working group has fully considered this issue.
The responses have more of the character of those found from people
trying to brush aside an issue than of
Antone Roundy wrote:
On Sunday, May 8, 2005, at 10:08 AM, Tim Bray wrote:
On May 7, 2005, at 3:29 PM, Robin Cover wrote:
The publication of a new Implementation Guideline by the
Open Archives Initiative (OAI) compels me to suggest once
again [1], as Norm Walsh [2], Bob Wyman [3], and others have
On Monday, May 9, 2005, at 02:43 PM, Robert Sayre wrote:
Did you see this email? Did you notice all the questions about the
technical basis of your position? Maybe you should answer them.
Also, I'm having trouble reconciling your road lying with the
assertion that the two proposals are
I have no problem with title only feeds.
I'm -1 on POS, although I wouldn't describe myself as being positioned
in the path of oncoming traffic.
Title-only feeds have valid uses, but they're really out of scope for
a feed format that only exists because it provides a clearer, cleaner
way to
On 5/9/05, Antone Roundy [EMAIL PROTECTED] wrote:
I have no problem with title only feeds. I myself would be far less
likely to subscribe to them--or at least they'd have to have
extraordinarily well-written, informative titles for me to subscribe to
them in just about all cases--but there
On 5/9/05, Roger B. [EMAIL PROTECTED] wrote:
I have no problem with title only feeds.
I'm -1 on POS, although I wouldn't describe myself as being positioned
in the path of oncoming traffic.
Title-only feeds have valid uses, but they're really out of scope for
a feed format that only
At 9:33 AM -0400 5/9/05, Sam Hartman wrote:
My personal opinion as someone who is very shortly going to have to
evaluate the atom specification is that you've identified an issue
(space and line breaking) for some languages that should be
considered. Your proposed solution seems highly
Henri Sivonen wrote:
On May 8, 2005, at 06:30, Walter Underwood wrote:
White space is not particularly meaningful in some of these languages,
so we cannot expect them to suddenly pay attention to that just so
they can use Atom.
Why not? We expect them not no insert other random characters there.
Graham wrote:
On 9 May 2005, at 6:48 pm, Bill de hÓra wrote:
I think this exercise is *critical* for any piece of markup that is
going to move from mandatory to optional. Either way, we should pin
down spec language around the optionality of alternate feed links, or
consciously decide we're
On 5/9/05, Graham [EMAIL PROTECTED] wrote:
On 9 May 2005, at 6:48 pm, Bill de hÓra wrote:
I think this exercise is *critical* for any piece of markup that is
going to move from mandatory to optional. Either way, we should pin
down spec language around the optionality of alternate feed
On Monday, May 9, 2005, at 05:05 PM, Graham wrote:
On 4 Apr 2005, at 6:59 pm, Antone Roundy wrote:
And add this bullet point:
* atom:feed elements that contain no child atom:id element MUST
contain an atom:link element with a relation of self.
rel=self is in no way a substitute for an
On Tue, May 10, 2005 at 12:05:22AM +0100, Graham wrote:
rel=self is in no way a substitute for an identifier and shouldn't
Has anyone considered merging these into one (required) element? The ID
can be a URI. The URI need not be resolvable. If the URI is a URL,
it SHOULD (MUST?) point to
On Mon, May 09, 2005 at 10:53:14AM -0600, Antone Roundy wrote:
302 would result in feed readers (that follow the HTTP spec) continuing
to hit the publisher's site every time they checked the feed, and then
going to FeedBurner.
I'm not sure how user agents would handle it, but one could
On 10/5/05 11:12 AM, Antone Roundy [EMAIL PROTECTED] wrote:
rel=self is in no way a substitute for an identifier
Why not?
the uri can change.
e.
I think we should be clearer that new elements in the Atom namespace
and unprefixed attributes with parent elements in the Atom namespace
can only be added by IETF consensus. Thoughts?
Robert Sayre
On Tue, May 10, 2005 at 11:52:55AM +1000, Eric Scheid wrote:
Why not?
the uri can change.
URIs don't change; People change them.[1]
But yah, things are never that simple. Consequently, ignore my other
e-mail in this thread. (And sorry if this is all a re-hash.)
David
[1]
On 10/5/05 11:36 AM, David Nesting [EMAIL PROTECTED] wrote:
rel=self is in no way a substitute for an identifier and shouldn't
Has anyone considered merging these into one (required) element? The ID
can be a URI. The URI need not be resolvable. If the URI is a URL,
it SHOULD (MUST?)
On May 9, 2005, at 6:52 PM, Robert Sayre wrote:
I think we should be clearer that new elements in the Atom namespace
and unprefixed attributes with parent elements in the Atom namespace
can only be added by IETF consensus. Thoughts?
I wonder if there's some standard IETF practice when you define
Question: how do we refer to the product of this WG once it has an RFC
number?
We definitely need some quick, snappy label to refer to that version to
distinguish it from Atom 0.3, which is widely enough deployed that
it'll be with us for a while. Per WG consensus, an Atom doc has no
version
At 7:22 PM -0700 5/9/05, Tim Bray wrote:
On May 9, 2005, at 6:52 PM, Robert Sayre wrote:
I think we should be clearer that new elements in the Atom namespace
and unprefixed attributes with parent elements in the Atom namespace
can only be added by IETF consensus. Thoughts?
I wonder if there's some
Tim Bray wrote:
Question: how do we refer to the product of this WG once it has an RFC
number?
We definitely need some quick, snappy label to refer to that version
to distinguish it from Atom 0.3, which is widely enough deployed that
it'll be with us for a while. Per WG consensus, an Atom
On 5/9/05, Paul Hoffman [EMAIL PROTECTED] wrote:
Fair enough. But can just anyone add stuff to the Atom namespace?
If the IESG lets them, yes.
We gotta trust the IESG after the WG shuts down. Fortunately, they
have earned that trust over time.
I am fine with that. I am concerned that the
Tim Bray wrote:
Question: how do we refer to the product of this WG once it has an RFC
number?
We definitely need some quick, snappy label to refer to that version
to distinguish it from Atom 0.3, which is widely enough deployed that
it'll be with us for a while. Per WG consensus, an Atom doc
On 5/9/05, Antone Roundy [EMAIL PROTECTED] wrote:
Tim Bray wrote:
Question: how do we refer to the product of this WG once it has an RFC
number?
We definitely need some quick, snappy label to refer to that version
to distinguish it from Atom 0.3, which is widely enough deployed that
--On May 9, 2005 7:29:58 PM -0700 Tim Bray [EMAIL PROTECTED] wrote:
Anyone have a better idea? --Tim
Hey, let's vote on a *new* name. I'm +1 on Naked News, because
it delivers the news without chrome and crap. Or maybe that is what
you get when Atom (Adam?) goes public. Or because sex sells.
45 matches
Mail list logo
