On May 26, 2005, at 06:23, James Cerra wrote:
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 trans
James M Snell wrote:
Ignoring the overhead that it adds for now, isn't this the kind of
situation digital signatures are designed to handle?
Yes. Norm and I have mentioned this as well. I do not think we can solve
this problem by patching the Atom level, ensuring that the Atom level
can b
Part of the reason I went into the detailed explanation I did, is
because not everyone
here may be familiar with mathematical logic. What I was explaining
is a heavy condensation
of what I learned in my BA in philosophy. I am not plucking these
thoughts out of a hat.
So let me apply these
On 26 May 2005, at 7:40 am, Thomas Broyer wrote:
With the current (08) draft, try transporting this textual summary:
This deals with
- feeding cats
- feeding dogs
- feeding fishes
Put it in atom:summary:
This deals with
- feeding cats
- feeding dogs
- feeding fishes
Decode:
This deals
* James Cerra <[EMAIL PROTECTED]> [2005-05-26 05:35]:
> Yes, but MSIE^H^H^H^Hsome xml processors (cough cough) still
> inappropriately use comments for that purpose. Then there are
> example XML documents (i.e. for tutorials) that sometimes
> require comments be preserved.
>
> > Entities can be
* Henri Sivonen <[EMAIL PROTECTED]> [2005-05-26 10:20]:
> On May 26, 2005, at 06:23, James Cerra wrote:
> >Yes, but MSIE^H^H^H^Hsome xml processors (cough cough) still
> >inappropriately use comments for that purpose.
>
> I am not familiar with that. What purpose exactly? Why should
> Atom suppo
* Graham <[EMAIL PROTECTED]> [2005-05-25 23:00]:
> How is this a "Denial of service" attack? Isn't it just
> ordinary spoofing/impersonation?
Indeed; I’d like to see this reworded to refer to “spoofing,” as
that’s what it is.
> Apart from that, +1.
+1 as well; always a good idea to alert people
On Wednesday, May 25, 2005, at 06:14 PM, James M Snell wrote:
Ignoring the overhead that it adds for now, isn't this the kind of
situation digital signatures are designed to handle?
Sure, but how many publishers are going to be using digital signatures
in the near term (and more importantly, h
On Thursday, May 26, 2005, at 08:04 AM, A. Pagaltzis wrote:
* Graham <[EMAIL PROTECTED]> [2005-05-25 23:00]:
How is this a "Denial of service" attack? Isn't it just
ordinary spoofing/impersonation?
Indeed; I’d like to see this reworded to refer to “spoofing,” as
that’s what it is.
I presum
On Wednesday, May 25, 2005, at 01:06 PM, Antone Roundy wrote:
== Abstract ==
State the atom:entries from the same feed with the same ID are the
same entry, whether simulateously in the feed document or not.
I'm retracting this proposal in preference for PaceAtomIdDos, which I
like better a
Antone Roundy wrote:
On Wednesday, May 25, 2005, at 06:14 PM, James M Snell wrote:
Ignoring the overhead that it adds for now, isn't this the kind of
situation digital signatures are designed to handle?
Sure, but how many publishers are going to be using digital signatures
in the near te
>> I've mentioned this several times before and haven't had time to follow the
>> evolvement of the draft up until now, but as far as I can tell, atom:uri is
>> still in place in the specification... Do we really need a pace to have that
>> element renamed before the spec goes final?
>
> -1 to
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 view this as
The atom:author element name is embarrassing. Make it atom:creator.
There were no objections to that.
wunder
--On May 26, 2005 10:26:54 AM -0700 Tim Bray <[EMAIL PROTECTED]> wrote:
>
>
> On behalf of Paul and myself: This is it. The initial phase of the WG's
> work in designing the Atompu
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
protocol draft.
David Powell wrote:
I'm also a bit confused about the terminology in Section 6.3:
It might be the case that the software is able to process the
foreign markup correctly and does so. Otherwise, such markup is
termed "unknown foreign markup".
So "unknown foreign markup" is "foreign ma
Thursday, May 26, 2005, 7:20:23 PM, Thomas Broyer wrote:
>>But then 6.3 goes on to explain how to process it.
>>This sounds like a contradiction?
>>
>>
> No, why?
Ok, I'd interpreted "ignoring" it to be processing it, as opposed to
failing. I'll concede that I misinterpreted that.
> Say I
David Powell wrote:
Thursday, May 26, 2005, 7:20:23 PM, Thomas Broyer wrote:
Say I am an Atom Processor and I find these extensions elements:
26.58
-97.83
Is this something I know how to process?
* yes: this is "known foreign markup", I process it
* no: this is "unknown fo
Thursday, May 26, 2005, 8:50:04 PM, you wrote:
>>6.2 says that new elements and attributes can be added.
>>
> 6.2 deals with the "Atom vocabulary", which is the markup in the Atom
> namespace or un prefixed attributes on Atom-namespaced elements (this is
> my interpretation, it's not clearly sta
On Wed, 25 May 2005 16:17:07 +0200, Graham <[EMAIL PROTECTED]> wrote:
What about atom:[EMAIL PROTECTED], then?
No, I want multiple uris.
Okay, that's a good point.
And couldn't email be a mailto: uri?
Another good point I think the atom:link element could solve pretty nicely.
+1 to rep
David Powell wrote:
Thursday, May 26, 2005, 8:50:04 PM, you wrote:
6.2 deals with the "Atom vocabulary", which is the markup in the Atom
namespace or un prefixed attributes on Atom-namespaced elements (this is
my interpretation, it's not clearly stated in the spec, and I'm quite
sure I alre
On 27/5/05 6:51 AM, "Asbjørn Ulsberg" <[EMAIL PROTECTED]> wrote:
>> +1 to replacing atom:email and atom:uri with multiple real atom:link
>> elements (to allow titles).
>
> Yay. +1.
+1
that's elegant and clean, and seeing as we're unlikely to be seeing many
feeds with email addresses at all it'
James M Snell wrote:
> Well, it comes down to whether the signature is trusted by the
> reader or not. If the signature in the entry is not from the trusted,
> expected source, the user should be able to reject it in favor of the
> unsigned entry.
Clearly, we're going to have to put a goo
Thursday, May 26, 2005, 11:16:05 PM, Thomas Broyer wrote:
> David Powell wrote:
>>Thursday, May 26, 2005, 8:50:04 PM, Thomas Broyer wrote:
>>
>>>6.2 deals with the "Atom vocabulary", which is the markup in the Atom
>>>namespace or un prefixed attributes on Atom-namespaced elements (this is
>>>m
At 7:16 PM -0400 5/26/05, Bob Wyman wrote:
The only mechanism that we would need in order to allow feeds to
sign their content would be a means to associate a signing key with a feed
or set of feeds. This could be done in one of two ways:
* The traditional indirect manner of havi
On 27/5/05 4:14 AM, "Tim Bray" <[EMAIL PROTECTED]> wrote:
> protocol-04
btw, where can we find it?
e.
Paul Hoffman wrote:
> It is much better to say "..having feeds, not people, be
> associated with keys...". That is, the identifier that is
> associated with the key is a URI of the feed, not a person
> or company name.
You are, of course, correct. My apologies for being sloppy and
letting
27 matches
Mail list logo
