Re: Last Call: 'The Atom Syndication Format' to Proposed Standard

On Apr 29, 2005, at 12:17, Martin Duerst wrote: Making this more precise is definitely desirable. But there is also an i18n issue: This works fine for languages that use spaces between words. It doesn't work for languages that don't have spaces between words (Chinese, Japanese, Thai,...). If Text e

Re: Autodiscovery

On 5/4/05, Henri Sivonen <[EMAIL PROTECTED]> wrote > No you don't. rel='license' and rel='nofollow' have been deployable > without a profile. You just release running code that hard-codes > rel='feed' and, boom, no profile needed. Then I'm confused as to why you can't just release running code th

Re: Autodiscovery

On May 4, 2005, at 06:50, Phil Ringnalda wrote: 1) Change the attribute value for the rel from "alternate" to "feed", Don't forget, since you would be doing that primarily for people who think too much, that you'll also need to include a profile [1] URI No you don't. rel='license' and rel='nofollo

Re: Autodiscovery

On May 4, 2005, at 02:56, David Nesting wrote: Plus, "feed" is kind of application-specific. What about "related"? It's a spec for discovering *feeds*. It is proper to have an app-specific rel value to avoid feed-specific apps downloading non-feed related documents. -- Henri Sivonen [EMAIL PROT

Re: Autodiscovery

Phil Ringnalda wrote: > > Arve Bersvendsen wrote: > On Tue, 03 May 2005 18:52:59 +0200, Tim Bray <[EMAIL PROTECTED]> wrote: http://diveintomark.org/rfc/draft-ietf-atompub-autodiscovery-01.txt 1) Change the attribute value for the rel from "alternate" to "feed", Don't forget, since you would be do

Re: Autodiscovery

David Nesting wrote: I expect that many of my implementations will utilize content negotiation (using the same URL as an HTML representation, where needed), so I expect that I'll have some links like: Or even That won't work, because content negotiation will continue to return the same

Re: Autodiscovery

Arve Bersvendsen wrote: On Tue, 03 May 2005 18:52:59 +0200, Tim Bray <[EMAIL PROTECTED]> wrote: http://diveintomark.org/rfc/draft-ietf-atompub-autodiscovery-01.txt 1) Change the attribute value for the rel from "alternate" to "feed", or some similar wording. A feed is not always an alternate of

Re: Autodiscovery

David Nesting wrote: On Tue, May 03, 2005 at 07:42:55PM +0200, Arve Bersvendsen wrote: 1) Change the attribute value for the rel from "alternate" to "feed", or some similar wording. A feed is not always an alternate of the HTML document in which it occurs. Suggested replacement text: I'm all f

Re: AutoDiscovery

Randy Charles Morin wrote: +1 to not Atom specific thanks Arve -1 to anything that even remotely implies any significance to @title Phil Ringnalda

Re: Autodiscovery

Arve Bersvendsen wrote: First, I am not too fond of making an autodiscovery protocol "Atom-only" It's only Atom-only in that it doesn't attempt to dictate things outside the WG's charter: as it's written now, it's just a well-specified exact equivalent of the existing RSS autodiscovery spec-blog-

pie/ecto/atom/rss

I've noticed the new version of Safari never mentions "Atom" in its UI, always referring to it as "RSS". A friend of a friend has a website that labels its Atom and RSS feeds "RSS feed" and "RSS feed (Non-Atom)" respsectively. Is the working group concerned about this usage? Graham

Re: AutoDiscovery

+1 to adding lang as an attribute to link thanks Robert http://www.kbcafe.com

Re: Autodiscovery

On 4/5/05 3:42 AM, "Arve Bersvendsen" <[EMAIL PROTECTED]> wrote: > 1) Change the attribute value for the rel from "alternate" to "feed", or ... > 2) I am not too fond of requiring a type attribute I suspect the requirement for @type was because of the choice of 'alternate' as the trigger, and th

Re: Autodiscovery

On Tue, May 03, 2005 at 07:42:55PM +0200, Arve Bersvendsen wrote: > > 1) Change the attribute value for the rel from "alternate" to "feed", or > some similar wording. A feed is not always an alternate of the HTML > document in which it occurs. Suggested replacement text: I'm all for avoidin

Re: PaceDuplicateIDWithSource2

