Subject: eTag, modified and accessed attributes in Link Extensions Draft

From: Bob Wyman <[email-masked]>
Date: Tue, 1 Jun 2010 17:27:57 -0400

The draft, as currently written, seems to be a bit ambiguous about the
source eTags and the meaning of "modified".

My assumption is that an eTag, when used as a link attribute, should not be
something generated by the link element creator but should be a mere passing
on of an eTag generated by the server that hosts the resource that is linked
to. Thus, eTag should be seen as something which, like "hash", simply
records and passes on information related to the state of the resource at
some specific point in time when it was previously accessed. In this case,
you could never have a eTag attribute on a link if the linked-to server did
not support eTags. If this assumption is correct, I think it might clarify
things if it were stated in the draft.

It seems that "modified" might be slightly different. In some cases, it
seems reasonable that modified would be the modified or updated date
reported on accessing a web resource. On the other hand, it seems like it
would also be reasonable, in cases where the server does not report modified
dates yet the author of the link has knowledge of the modification history,
that the link author might include a modified date even though it is NOT
reported by the server. However, this means that the link author is not
simply recording and passing on data offered by the server. This means that
the meaning of "modified" would be somewhat ambiguous. Am I reading this
right?

I continue to see evidence that formal systems for "Internet citation" or
bibliography typically require that a "last accessed" date be included in
citations. Thus, I'd like to suggest a new section (as discussed in earlier
messages):

X.  The 'accessed' attribute

   The 'accessed' Attribute specifies a date and time when the
   resource identified by the atom:link or atom:content element was
   accessed. The 'accessed' attribute SHOULD record the most recent date
   and time at which the resource was accessed. The value MUST conform
   to the "date-time" production defined by [RFC3339].  An uppercase
   "T" character MUST be used to separate date and time, and an
   uppercase "Z" character MUST be present in the absence of a numeric
   time zone offset.  The 'accessed' attribute MAY appear as a child
   of the atom:link and atom:content elements.

     accessed = attribute accessed { xsd:dateTime }

   An example accessed attribute for an enclosed MP3 file:

     <atom:link rel="enclosure"
       href="http://example.org/media/myfile.mp3"
       accessed="2010-12-12T12:12:12Z" />

bob wyman

---

From: James Snell <[email-masked]>
Date: Tue, 1 Jun 2010 16:40:00 -0700

> things if it were stated in the draft.

Agreed.

> the meaning of "modified" would be somewhat ambiguous. Am I reading this

Yes.. I think we need to limit "modified" to the date reported by the
server. If no date is specified, the modified attribute should not be
used.  The feed producer should not make up a value on it's own for
that attribute. The etag and modified attributes should provide enough
valuable information to perform a reasonable conditional get on the
linked resource. If the server doesn't provide that information in the
first place, then it's not of much value.

>        accessed="2010-12-12T12:12:12Z" />

+1. I've been looking at this also. We are going to need to include
some semantics for when the accessed attribute is omitted. This
attribute essentially needs to establish the point in time at which
the modified, etag and hash were considered to be valid... if it is
omitted, then the atom:updated has to be assumed to be the fallback.

- James

---

From: James Snell <[email-masked]>
Date: Mon, 7 Jun 2010 19:09:21 -0700

Ok, new version of the Link Extensions draft has been posted..
includes the 'accessed' attribute...

  http://www.ietf.org/internet-drafts/draft-snell-atompub-link-extensions-06.txt

- James

-- 
- James Snell
  http://www.snellspace.com
  [email-masked]