Re: Link Extensions Draft Update

[Niklas Lindström <[e-mail]>]

Hi James!

It's been great to see this draft revitalized and progressing. I am
certainly in favor of the non-namespaced attributes and the
generalized "hash" approach.

I understand Eric's objection that "significant" may not always
include hash changes, so changing that to a "MAY" sounds reasonable.
(I have no concerns in general about specified significance, since we
have very specific requirements on our publishers regarding both
updated and hash. In our case, *any* change is significant, and we
require hash values to be correct -- but since this is enforced at our
own contract level, we don't need such requirements in the spec.)

I have two questions:

1. I am a bit concerned about referencing a Candidate Rec (CSS3 Media
Queries). Might that stall this from becoming an RFC? (In any case,
the link in version 7 of this I-D is outdated, the current CSS3 Media
Queries CR is from 27 July 2010.) If so, maybe it's better to split
that part out?

2. I wonder if you have an estimate on what's needed to get this to
Last Call? I'd like to help as much as I can, but I don't really know
how (apart from expressing my support on this list).


Implementation-wise, I can donate any specific implementation code you
need (at least in java), but probably won't have time to wrap up and
publish a hosted source project (e.g. a properly packaged Abdera
extension) anytime soon (although I can contribute to such if the
infrastructure was in place).

(Background recap: we are using the hash mechanism in an egov project
[1], and publishers are starting to implement it. We need to inform of
the (hash attr) syntax changes to the publishers (less than 5 are
currently implementing this, but some 95 more are to follow over the
coming year(s)). Thus we really need to work to ensure the stability
of the current syntax. We are certainly aware that it's not proper
conduct to reference I-D:s, but have chosen to take the risk of
changes in this case over inventing our own extension for such a
generic thing as hash digests.)


Thanks for your efforts!

Best regards,
Niklas Lindström, Valtech

[1] The Swedish Legal Information System (Docs in swedish:
<http://dev.lagrummet.se/dokumentation/>.)



On Sun, Jul 4, 2010 at 12:52 PM, eric scheid
<[e-mail]> wrote:
>
> On 1/7/10 4:32 AM, "James Snell" <[e-mail]> wrote:
>
>> http://www.ietf.org/internet-drafts/draft-snell-atompub-link-extensions-07.txt
>>
>> A few minor updates, and one significant update... the new requirement is that
>> changes to the hash, etag, modified and accessed attributes MUST be considered
>> to be "significant" with regards to the value of atom:updated. This is a
>> requirement on the feed publisher.
>
> -1, sorry, can't agree with this
>
>   The "atom:updated" element is a Date construct indicating the most
>   recent instant in time when an entry or feed was modified in a way
>   the publisher considers significant.  Therefore, not all
>   modifications necessarily result in a changed atom:updated value.
>
>   atomUpdated = element atom:updated { atomDateConstruct }
>
>   Publishers MAY change the value of this element over time.
>
> A minor and trivial change to a linked resource, eg. whitespace, could well
> cause a change in (eg.) the hash, but that (usually) is not significant.
>
> Similarly a change in the 'accessed' attribute especially when the 'hash'
> and 'etag' *didn't* change is pretty much the definition of not-significant.
>
> s/MUST/MAY/
>
>
> e.