Begin forwarded message:
From: John Cowan [EMAIL PROTECTED]
Date: January 4, 2007 8:08:06 AM PST (CA)
To: [EMAIL PROTECTED]
Subject: Atom format interpretation question
Am I right in thinking that content which is in fact in XML but
is labeled with a media type that is neither generic XML nor
On Dec 15, 2006, at 5:00 PM, Lisa Dusseault wrote:
I guess I'm assuming that one would want clients to be able to
extend Atom unilaterally.
That doesn't seem to have been a design goal for the WG. To the
extent that the issue never came up in the discussion.
The choices that I
Lisa Dusseault wrote:
Can a client modify an entry to contain a link relation element in the
following cases:
- To point to a resource on a different server entirely?
There is no reason to believe that any of these resource are on
the same machine to begin with. I could POST to media to
Bob Wyman wrote:
There is, I think, a compromise position here which will avoid breaking
those existing implementations which follow the existing RFC's.
co-chair-modeIn case you haven't noticed, the WG is hopelessly split
between the new-media-type option and the media-type-parameter option.
Anne van Kesteren wrote:
Jan Algermissen
[EMAIL PROTECTED] wrote:
is it really true that the Atom namespace is
http://www.w3.org/2005/Atom ?
It wasn't really relevant, I'd say. (That it says Atom and not atom
was a mistake.)
I'd agree. Sigh. But not a big one, I think -Tim
Mark Baker wrote:
Ok, the recent discussion seems to point towards a consensus towards
distinctly flagging Entry Documents in the media type.
Erm, isn't it up to the chairs to declare concensus?
co-chair-modeI agree that there exists sentiment in favor of there
being a way to distinguish
I seems obvious to me that Atom Feed and Entry docs are potentially
quite different things which can be used for entirely different
purposes. The contention that an Entry doc is somehow really the same
as a one-entry Feed doc is entirely unconvincing.
The Architecture of the Web
On Nov 29, 2006, at 8:16 AM, James M Snell wrote:
http://www.intertwingly.net/wiki/pie/PaceEntryMediatype
#pragma section-numbers off
== Abstract ==
For the current Atom Publishing Protocol draft...
Irrespective of the merits of the new media type, the APP spec seems
like the wrong
On Nov 28, 2006, at 3:16 PM, Robert Sayre wrote:
They already know how, in general. The WHAT-WG is the place to work
out edge cases in HTML semantics.
Over the course of history, a remarkable number of different groups
have jumped up and down and said *We're* the ones defining HTML!!!
On Nov 22, 2006, at 3:11 AM, Sylvain Hellegouarch wrote:
Say I POST an atom:entry to a collection URI, this entry does not have
an atom:author
If I were implementing the server, in this scenario I'd reject the
post with an error message. It's hard for me to see a scenario where
the
, Eric Scheid wrote:
On 27/9/06 8:15 AM, Tim Bray [EMAIL PROTECTED] wrote:
PaceAppEdited: Lots of discussion. There seems universal support for
the utility of an app:edited element, and an assertion that entry
members SHOULD contain one. On the other hand, every discussion of
sort order has
On Sep 26, 2006, at 12:34 PM, Sam Ruby wrote:
Here's a list of Paces that weren't disposed of with the last
consensus call:
First of all, did Sam get them all? Please speak up soonest about
anything that was missed and might have a realistic chance.
co-chair-mode
PaceAppEdited: Lots
On Sep 11, 2006, at 4:27 AM, James Aylett wrote:
We've run across a situation where we want to annotate an atom:icon
with a title. Currently we're doing the following, as something that
Feed Validator is happy with, but doesn't feel right:
On Sep 11, 2006, at 7:45 AM, James Aylett wrote:
Feed Validator gets upset with extension attributes - is it wrong?
Be specific, please? -Tim
Eric Scheid wrote:
When updating an entry, is it acceptable to insert a value other than Now()
into atom:updated?
Clearly, since updated is defined as the time the publisher thinks it
was significantly updated. Of course, the server could over-write the
updated value if it chose. -Tim
On May 30, 2006, at 5:25 PM, James Holderness wrote:
I agree completely, but as a content consumer I still need to know
whether to use IRI::Compare or String::Compare when I do encounter
some ridiculous feed that uses example (a). I'm hoping for a simple
answer along the lines of Use
On May 17, 2006, at 12:46 PM, Byrne Reese wrote:
Speaking up:
http://www.majordojo.com/atom/
standardizing_the_atom_thread_extension.ph
p
No surprise I guess, but I am a huge +1. Lock this spec down and ship
it.
Me too. Does something useful, does no harm, if it's broken in some
way
On May 18, 2006, at 6:15 AM, David Powell wrote:
What I see as a problem is that reasonable implementations will not
preserve Atom documents bit-for-bit, so they will need to explicitly
support this draft if they don't want to corrupt data by dropping the
thr:count attributes. By the letter of
On May 20, 2006, at 8:49 AM, David Powell wrote: (at great length)
I'm going to re-organize David's argument a little and deal with one
of his last points first.
Foreign attributes are bad, and are inherently less interoperable
than Extension Elements.
I would say that furious debates
On May 4, 2006, at 3:43 PM, Thomas Broyer wrote:
Things would have been far easier if either a) atom:link were
extensible
This assertion that atom:link is not extensible is simply, flatly,
completely, wrong. I just went and reviewed 4287 and I think it is
perfectly clear on this. I
On May 4, 2006, at 5:25 PM, Kyle Marvin wrote:
the motivation behind
sometimes using 'extensionElement' and other times 'undefinedContext'
in the Relax-NG schemas for various 4287 elements is a point of
confusion.
Agreed. Fortunately the schema's non-normative. -Tim
On May 4, 2006, at 5:08 PM, A. Pagaltzis wrote:
The assertion is not that atom:link may not have child elements
or namespaced attributes. The assertion is that the list of
locations for Metadata elements in Section 6.4 should have
included atom:link.
Mountain, meet molehill.
If it turns out
On Mar 30, 2006, at 9:20 PM, James M Snell wrote:
I would agree that, as a best practice, the xml:base should appear on
the content element, but implementations need to be prepared to use
whatever the in-scope URI is (e.g. if no xml:base is specified,
relative
refs in the content will be
On Mar 23, 2006, at 8:01 AM, Sylvain Hellegouarch wrote:
Seriously though, the atom:name element is described as a human-
readable name,
Do you mean that human-readable is equivalent to solely English?
Because as a French, having accents in names is so natural that I
see it as human
On Mar 23, 2006, at 8:57 AM, Eric Scheid wrote:
On 24/3/06 3:21 AM, Anne van Kesteren [EMAIL PROTECTED]
wrote:
authorname![CDATA[Bertrand Cafeacute;]]/name/author
Even if it was HTML you couldn't really use the entity, could
you? I think
you have to use a character reference or the
On Mar 23, 2006, at 8:16 AM, Eric Scheid wrote:
If I have an author with the name Bertrand Café, is it acceptable
to put
that into atom:author like this;
authorname![CDATA[Bertrand Cafeacute;]]/name/author
or should I be using the unicode numeric entity instead?
The key point is that
On Mar 23, 2006, at 2:20 PM, Eric Scheid wrote:
Oh well, now to track down a list of html entities and
their corresponding unicodes ...
http://www.google.com/search?q=xhtml%20entities
On Mar 9, 2006, at 7:51 AM, Sean Lyndersay wrote:
I hope this helps make the reasoning behind IE’s behaviour with
feeds and stylesheets a little less murky.
I don't really have an opinion as to whether this is the ideal
behavior. But there is no doubt whatsoever that that Sean's software
Where can one go to get versions of the atom logo (the one in view at
atomenabled.org) in various sizes? -Tim
On Mar 6, 2006, at 12:43 PM, Anne van Kesteren wrote:
Quoting Tim Bray [EMAIL PROTECTED]:
Where can one go to get versions of the atom logo (the one in view
at atomenabled.org) in various sizes? -Tim
I guess SVG fits that definition:
http://zcorpan.1go.dk/sandbox/svg/atom/.xml
Oooh
On Feb 24, 2006, at 3:05 PM, Sean Lyndersay wrote:
I'm sure that many people -- on this list in particular -- think
that the right thing to do is to normalize to Atom 1.0, instead.
Yep, that's certainly one way to think about it. But then I'd be
having this same discussion with Dave and
On Jan 30, 2006, at 8:23 AM, James M Snell wrote:
+1. Serving atom up at application/xml is perfectly acceptable
It is *not*. Atom has a registered Internet media type (application/
atom+xml); using anything else is a bug. -Tim
On Jan 30, 2006, at 12:57 PM, John Panzer wrote:
In other words, the application/xml content is a fallback for when
users, despite our best efforts, end up looking at XML content
inside a web browser. I'd also be happy to make this behaviior
browser-dependent so that we serve
On Jan 25, 2006, at 11:56 AM, James M Snell wrote:
APP should use the values as registered. That is, previous, next,
first, last and current. No need to modify the registrations.
+1
On Jan 19, 2006, at 9:05 AM, Robert Sayre wrote:
PaceAnchorSupport and PaceDifferentRelValue don't seem very useful,
and they weren't proposed by implementors. The spec is extremely
well-written and reflects existing behavior.
Can we please un-expire this:
On Jan 10, 2006, at 9:07 AM, James M Snell wrote:
In RSS there is definite confusion on what constitutes an update. In
Atom it is very clear. If updated changes, the item has been
updated.
No controversy at all.
Indeed. There's a word for behavior of RssBandit and Sage: WRONG.
On Jan 9, 2006, at 5:08 PM, James M Snell wrote:
The updated element is used to indicate when a significant update
has occurred to the entry. If you are updating the updated element
when you update your entry, you are doing the right thing. If
RSSBandit and FeedDemon are not picking up
On Dec 17, 2005, at 9:01 PM, Alan Gutierrez wrote:
I'm to understand that Atom has adopted the Tag URI as a a perferred.
GUID for an Atom 1.0 feed.
It has not. There is no preferred scheme. -Tim
On Oct 26, 2005, at 9:46 PM, Eric Scheid wrote:
Section 4.1.2 of the Atom Syndication Format spec states this:
This specification assigns no significance to the order of
appearance of the child elements of atom:entry.
Is this referring to the immediate children only of atom:entry,
On Oct 21, 2005, at 5:03 PM, Mark Nottingham wrote:
How about:
- Description: A URI that refers to a feed document containing a
set of the most recent entries in the feed. This URI is intended to
be subscribed to to keep abreast of recent changes in the feed;
when different from the
On Oct 22, 2005, at 3:28 AM, Eric Scheid wrote:
I think you've got the special case turned around. That is, if you are
looking at a representation of the active feed then the 'self' link
would
happen to match the 'subscribe' link, which is the exception. The
defining
text in the spec says
On Oct 22, 2005, at 8:40 AM, Mark Nottingham wrote:
You seem to be saying that because link/@rel=self was designed
for a specific purpose, and even though its definition is quite
descriptive (its definition *only* says it should be used to link
to the current document; -11 says nothing
On Oct 21, 2005, at 7:38 AM, James Holderness wrote:
The idea being that if you were to come across an archived Atom
document (however that might happen), the presence of this link
would, (a) let you know that it was an archive document and thus
shouldn't be subscribed to, and (b) provide
On Oct 21, 2005, at 3:13 PM, Mark Nottingham wrote:
- Description: A URI that refers to a feed document containing a
set of the most recent entries in the feed. This URI is intended
to be subscribed to to keep abreast of recent changes in the feed.
When different from the URI of the
On Oct 7, 2005, at 10:20 AM, Byrne Reese wrote:
Are there any good examples of how the [EMAIL PROTECTED] attribute is
used?
Over at 'ongoing', I have my own set of categories, so my category
elements look like
category scheme='http://www.tbray.org/ongoing/What/' term='Business' /
On Sep 9, 2005, at 5:03 AM, Bill de hÓra wrote:
Here's the feedvalidator results for my journal served up as
Atom1.0 as
per MT3.2's Atom1.0 template
http://feedvalidator.org/check.cgi?url=http%3A%2F%2Fwww.dehora.net%
2Fjournal%2Fatom.xml
I'm getting a 404 on that (or rather the
On Aug 23, 2005, at 6:57 AM, Bjoern Hoehrmann wrote:
That's a bit misleading, a fatal error just means that the XML
processor must report the error to the application and that the
processor is not required by the XML specification to continue
processing; doing so is however an optional
On Aug 22, 2005, at 9:27 PM, A. Pagaltzis wrote:
It's got another advantage. You connect and ask for the feed.
You get
feed xmlns=http://www.w3.org/2005/Atom;
... goes on forever
and none of the entry documents need to redeclare the Atom
namespace, which saves quite a few
On Aug 22, 2005, at 9:56 PM, Bjoern Hoehrmann wrote:
If you encounter a busted tag on the Nth entry, per the XML spec
that's a fatal error and you can't process any more.
That's a bit misleading, a fatal error just means that the XML
processor must report the error to the application and
On Aug 21, 2005, at 1:42 PM, A. Pagaltzis wrote:
* Paul Hoffman [EMAIL PROTECTED] [2005-08-21 21:55]:
Ah, I had missed that. This leads to a question for the mailing
list. Does an informative extension that appears at the feed
level (as compared to in entries) indicate:
d) completely
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 API.
Ahh, I had thought this was a more dedicated ping traffic stream. The
never ending Atom
On Aug 17, 2005, at 4:10 AM, Henry Story wrote:
Yes. I agree the problem also exists for complex extensions. My
question is the following:
How can a parser that parses atom and unknown extensions, know when
to apply the xml base to
an extension element automatically?
It can't.
Anyway
On Aug 15, 2005, at 7:28 AM, Tim Bray wrote:
The way Tim Bray's feed and the examples from James Snell on
developerWorks use xml:base is what Roy T. Fielding calls an abuse.
I disagree with Roy, but agree that the way my links were set up was
a little surprising to the eye, so I tweaked
On Aug 13, 2005, at 1:34 AM, Simon Brown wrote:
Just to quote an example, Tim is currently using URL based Atom
IDs, such as :
idhttp://www.tbray.org/ongoing//id
idhttp://www.tbray.org/ongoing/When/200x/2005/08/09/Web-2.0/id
If Tim *moves* his blog to www.timbray.com/ongoing, would you
On Aug 12, 2005, at 1:55 AM, Graham Parks wrote:
categorization scheme means the system used to categorize
entries. Presumably each blog has its own system for doing so, so
the scheme attribute should be the same for all posts from the same
blog, and unique to the blog.
Mostly agree.
On Aug 9, 2005, at 5:11 PM, David Powell wrote:
No, we just need to warn publishers (and extension authors) that the
base URI of Simple Extension elements is not significant, and that
they must not expect it to be preserved.
Either the software understands the foreign markup, in which case
On Aug 4, 2005, at 1:04 PM, Sam Ruby wrote:
Tim Bray wrote:
I'm getting increasingly grumpy and just fail is looking better and
better. The current normative text, The element's content MUST
be an
IRI, is clear and simple and supported by other well-understood
normative text
On Aug 3, 2005, at 6:04 AM, Sam Ruby wrote:
To an Infoset person, this following is a completely different stream
from the example above (please ignore any line breaks that your email
client may insert):
atom:id#104;#116;#116;#112;#58;#47;#47;#101;#120;#97;#109
On Aug 4, 2005, at 10:59 PM, Eric Scheid wrote:
link rel=in-reply-to
href=http://www.example.com/atom;
type=application/atom+xml
thread:idref=urn:foo:1 /
this way processors that have a basic understanding of what a
link is can
still do something useful.
On Aug 5, 2005, at 5:59 AM, David Powell wrote:
We say that Simple Extension Elements are not language sensitive,
but
They *are* affected by xml:base. xml:base establishes the base URI
for wherever it's in-scope, with a specific callout to RFC3986 for
the semantics. Anytime you see
On Aug 4, 2005, at 3:25 AM, Paul Hoffman wrote:
At 7:37 PM -0400 8/2/05, Robert Sayre wrote:
One way of saying this would be Atom Processors MAY ignore leading
and trailing whitespace in _.
That works for me. Another idea is Atom Processors MAY ignore
leading and/or
On Aug 4, 2005, at 6:53 AM, Robert Sayre wrote:
I propose trying harder, but I am open to just fail.
As am I. I am not OK with a long treatise on whitespace, like the one
Tim suggested. If there is a MUST-breaking error in a feed, that's not
an Atom document and I don't want to talk about
On Aug 2, 2005, at 4:37 PM, Robert Sayre wrote:
One way of saying this would be Atom Processors MAY ignore leading
and trailing whitespace in _. That is, no existing
software is buggy, but if you want to be sure your document is
processed accurately, you should trim the space
/ongoing/'
xml:lang='en-us'
titleongoing/title
link href='' /
link rel='self' href='ongoing.atom' /
logorsslogo.jpg/logo
icon/favicon.ico/icon
updated2005-07-16T11:17:23-08:00/updated
authornameTim Bray/name/author
subtitleongoing fragmented essay by Tim Bray/subtitle
idhttp://www.tbray.org/ongoing
On Jul 16, 2005, at 1:28 PM, Sam Ruby wrote:
I didn't realize that path-empty was a valid URI-reference.
Yeah, it means here.
While it clearly shouldn't be the default behavior, longer term
(i.e., sometime well after basic Atom 1.0 support is more
complete), how much value do you think
On Jul 16, 2005, at 11:20 AM, Tim Bray wrote:
I got an email last night from a well known syndication implementor
pointing out an obvious bug in my Atom feed. The feed's valid, but
the stuff in content was full of relative URIs which were broken
because I'd borked the xml:base. So I
Paul assures me that the remaining IETF process steps will not
introduce material technical changes, and so format-10 is appropriate
as a basis for implementors to go to work. So, implementors... to
work. And everyone, now is a good time to tell the world. -Tim
On Jul 15, 2005, at 8:56 AM, Walter Underwood wrote:
--On July 14, 2005 11:37:05 PM -0700 Tim Bray
[EMAIL PROTECTED] wrote:
So, implementors... to work.
Do we have a list of who is implementing it? That could be used in
the Deployment section of http://www.tbray.org/atom/RSS
On Jul 15, 2005, at 12:35 PM, Robert Sayre wrote:
http://feedvalidator.org/check.cgi?url=http%3A%2F%
2Fwww.fondantfancies.com%2Fblog%2Fatom1%2F
Hmm... the feed looks OK to me; I wouldn't be surprised if it's
tickling a bug in the just-barely-into-beta Atom 1.0 feedvalidator
code. -Tim
co-chair-mode
The Atom Format draft was considered by the IESG today, and there
remain some outstanding DISCUSS issues, see:
https://datatracker.ietf.org/public/pidtracker.cgi?
command=print_ballotballot_id=1681filename=draft-ietf-atompub-format
On Jul 6, 2005, at 3:28 PM, Paul Hoffman wrote:
Greetings again. I gravely misunderstood XML Canonicalization, and
as it has been explained to me now, XML Canonicalization would be a
disaster for Atom: what we want is Exclusive XML Canonicalization.
Urgh, I should have caught this.
On Jul 5, 2005, at 8:58 AM, Bob Wyman wrote:
We can debate what it means to have an interoperability issue,
however, my personal feeling is that if systems are forced to break
and
discard signatures in order to perform usual and customary
processing on
entries that falls very close to
On Jul 5, 2005, at 9:27 AM, James M Snell wrote:
Huh?! Pardon my ignorance, could you please provide an
explanation for the simple-minded as to how the absence of a
source element in a signed entry will lead to signatures being
discarded? Also, it would be helpful to sketch in some of
On Jul 5, 2005, at 12:50 PM, Walter Underwood wrote:
I'm fine with the delay. Two or three weeks on top of 18 months is
not a big deal.
I am *not*. It's not two or three weeks, it's some
uncontrollable time in the future versus now. We have spent way
too long already. -Tim
On Jul 5, 2005, at 1:05 PM, David Powell wrote:
Will we still be fixing some of bugs raised since the last draft
though?
Definitely. A number of things have been pointed out as bugs,
there's been no WG pushback on any of them, and since we were going
to have to have a -10 draft anyhow
On Jul 5, 2005, at 4:08 PM, Paul Hoffman wrote:
Intermediaries such as aggregators may need to add an atom:source
element to an entry that does not contain its own atom:source
element. If such an entry was signed, the addition will break the
signature. Thus, a publisher of
On Jul 4, 2005, at 7:38 PM, Bob Wyman wrote:
I believe it would be very useful to specify that signed entries
should include a source element. This can/should be considered
part of entry canonicalization.
-1. Leave it to the market. I suspect that you're right, but I'd be
On Jun 30, 2005, at 6:26 PM, Paul Hoffman wrote:
Greetings again. Russ Housley, one of the two Security Area
Directors, has placed a discuss vote on the Atom format document.
You can read it at https://datatracker.ietf.org/public/
pidtracker.cgi?command=view_commentid=36890.
On Jun 23, 2005, at 7:18 AM, Paul Hoffman wrote:
In other words, this isn't bad news, just a delay.
Fully disagree. The world has many implementors eagerly awaiting the
arrival of Atom so they can start using it. If there are problems
that require repair, I don't want to wait two more
On Jun 23, 2005, at 9:12 AM, Eric Scheid wrote:
If there are problems
that require repair, I don't want to wait two more weeks to find out
about them. This is very disappointing. -Tim
we can start with these two...
https://datatracker.ietf.org/public/pidtracker.cgi?
On Jun 22, 2005, at 11:55 AM, James M Snell wrote:
Note that I am not trying to change Atom's model or the core spec,
We do agree on Paul's suggested changed saying it's OK to sign
entries though, I think.
I am trying to define an Atom extension that is capable of meeting
a specific
On Jun 22, 2005, at 12:03 PM, James M Snell wrote:
I'm planning to write a separate Internet-Draft that discusses
digital signing of Atom feeds and entries. Some parts of that
document will includes mandates; other parts will include
recommendations. We can describe for entry producers
On Jun 18, 2005, at 8:00 AM, David Powell wrote:
Friday, June 17, 2005, 6:14:38 PM, Tim Bray wrote:
My feeling was that we ruled out composite types in *local* content
[...]
I'm still looking, but my suspicion is that we never did rule them
out, and that this restriction crept
On Jun 18, 2005, at 1:15 PM, Domel wrote:
How many drafts will you planing to publish to Atom 1.0?
That depends on what the IESG says at their meeting of June 23rd. If
they say OK there will be a last draft to fix some typos and bugs
that people have turned up in -09 and include the
Uh, has Mark spotted a dumb bug here that we should fix? Do we care
if *remote* content is of a composite MIME type? My feeling was that
we ruled out composite types in *local* content, for fairly obvious
reasons. The fix is obvious, in 4.1.3.1
Failing that, it MUST be a MIME media
On Jun 9, 2005, at 9:22 AM, David Powell wrote:
Apologies for the rubbish timing, but I've been reviewing section
6, and found a
number of problems.
Firstly, there are some mismatches between the RelaxNG grammar and the
specification text. I know that the RelaxNG grammar isn't
normative;
On Jun 2, 2005, at 10:37 AM, Greg Smith wrote:
Can you point to a link describing maybe the process
and specifically the structure, format, and submission
guidelines for official documents such as a Pace.
Don't know of such a link, so here's how it works.
Well, go to the wiki (starting at
On May 28, 2005, at 2:09 PM, John Panzer wrote:
entry
titlethe minimal Atom Entry/title
summaryA minimal entry has only .../summary
content type=application/atom+xml
entry
...
/entry
Or perhaps:
feed
On May 27, 2005, at 11:23 AM, James M Snell wrote:
In general, the idea of associating the signing keys with the
network resource (feed or entry document URI) makes a lot of sense
but I think there may be some issues there with aggregate feeds and
intermediaries (e.g. Feedburner) that
co-chair-mode
On behalf of Paul and myself: This is it. The initial phase of the
WG's work in designing the Atompub data format specification is
finished over, pining for the fjords, etc. Please everyone reach
around and pat yourselves on the back, I think the community will
generally
co-chair-mode
As we get ready to buckle down on the Atom Publishing Protocol draft,
we're doing some editor-shuffling. With thanks to Rob Sayre for his
excellent work up through protocol-04, we're shifting from Rob-and-
Joe to Joe Gregorio and Bill de hÓra as co-editors of the Atom
The level of traffic in recent days have been ferocious, and reading
through it, we observe the WG has consensus on changing the format
draft in a surprisingly small number of areas. Here they are:
1. The restriction that atom:author can appear only once is removed.
2. The draft should
On May 25, 2005, at 1:40 PM, David Powell wrote:
What is section 6.3 unknown foreign markup for?
I think the notion of foreign markup exists so that we can write the
extremely-important section 6.3, our MustIgnore assertion. The point
is, either software knows what to do with an
On May 25, 2005, at 1:49 PM, Graham wrote:
Atom Processors should be aware of the potential for denial of
service attacks where the attacker publishes an atom:entry with
the atom:id value of an entry from another feed, and perhaps with
a falsified atom:source element duplicating the
On May 24, 2005, at 1:25 AM, Graham wrote:
First off: it is an error to lie about your
media-type, so I would change SHOULD be suitable for
handling as the indicated media type to MUST be
suitable for handling as the indicated media type.
+1
I'm tempted to agree but can't, because the
On May 24, 2005, at 10:43 AM, Graham wrote:
I also think removing that piece of text makes it unclear that the
element is normally empty.
+1 -Tim
co-chair-modeWe observe a significant amount of discomfort with the
current one-author/multiple-contributors model in atom-format.
Despite the mentions that Rob dug up, nobody can claim this has had
serious in-depth discussion in the IETF context.
On the other hand, we note that the
On May 23, 2005, at 2:43 AM, Graham wrote:
* When @type=html then the content of the element is a xsd:string
[1] of an HTML DIV element plus optional insignificant whitespace
around it. Which version of HTML is defined? How do you
differentiate between HTML 4.01, HTML 3.2, the upcoming HTML
On May 23, 2005, at 5:18 AM, Graham wrote:
On 23 May 2005, at 1:09 pm, Robert Sayre wrote:
Fully disagree. Try a record album by the Rolling Stones or
Grandmaster Flash and The Furious 5. OK to list the band members as
contributors? Definitely.
Maybe there's a minor bug in the wording
On May 23, 2005, at 7:45 AM, James Aylett wrote:
Baking it into the
spec strikes me as needlessly creating rules - we can be precise about
what the semantics are without this rule, IMHO.
+1 -Tim
1 - 100 of 253 matches
Mail list logo
