On Sat, 29 Jan 2005 16:47:09 +1100, Eric Scheid
<[EMAIL PROTECTED]> wrote:
Maybe "image" is the wrong name for the concept. We're not talking about
some random image associated with some entity, we're talking about a
branding badge or logo of some kind which is representative of the feed.
I know
nitpickers welcome.
I have this spec text in my draft Pace...
> atom:head elements MAY contain one or more atom:foo elements, so
> long no two atom:foo elements have the same combination of
> atom:hreflang, xml:lang, or atom:type.
I also considered writing it like this...
> atom:head e
On Wed, 26 Jan 2005 21:39:34 -0500, Sam Ruby <[EMAIL PROTECTED]>
wrote:
There are now, by some counts, ten versions of formats that call
themselves RSS. Every last one of then has a required channel/link.
Every last one of them.
Yes.
Relaxing a restriction requires consumers to handle more case
On 29/1/05 4:22 PM, "Asbjørn Ulsberg" <[EMAIL PROTECTED]> wrote:
>> http://www.intertwingly.net/wiki/pie/PaceIconAndImage
>
> Nice. But if we have both atom:icon and atom:image for the feed, why do we
> need to do all kinds of wierd stuff to have images attached to Atom
> entries? Can't atom
On Wed, 26 Jan 2005 07:53:33 -0800, Tim Bray <[EMAIL PROTECTED]> wrote:
"Software which discovers that the FeedLink URI is different from that
used to retrieve the atom:feed document containing MAY choose to use
the FeedLink URI for subsequent fetches."
Nicely put. +1.
--
Asbjørn Ulsberg -=|=-
On Thu, 27 Jan 2005 09:08:34 -0700, Antone Roundy <[EMAIL PROTECTED]>
wrote:
While I agree with this sentiment, the working group has rejected
attempts to add language to the spec to limit the use of , so I
assume we do not have consensus on the desire to limit it's usage. So
that's not n
On Thu, 27 Jan 2005 22:12:41 +1100, Eric Scheid
<[EMAIL PROTECTED]> wrote:
http://www.intertwingly.net/wiki/pie/PaceIconAndImage
Nice. But if we have both atom:icon and atom:image for the feed, why do we
need to do all kinds of wierd stuff to have images attached to Atom
entries? Can't a
On Fri, 28 Jan 2005 17:13:26 -0800, Paul Hoffman <[EMAIL PROTECTED]> wrote:
Many elements are consider 'unsafe' in that they open clients to one or
more types of attack. Every client should consider carefully their
handling of every type of element when processing incoming (X)HTML in
Text Con
On Fri, 28 Jan 2005 13:21:08 -0800, Tim Bray <[EMAIL PROTECTED]> wrote:
Whereas you could technically get by with warning-by-reference, I think
that it's OK and fact probably essential to point out that and
On Fri, 28 Jan 2005 17:01:06 -0500, Robert Sayre <[EMAIL PROTECTED]>
wrote:
I guess the question is whether we can and should outline HTML security
issues. I don't think we can or should.
Considering the large amount of (X)HTML that are being syndicated via RSS
and Atom today and will be in
On Fri, 28 Jan 2005 12:30:20 +0200, Henri Sivonen <[EMAIL PROTECTED]> wrote:
It would be inapropriate to forbit declaring the same namespace in
multiple ways, but the div is still cruft and unnecessary for declaring
namespaces, so I think the div shouldn't be required.
I kind of agree. We shoul
> Given the two choices, I actually prefer
> security-by-reference because it points out the similarity of
> what we are doing to other protocols.
I agree. It's also a good practice to have only one authoritative source
that talks about a topic, especially when that source has already been
thr
At 12:56 PM -0800 1/28/05, Tim Bray wrote:
At this point we should appeal to our designated IETF
culture/process experts; Scott/Ted/Paul, any guidance? -Tim
It's up to the WG. If we do a long list, we will probably be told to
make it much longer. If we do security-by-reference, we will probably
Martin Duerst wrote:
The IRI spec is now published as RFC 3987 (Proposed Standard,
http://www.ietf.org/rfc/rfc3987.txt).
The update of the URI spec, known as RFC2396bis, is now published
as STD 66, RFC 3986.
Even less reason for not adopting them. Editors, please update
your references. I'll update
Henri Sivonen wrote:
On Jan 28, 2005, at 20:21, Sam Ruby wrote:
I also don't like the restriction on where namespace declarations must
be placed, but overall, I believe that the pace is a good idea.
I, for one, use gnu.xml.pipeline.NSFilter for ensuring the namespace
correctness in my RSS feed. I
Friday, January 28, 2005, 9:27:11 PM, you wrote:
Sorry, that version created duplicate rdf:nodeIDs. I've fixed it now,
the new version is 9826 bytes.
--
Dave
On Jan 28, 2005, at 20:21, Sam Ruby wrote:
I also don't like the restriction on where namespace declarations must
be placed, but overall, I believe that the pace is a good idea.
I, for one, use gnu.xml.pipeline.NSFilter for ensuring the namespace
correctness in my RSS feed. If the current spec la
On Friday, January 28, 2005, at 02:40 PM, Robert Sayre wrote:
Tim Bray wrote:
On Jan 28, 2005, at 12:55 PM, Robert Sayre wrote:
> I would strike all the details on HTML, leave the first paragraph,
> and refer to the security sections of RFC 2854 and HTML 4.01.
Whereas you could technically get b
Joe Gregorio wrote:
Those two references are woefully inadequate, just compare the threats
they outline versus the ones I outline in the Pace. If there were a
good reference of all the problems that HTML can cause when used in
email, *that* would be more in line with what we need, but I was
unable
On Fri, 28 Jan 2005 15:55:10 -0500, Robert Sayre <[EMAIL PROTECTED]> wrote:
> Graham wrote:
>
> > I don't like stuff like:
> > "All SCRIPT elements should be stripped from Text Constructs or all
> > native
> > scripting support of the (X)HTML display engine should be disabled."
> >
> > I don't th
Tim Bray wrote:
On Jan 28, 2005, at 12:55 PM, Robert Sayre wrote:
> I would strike all the details on HTML, leave the first paragraph,
> and refer to the security sections of RFC 2854 and HTML 4.01.
Whereas you could technically get by with warning-by-reference, I
think that it's OK and fact pro
I've put together an XSLT stylesheet to map Atom to RDF/XML. It is
just as a proof of concept to see if it is possible. I think it
handles everything except for xml:lang - I'm not sure what's happening
with xml:lang at the moment - but it should be possible to add it in a
similar way to xml:base.
On Friday, January 28, 2005, at 01:55 PM, Robert Sayre wrote:
Graham wrote:
I don't like stuff like:
"All SCRIPT elements should be stripped from Text Constructs or all
native
scripting support of the (X)HTML display engine should be disabled."
I don't think you need to should do any more than o
On Jan 28, 2005, at 12:55 PM, Robert Sayre wrote:
I would strike all the details on HTML, leave the first paragraph, and
refer to the security sections of RFC 2854 and HTML 4.01.
Whereas you could technically get by with warning-by-reference, I think
that it's OK and fact probably essential to po
On Jan 28, 2005, at 12:09 PM, Graham wrote:
I don't like stuff like:
"All SCRIPT elements should be stripped from Text Constructs or all
native
scripting support of the (X)HTML display engine should be disabled."
I don't think you need to should do any more than outline the threat
model from eac
Graham wrote:
I don't like stuff like:
"All SCRIPT elements should be stripped from Text Constructs or all
native
scripting support of the (X)HTML display engine should be disabled."
I don't think you need to should do any more than outline the threat
model from each tech. Proscribing how to dea
I don't like stuff like:
"All SCRIPT elements should be stripped from Text Constructs or all
native
scripting support of the (X)HTML display engine should be disabled."
I don't think you need to should do any more than outline the threat
model from each tech. Proscribing how to deal with it is n
I looked at format-05 and found that the security section is still
pretty anemic. Here is my stab at fleshing out that section:
http://www.intertwingly.net/wiki/pie/PaceFormatSecurity:
===
== Abstract ==
Fill out the security section of the format spec.
== Sta
> Given that common practice is to include this element, making it
> mandatory makes things clearer to both people who are producing
> consuming tools based on the spec, and people who are producing new
> feeds based on copy and paste.
+1
--
Roger Benningfield
Julian Reschke wrote:
Sam Ruby wrote:
I also don't like the restriction on where namespace declarations must
be placed, but overall, I believe that the pace is a good idea.
Consumers don't want full web pages (complete with html head and titles)
as summaries, they want something that they can *inse
On 28 Jan 2005, at 6:21 pm, Sam Ruby wrote:
I also don't like the restriction on where namespace declarations must
be placed, but overall, I believe that the pace is a good idea.
Yes.
and it succinctly provides a rather
good hint as to what child elements are valid.
Yes.
I would be OK with either
Sam Ruby wrote:
I also don't like the restriction on where namespace declarations must
be placed, but overall, I believe that the pace is a good idea.
Consumers don't want full web pages (complete with html head and titles)
as summaries, they want something that they can *insert* into a web
page.
Antone Roundy wrote:
On Thursday, January 27, 2005, at 10:38 PM, Henri Sivonen wrote:
On Jan 27, 2005, at 22:30, Antone Roundy wrote:
I'm not in favor of mandating restrictions, because there are
probably legitimate uses for anything we might try to protect people
against.
The namespace div plac
On Thu, 27 Jan 2005 13:30:40 -0700, Antone Roundy <[EMAIL PROTECTED]> wrote:
> As far as the question of CSS and/or elements/tags everywhere, I'd
> think that would be a matter for the security considerations section
> (protecting against the Raging Platypus, for example). Whatever
> restrictions
On 28 Jan 2005, at 15:14, Danny Ayers wrote:
On Thu, 27 Jan 2005 16:10:06 -0500, Robert Sayre
<[EMAIL PROTECTED]> wrote:
http://atompub.org/2005/01/27/draft-ietf-atompub-format-05.html
http://atompub.org/2005/01/27/draft-ietf-atompub-format-05.txt
Thanks Robert. The Relax NG snippets make a *hug
On Thu, 27 Jan 2005 16:10:06 -0500, Robert Sayre <[EMAIL PROTECTED]> wrote:
> http://atompub.org/2005/01/27/draft-ietf-atompub-format-05.html
> http://atompub.org/2005/01/27/draft-ietf-atompub-format-05.txt
Thanks Robert. The Relax NG snippets make a *huge* difference to the
clarity. (Thanks Nor
Eric Scheid wrote:
and this is somewhere in the middle...
Copyright 2005 John Doe, all rights reserved
once you have more than just one set of tags like in there.
The em element does not inherit the namespace of he div. You could have
bound to one namespace, 'h' to another and
37 matches
Mail list logo
