Subject: Re: Feed State [was: Work Queue Rotation #16]

From: Mark Nottingham <[email-masked]>
Date: Mon, 31 Jan 2005 21:10:36 -0800

On Jan 31, 2005, at 6:27 PM, Paul Hoffman wrote:

> At 3:46 PM -0800 1/31/05, Mark Nottingham wrote:
>> If this is the direction we go in on this, that's fine with me, but I 
>> think that the spec needs to say *something* about managing feed 
>> state,
>
> Why?

Because it's a *very* common use case, but we don't provide any 
guidance on how it's done, which IMO will lead to interoperability 
problems. Since the WG doesn't want to nail this down, I think it's the 
least we could do to point out that there may be dragons there (or at 
least the need for more work).

> What does that add to the document? A MAY with a hint of an extension 
> doesn't seem to add much.

Well, I tried the other way...

--
Mark Nottingham     http://www.mnot.net/

---

From: Mark Nottingham <[email-masked]>
Date: Mon, 31 Jan 2005 21:18:44 -0800

What registry?

I don't think the examples you cite are the common case. The common 
case is "This Feed Document represents the last n entries in an ongoing 
information channel," or "This Feed Document represents entries within 
the last m units of time in an ongoing information channel."

These cases aren't well-supported by Atom, as it stands.

P.S. Feed Document may be somewhat misleading, because it's easy to 
confuse it with Feed (which has connotations of the information 
channel). I think "Feed Snapshot Document" or the like was once 
proposed, but it was shot down. *shrug*

On Jan 31, 2005, at 6:42 PM, Robert Sayre wrote:

> Paul Hoffman wrote:
> I agree with Paul. The proposal doesn't really make sense unless 
> there's a way to distinguish "this feed represents the current weather 
> in Oaxaca" from "the latest entry represents the current weather in 
> Oaxaca". Also, should such a convention arise, it would be easy to add 
> to the registry.
>
> Robert Sayre
>
>
>

---

From: Danny Ayers <[email-masked]>
Date: Tue, 1 Feb 2005 10:50:12 +0100

On Mon, 31 Jan 2005 11:45:25 -0800, Tim Bray <[email-masked]> wrote:
> 
> Atom Public Issues List:
> http://www.intertwingly.net/wiki/pie/AtomPubIssuesList

Regarding PaceExtensionConstruct, PaceAttributesNamespace and Henry's
RDF-related proposals, these got Catch-22'd by the process a little.
The chair wanted actual spec text to enable discussion, but the text
as provided (at least for PaceAttributesNamespace) was more aimed at
alpha version 0.001 ballpark-finding than providing something
voteworthy.

I'll try and have something more workqueue-suitable for
PaceAttributesNamespaces in the next few days.
  
The other decisions look good to me  - they all seem to reflect
discussion accurately (although I somehow missed PaceFeedState...).

Cheers,
Danny.

-- 

http://dannyayers.com

---

From: Eric Scheid <[email-masked]>
Date: Tue, 01 Feb 2005 21:34:38 +1100

> proposed, but it was shot down. *shrug*

"Atom Collection Document" might be even more accurate, as this also suits
temporal period archives or a handpicked set of "best essays of 2004".

If so, perhaps we could change the top level element name from <feed> to
<collection>? Do we need a Pace?

e.

---

From: Martin Duerst <[email-masked]>
Date: Tue, 01 Feb 2005 15:29:08 +0900

Clarifying some details based on my write-manytimes understanding
of IRIs (RFC 3987).

At 07:15 05/02/01, Robert Sayre wrote:
 >
 >Graham wrote:
 >
 >> I don't know much about IRIs. Is it possible to express them as URIs?
 >
 >
 >My read-the-draft-once understanding is that it is always possible to 
convert an IRI to a URI,

Correct.

 > but it may not be possible to convert a URI back to the same IRI it was 
generated from.

Correct.

 >For example, it is always possible to convert an IRI to ASCII for use in 
HTTP's Request-URI, but it would be better to leave it in Unicode for editing.

Exactly.

 >There's also a large section of the draft that deals with right-to-left 
IRIs, but I don't understand it.

It's not relevant for a protocol, but it is relevant for input and display
of IRIs that contain Arabic or Hebrew characters.

Regards,    Martin.

---

From: Martin Duerst <[email-masked]>
Date: Tue, 01 Feb 2005 16:26:01 +0900

At 08:25 05/02/01, DJWS wrote:
 >
 >At 22:25 31/01/2005, Graham wrote:
 >As far as I understand, and this is my problem : I cannot have a formal 
response on the following.
 >- there are various way to support a non ASCII IRI (the majority of the 
world needs them - inclunding French language).
 >- one way is to use Unicode
 >- another way is to use ToASCII and punycode process (used in IDNs)

There is only one IRI spec (RFC 3987). For backwards compatibility,
it allows the use of punycode for converting domain-name parts
of some URIs. Otherwise, it's just converted to %-encoding
using UTF-8, and then the URI spec (RFC 3986) takes over.

 >the punycode process :
 >- is reversible (if it was not, the Domain Name could not be valid).

It is reversible up to equivalent domain names, in particular,
it does not conserve case, if you take stringprep into account.

 >- is used in IDNs in transcoding the Unicode into ascii for 2LD and above 
level and in adding the prefix "xn--".

There is no technical restriction to "2LD and above".
There are some people claiming that it should not be used
for TLDs, but I would disagree. It works for TLDs as well as
for other levels. The difficult problems on the TLD level
are political, but those don't go away with a different
technical solution.

 >- can obvsiously be used to transcode the TLD of a domain name, but there 
is no specification in RFCs about TLDs being punycoded.

I think rfc 3986 is pretty clear about this, and doesn't
make an exception for TLDs. From http://www.ietf.org/rfc/rfc3986.txt:

    The reg-name syntax allows percent-encoded octets in order to
    represent non-ASCII registered names in a uniform way that is
    independent of the underlying name resolution technology.  Non-ASCII
    characters must first be encoded according to UTF-8 [STD63], and then
    each octet of the corresponding UTF-8 sequence must be percent-
    encoded to be represented as URI characters.  URI producing
    applications must not use percent-encoding in host unless it is used
    to represent a UTF-8 character sequence.  When a non-ASCII registered
    name represents an internationalized domain name intended for
    resolution via the DNS, the name must be transformed to the IDNA
    encoding [RFC3490] prior to name lookup.  URI producers should
    provide these registered names in the IDNA encoding, rather than a
    percent-encoding, if they wish to maximize interoperability with
    legacy URI resolvers.

 >Yet there are "ML.ML" domain names already in use (both by Govs agencies 
and in private spaces).

These are just rouge local setups, not conforming to any kind of spec.

 >I asked the author of the IRI RFC. He reponded to most of my questions. 
But the situation of the TLD is not clear as it is not supported by IE, but 
is supported by plug-in.

In this sense, TLDs are no different from other levels of the
domain name hierarchy.

 >The case of ATOM is different as not dependent from browsers.

It would be a very bad idea if Atom decided to dereference
URIs or IRIs in a different way from other software.

 >Also it is likely that in the ATOM definition timeframe the "ML.ML" 
(multilingual.multilingual) will most probably broadly in use in some areas 
of the world.

It would be good. There is nothing in IRIs or URIs preventing
the use of non-ASCII.non-ASCII domain names (multilingual
in this context is totally inappropriate, although a lot of
people use it that way). It is up to ICANN to decide on new
TLDs, and it's a political problem, not a technical one.

Regards,     Martin.

---

From: David Powell <[email-masked]>
Date: Tue, 1 Feb 2005 22:58:30 +0000

> proposed, but it was shot down. *shrug*

In my RDF mapping <http://djpowell.net/atomrdf/0.1/> I modelled the
thing with the id as a "Feed", and used "FeedInstance" as a term for
the version of feed properties that is delivered in the document.

Same for "Entry" and "EntryInstance". It is clear that feeds and
entries are expected to change so I modelled the different instances
as separate entities. This way you can use the same model whether you
only care about the latest instance, or if you want to keep historic
instances. [*]

Anyway - would it be worth using the term "Entry Instance" in the
spec?  Would it make ids easier to explain?

* You'd annotate each instance with something like atomrdf:receivedDate
so that you can select the latest version. It works well from
RDF - because you are no longer negating information every time
something changes, instead you are just taking a selective view on the
most recent version of what is available.

-- 
Dave

---

From: Mark Nottingham <[email-masked]>
Date: Thu, 3 Feb 2005 21:03:14 -0800

This is now PaceNoFeedState;
   http://www.intertwingly.net/wiki/pie/PaceNoFeedState

On Jan 31, 2005, at 3:46 PM, Mark Nottingham wrote:

> x. Managing Feed State
>
> Atom Processors MAY keep state (e.g., metadata in atom:head, entries) 
> sourced from Atom Feed Documents and combine them with other Atom Feed 
> Documents, in order to facilitate a contiguous view of the contents of 
> the feed. The manner in which Atom Feed Documents are combined in 
> order to reconstruct a feed (including methods of identifying 
> duplicate entries, updating metadata, and dealing with missing 
> entries) is out of the scope of this specification, but may be defined 
> by an extension to Atom.
>

---

From: Eric Scheid <[email-masked]>
Date: Fri, 04 Feb 2005 18:46:04 +1100

>  http://www.intertwingly.net/wiki/pie/PaceNoFeedState

+1

e.