Tim Bray wrote:
> 5. rework the last paragraph of 4.1.3.2. First of all, the
> description involving "text/" and "+xml" needs fixing per Thomas
> Broyer's work (see http://www.imc.org/atom-syntax/mail-archive/
> msg15444.html), [...]
What about the list items in 4.1.3.3 (see [1])?
Anw how about
Graham wrote:
> With the Pace, try transporting this:
> Text
>
> Wrap it in a div:
>
>
> Decode it:
> Text
>
> Oops, we've thrown data away. Whether the change is significant or not
> isn't important. As a user, I expect to be able to type something in
> at one end and have it reliably
Henri Sivonen,
> > If the intended Atom content contains essential comments,
>
> There should be no such thing as essential comments. The XML spec does
> not require XML processors to report comments to the app. Hence,
> comments are inappropriate for transferring essential data.
Yes, but MSI
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 atom
Please forgive me for stepping in here, because of the recent list
volume I've only been able to partially pay attention to this
discussion, but I just wanted to make a quick observation..
Ignoring the overhead that it adds for now, isn't this the kind of
situation digital signatures are des
Wednesday, May 25, 2005, 10:04:52 PM, Tim Bray wrote:
> 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 extension and does it,
> or if not it's not allowed
> Section 6.4:
> The RNGs in this section require Extension Elements to be in a
> namespace that isn't the Atom namespace. This requirement is missing
> from the text.
Just a note:
This proposal doesn't rehash the
"extensions -- Atom NS and unprefixed attributes" thread [1], because it
only ap
Tim Bray wrote:
Have I missed any? Yes, there has been high-volume debate on several
other issues; but have there been any other outcomes where we can
reasonably claim consensus exists? -Tim
Good summary, thank you.
cheers
Bill
On 25 May 2005, at 10:05 pm, Antone Roundy wrote:
But is it not potentially a DOS? The Good Guy publishes an entry.
The Bad Guy copies the atom:id of that entry into an entry with
different content, gives it a later atom:updated, and publishes
it. The aggregator stops publishing/display
Wednesday, May 25, 2005, 10:04:52 PM, Tim Bray wrote:
> 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 asserti
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 a
On Wednesday, May 25, 2005, at 02:49 PM, Graham wrote:
On 25 May 2005, at 9:01 pm, Antone Roundy wrote:
8.5 Denial of Service Attacks
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
On Wednesday, May 25, 2005, at 02:26 PM, Henry Story wrote:
Since the referents of "Superman" and "Clark Kent" are the same, what
is true of the one,
is true of the other. When speaking directly about the world, we can
replace any occurrence
of Superman with Clark Kent, and still say somethin
On 25 May 2005, at 9:01 pm, Antone Roundy wrote:
8.5 Denial of Service Attacks
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
Tuesday, May 24, 2005, 9:28:09 PM, Tim Bray wrote:
> On the one hand I agree with Graham; this does feel like a
> substantial change. On the other, it's hard to see that having stuff
> inside would do any damage; I best most software would never
> notice it. Having said that, I don't agree th
On 5/25/05, Tim Bray <[EMAIL PROTECTED]> wrote:
> Have I missed any? Yes, there has been high-volume debate on several
> other issues; but have there been any other outcomes where we can
> reasonably claim consensus exists?
Not in my opinion. Looks good to me.
Robert Sayre
On 25 May 2005, at 21:06, Antone Roundy wrote:
* The accepted language does not speak of the origin feed of the
entries. Ideally, an atom:id should be univerally unique to one
entry resource, and we rightly require publishers to mint them with
that goal. However, in reality, malicious or
--On Wednesday, May 25, 2005 11:03:46 AM -0700 Tim Bray <[EMAIL PROTECTED]>
wrote:
Have I missed any? Yes, there has been high-volume debate on several
other issues; but have there been any other outcomes where we can
reasonably claim consensus exists?
Changing atom:author to atom:creator?
On Wednesday, May 25, 2005, at 01:20 PM, Graham wrote:
On 25 May 2005, at 7:35 pm, Antone Roundy wrote:
"If multiple atom:entry elements originating in the same Atom feed
have the same atom:id value, whether they exist simultaneously in one
document or in different instances of the feed docum
At 2:38 PM -0400 5/25/05, Bob Wyman wrote:
I'd like to suggest that we explicitly invite the IPTC
folk to propose a set of Atom extensions (that would include ByLine)
with the intention that these extensions would incorporate their
detailed knowledge of the publishing world and fac
On 26/5/05 5:20 AM, "Graham" <[EMAIL PROTECTED]> wrote:
> (Also, do we have a definition for "Atom feed" that exists beyond a
> single instance of a "feed document"?)
we should have, but we don't.
similarly for "Atom Entry".
e.
On 25 May 2005, at 7:35 pm, Antone Roundy wrote:
"If multiple atom:entry elements originating in the same Atom feed
have the same atom:id value, whether they exist simultaneously in
one document or in different instances of the feed document, they
describe the same entry."
I'm going to w
On Wednesday, May 25, 2005, at 12:35 PM, Antone Roundy wrote:
I'm going to write a Pace right now, in case that will make any
difference.
Here it is--now comments on that particular detail can be directed at a
proper Pace:
http://www.intertwingly.net/wiki/pie/PaceDuplicateIdsEntryOrigin
==
On Wednesday, May 25, 2005, at 12:03 PM, Tim Bray wrote:
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:
All looks good (or at least entirely
I’ve spent an interesting day
in Amsterdam at
the IPTC News Summit and had a chance to talk about standards convergence
issues with various folk in the IPTC (owners of NewsML, NITF, EventsML,
SportsML, ANPA, etc.). These folk seem sincerely interested in getting some
better worked out compa
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 in
Le 05-05-25 à 13:13, Mark Pilgrim a écrit :
On 5/24/05, Karl Dubost <[EMAIL PROTECTED]> wrote:
Validation is something very precise. It can be validated against a
DTD, or against a Schema or another grammar language, etc. At least
the "Feed validator" could become a "Feed checker" which devel
On 5/24/05, Karl Dubost <[EMAIL PROTECTED]> wrote:
> Validation is something very precise. It can be validated against a
> DTD, or against a Schema or another grammar language, etc. At least
> the "Feed validator" could become a "Feed checker" which develops a
> heuristic to check if the requireme
On 25/5/05 2:45 PM, "Eric Scheid" <[EMAIL PROTECTED]> wrote:
>> I agree with this. I thought it was unusual to name a tag after a specific
>> technology rather than its intent (atom:email is an exception). In this
>> instance, I think atom:name, atom:resource, or atom:link works better.
>
> +1
On 25 May 2005, at 2:25 pm, Asbjørn Ulsberg wrote:
What about atom:[EMAIL PROTECTED], then?
No, I want multiple uris. I've just checked the spec and noticed it
doesn't allow them. Why? Shouldn't I be able to have an http: uri and
an aim: uri? And couldn't email be a mailto: uri?
+1 to r
On Wed, 25 May 2005 14:53:05 +0200, Graham <[EMAIL PROTECTED]> wrote:
-1 to "atom:link" unless they are proper link elements.
What about atom:[EMAIL PROTECTED], then?
I'm fairly happy with the current situation.
Okay, but do you agree that the atom:uri element is a bit inconsistent
with
On Tue, May 24, 2005 at 01:54:20PM -0400, Karl Dubost wrote:
> >The implication (and I think it's pretty clear, but perhaps I'm used
>
> Implication :) You just name it and that's the source of lng
> (endless) discussions when specs are released.
As I said, I'm probably more used to IETF-
-1 to "atom:link" unless they are proper link elements. I'm fairly
happy with the current situation.
Graham
On 25/5/05 6:57 PM, "Asbjørn Ulsberg" <[EMAIL PROTECTED]> wrote:
> Consistency makes the format easier to understand and learn. Isn't that
> something worth stribing (and thus changing) for?
+1
On Wed, 25 May 2005 06:45:29 +0200, Eric Scheid
<[EMAIL PROTECTED]> wrote:
In this instance, I think atom:name, atom:resource, or atom:link works
better.
+1 atom:link
I think atom:[EMAIL PROTECTED] works even better. Thinking of what information
is stored in atom:uri and how it is use
Thomas Broyer wrote:
Bill de hÓra wrote:
Thomas Broyer wrote:
* it is not less reliably implementable than the current draft's
mandatory div element; if we go for a SHOULD or MAY on discarding
the div elements, it is even *more* reliably implementable.
We had a discussion about optional
On 24 May 2005, at 2:41 pm, Thomas Broyer wrote:
Oops, before it'd be misinterpreted:
* the Pace is not *complete*
* it is not less reliably implementable than the current draft's
mandatory
div element; if we go for a SHOULD or MAY on discarding the div
elements,
it is even *more*
Bill de hÓra wrote:
> Thomas Broyer wrote:
>> * it is not less reliably implementable than the current draft's
>>mandatory div element; if we go for a SHOULD or MAY on discarding
>> the div elements, it is even *more* reliably implementable.
>
> We had a discussion about optional div not so l
On May 25, 2005, at 06:43, James Cerra wrote:
If the intended Atom content contains essential comments,
There should be no such thing as essential comments. The XML spec does
not require XML processors to report comments to the app. Hence,
comments are inappropriate for transferring essenti
On May 25, 2005, at 06:46, James Cerra wrote:
fter being processed by a XML processor, any entites should be
dereferenced to
their text values and placed into the document tree. So this:
would become the text string:
No. It becomes a tree:
Element atom:c
On May 24, 2005, at 23:44, Paul Hoffman wrote:
So why are we discussing where the Atom format document doesn't match
up to W3C test specification guidelines?
Atom has been advertised as "thoroughly specified" before it is even
known what exactly the upcoming RFC will specify. Assessing the l
On May 24, 2005, at 20:54, Karl Dubost wrote:
A feed validator doesn't have to use a schema, but it could use it for
a non-normative check ("you may have problems" - or even kicking in
more lengthy checking code only when the schema is violated). This is
up to the validator authors.
Validatio
A. Pagaltzis wrote:
> * Thomas Broyer [2005-05-24 15:15]:
>> A. Pagaltzis wrote:
>> > * Thomas Broyer [2005-05-24 09:05]:
>> >> c)
>> >> feed:
>> >> author: A
>> >> contributor: B
>> >> entry:
>> >> contributor: C
>> [...]
>> >> c) The entry inherits the author but overrides the
>> >>
43 matches
Mail list logo