Martin Duerst wrote: I'm not really happy with this. Conceptually, it seems to replace an ID for an entry with a pair (ID,feed). As IDs are URIs/IRIs (remember what they expand to), that doesn't make sense. What guarantee do we have that two feeds will be different? (yes, these days, we get feeds o

Re: Getting atom:source right

On Tuesday, May 3, 2005, at 09:04 AM, Asbjørn Ulsberg wrote: On Mon, 02 May 2005 23:13:06 +0200, Antone Roundy <[EMAIL PROTECTED]> wrote: Should we add something like this? If an atom:entry element already containing an atom:source element is copied to another feed, the contents of t

Re: Autodiscovery

On May 3, 2005, at 10:33 AM, Scott Hollenbeck wrote: I've privately asked Tim and Paul the same question. Though section 6.3 of RFC 2418 doesn't specifically say that a document editor MUST be a member of the working group, the situation appears so obvious that it shouldn't need to be stated. O

Re: Last Call: 'The Atom Syndication Format' to Proposed Standard

On 28 Apr 2005, at 7:33 pm, Alexey Melnikov wrote: Ok, maybe it is just me, but what does it mean to "collapse white- space"? Does this mean to replace FWS (in RFC 2822 sense) with a single space? Since the statement is a MAY, I don't think any exact meaning is necessary. It's simply a hint to

Re: Autodiscovery

On Tue, 03 May 2005 18:52:59 +0200, Tim Bray <[EMAIL PROTECTED]> wrote: http://diveintomark.org/rfc/draft-ietf-atompub-autodiscovery-01.txt http://diveintomark.org/rfc/draft-ietf-atompub-autodiscovery-01.html http://diveintomark.org/rfc/draft-ietf-atompub-autodiscovery-01.xml Although Mark's not su

RE: Autodiscovery

> -Original Message- > From: Bill de hÓra [mailto:[EMAIL PROTECTED] > Sent: Tuesday, May 03, 2005 1:18 PM > To: atom-syntax Syntax' > Subject: Re: Autodiscovery > > > > Tim Bray wrote: > > > Assuming no errors, or rather that any errors we turn up > are fixed, are > > there any obje

Re: Last Call: 'The Atom Syndication Format' to Proposed Standard

Martin Duerst wrote: At 03:33 05/04/29, Alexey Melnikov wrote: > > If the value is "text", the content of the Text construct MUST NOT > > contain child elements. Such text is intended to be presented to > > humans in a readable fashion. Thus, Atom Processors MAY collapse > > white-spa

Re: Autodiscovery

On 3 May 2005, at 5:52 pm, Tim Bray wrote: I scanned them and nothing objectionable leapt out at me, but please, could a few more people also have a look? The only thing I noticed was the href attribute definition: "The value MAY be a relative URI, and if so, clients MUST resolve it to a full U

Re: Autodiscovery

Tim Bray wrote: Assuming no errors, or rather that any errors we turn up are fixed, are there any objections to us submitting this I-D as a product of the Atompub WG? -Tim How do we manage a WG product produced and edited by a non-WG member? This isn't an objection, btw, I'm just curious about t

Re: Autodiscovery

On 5/3/05, Tim Bray <[EMAIL PROTECTED]> wrote: > I scanned them and nothing objectionable leapt out at me, but please, > could a few more people also have a look? I've never liked the rules in section 6. For example, when presenting a single option from multiple link elements, UAs should be perm

Re: hreflang attribute should be allowed to be empty as well

Anne van Kesteren wrote: I think that the HREFLANG attribute[1] should be allowed to be empty as well, just like xml:lang is allowed to be empty. xml:lang is allowed to be empty to override a previous, inherited, xml:lang declaration without specifying a new language. As xml:lang doesn't apply t

Re: Autodiscovery

Tim Bray wrote: Mark Pilgrim agreed to turn his Atom autodiscovery draft into a WG draft, and has done so, see: http://diveintomark.org/rfc/draft-ietf-atompub-autodiscovery-01.txt http://diveintomark.org/rfc/draft-ietf-atompub-autodiscovery-01.html http://diveintomark.org/rfc/draft-ietf-atompub-a

Autodiscovery

Mark Pilgrim agreed to turn his Atom autodiscovery draft into a WG draft, and has done so, see: http://diveintomark.org/rfc/draft-ietf-atompub-autodiscovery-01.txt http://diveintomark.org/rfc/draft-ietf-atompub-autodiscovery-01.html http://diveintomark.org/rfc/draft-ietf-atompub-autodiscovery-01.

Re: PaceXhtmlDivSuggestedOnly

Martin Duerst wrote: > > At 04:14 05/05/02, Julian Reschke wrote: > >+1 on properly distinguishing between block-level and in-line > > +0.5 here, the CSS display property can change things easily. So this is OK for you? This is a title ...with block-level content. -- Thomas Broye

Re: Last Call: 'The Atom Syndication Format' to Proposed Standard

On 4/29/05, Martin Duerst <[EMAIL PROTECTED]> wrote: > At 03:33 05/04/29, Alexey Melnikov wrote: > > > >Ok, maybe it is just me, but what does it mean to "collapse white-space"? > Does this mean to replace FWS (in RFC 2822 sense) with a single space? > > Making this more precise is definitely d

Re: Getting atom:source right

On 2 May 2005, at 10:13 pm, Antone Roundy wrote: Should we add something like this? If an atom:entry element already containing an atom:source element is copied to another feed, the contents of the atom:source element MUST NOT be replaced with metadata from the containing atom:f

ADMINISTRIVIA: another mail loop

Expect to see at least a couple of more duplicates of recent messages on the list. This one comes courtesy of Xerox. The offending user has been removed from the mailing list and been told of the problem. --Paul Hoffman, Director --Internet Mail Consortium

Re: editorial suggestion (draft 08): "date-time" format

On 5/3/05, Isofarro <[EMAIL PROTECTED]> wrote: > > Suggest that you list an example or two of the date formats allowable. > Saves readers hunting down an example and missing the explicit mention > of which format. Agree. Will do. Robert Sayre

Re: Last minute editorial suggestions

On 5/2/05, Graham <[EMAIL PROTECTED]> wrote: > > - In section 4.2.4 there's an obsolete reference to atom:head > > - In section 3.1.1.3, the text "The XHTML div element itself MUST NOT > be considered part of the content" is inadequate. Replace with (or > add): "The intended value of the content

Re: hreflang attribute should be allowed to be empty as well

On 5/3/05, Anne van Kesteren <[EMAIL PROTECTED]> wrote: > > I think that the HREFLANG attribute[1] should be allowed to be empty as > well, just like xml:lang is allowed to be empty. Why would we want that? xml:lang uses the empty string to halt inheritance, if necessary. hreflang doesn't have t

Re: Getting atom:source right

On Mon, 02 May 2005 23:13:06 +0200, Antone Roundy <[EMAIL PROTECTED]> wrote: Should we add something like this? If an atom:entry element already containing an atom:source element is copied to another feed, the contents of the atom:source element MUST NOT be replaced with metada

Re: hreflang attribute should be allowed to be empty as well

On Tue, 03 May 2005 13:11:51 +0200, Anne van Kesteren <[EMAIL PROTECTED]> wrote: I think that the HREFLANG attribute[1] should be allowed to be empty as well, just like xml:lang is allowed to be empty. I'm +1 to this. It makes sense. -- Asbjørn Ulsberg -=|=-http://virtuelvis.com/quark/

hreflang attribute should be allowed to be empty as well

I think that the HREFLANG attribute[1] should be allowed to be empty as well, just like xml:lang is allowed to be empty. [1] -- Anne van Kesteren

editorial suggestion (draft 08): "date-time" format

In section 3.3 titled "Date Constructs" 3.3 Date Constructs A Date construct is an element whose content MUST conform to the "date-time" production in [RFC3339]. In addition, an uppercase "T" character MUST be used to separate date and time, and an uppercase "Z" character MUST be pres

Re: PaceXhtmlDivSuggestedOnly

At 04:14 05/05/02, Julian Reschke wrote: > >For the record...: > >+1 on not requiring wrapper elements +1 here, too. >+1 on properly distinguishing between block-level and in-line +0.5 here, the CSS display property can change things easily. Regards, Martin. >+1 on using the same recommendations

Re: Last Call: 'The Atom Syndication Format' to Proposed Standard

At 03:33 05/04/29, Alexey Melnikov wrote: >>The file can be obtained via >>http://www.ietf.org/internet-drafts/draft-ietf-atompub-format-08.txt > >3.1.1.1 Text > > If the value is "text", the content of the Text construct MUST NOT > > contain child elements. Such text is intended to be presen

Re: PaceDuplicateIDWithSource2

I'm not really happy with this. Conceptually, it seems to replace an ID for an entry with a pair (ID,feed). As IDs are URIs/IRIs (remember what they expand to), that doesn't make sense. What guarantee do we have that two feeds will be different? (yes, these days, we get feeds over http, but there a