eTag, modified and accessed attributes in Link Extensions Draft

[Bob Wyman]

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

[James Snell]

Post by Bob Wyman
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.

Agreed.

Post by Bob Wyman
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?

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.

Post by Bob Wyman
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
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 }
<atom:link rel="enclosure"
href="http://example.org/media/myfile.mp3"
accessed="2010-12-12T12:12:12Z" />
bob wyman

+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

[James Snell]

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

Post by James Snell

Post by Bob Wyman
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.

Agreed.

Post by Bob Wyman
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?

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.

Post by Bob Wyman
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
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 }
     <atom:link rel="enclosure"
       href="http://example.org/media/myfile.mp3"
       accessed="2010-12-12T12:12:12Z" />
bob wyman

+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