Subject: [Ietf-message-headers] provisional registration Memento-Datetime header

From: Herbert Van de Sompel <[email-masked]>
Date: Wed, 29 Sep 2010 11:18:00 -0600

PROVISIONAL MESSAGE HEADER FIELD SUBMISSION TEMPLATE:

    Header field name: Memento-Datetime

    Applicable protocol: http

    Status: provisional

    Author/Change controller: Herbert Van de Sompel,  
[email-masked], Los Alamos National Laboratory, http://public.lanl.gov/herbertv/

    Specification document(s): http://www.mementoweb.org/guide/http/

    Related information:

Van de Sompel, H., Sanderson, R., Nelson, M.L., Balakireva, L.,  
Ainsworth, S., Shankar, H. (2010) An HTTP-Based Versioning Mechanism  
for Linked Data. Proceedings of the 3rd Workshop on Linked Data on the  
Web (LDOW2010).Arxiv preprint. http://arxiv.org/abs/1003.3661

Van de Sompel, H., Nelson, M.L., Sanderson, R., Balakireva, L.,  
Ainsworth, S., Shankar, H. (2009) Memento: Time Travel for the Web.  
Arxiv preprint.  http://arxiv.org/abs/0911.1112

---

From: Ted Hardie <[email-masked]>
Date: Wed, 29 Sep 2010 11:14:40 -0700

Howdy,

First, I would suggest that the pointer given in the specification document
be to the introduction document (http://www.mementoweb.org/guide/quick-intro/)
because leaping into the middle of the guide cited doesn't tell you anything
about what this is for.  Without that, it is sort of hard to tell
whether the header
is well-specified.

Second, I would suggest that you include in the linked document (
guide or other)
ABNF or similar pseudo-code indicating what you expect in the two
headers you are
dealing with.  This would tell a develop whether or not q-factors are permitted,
for example.

Third, I would suggest you consider a modification similar to that in
Accept-Language,
allowing you to include a series of time values and q factors for
them.  If you would really
like August 28, 1963, but would okay with August 29, 1963 or August
30, 1963, the
q-factors would allow you indicate which would be better.  I also
strongly suspect
that if you don't do this some bright spark will do it for you later,
as we've seen
q-factor additions crop up to Accept headers in a variety of "Interesting" ways.

regards,

Ted Hardie

On Wed, Sep 29, 2010 at 10:18 AM, Herbert Van de Sompel
<[email-masked]> wrote:
>    Author/Change controller: Herbert Van de Sompel, [email-masked], Los
> Alamos National Laboratory, http://public.lanl.gov/herbertv/
> Van de Sompel, H., Sanderson, R., Nelson, M.L., Balakireva, L., Ainsworth,
> S., Shankar, H. (2010) An HTTP-Based Versioning Mechanism for Linked Data.
> Proceedings of the 3rd Workshop on Linked Data on the Web (LDOW2010).Arxiv
> preprint. http://arxiv.org/abs/1003.3661
>
> Van de Sompel, H., Nelson, M.L., Sanderson, R., Balakireva, L., Ainsworth,
> S., Shankar, H. (2009) Memento: Time Travel for the Web. Arxiv preprint.
> http://arxiv.org/abs/0911.1112
>
>
> _______________________________________________
> Ietf-message-headers mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ietf-message-headers
>
>

---

From: Herbert van de Sompel <[email-masked]>
Date: Wed, 29 Sep 2010 13:33:52 -0600

Dear Ted,

Thanks for your feedback. I insert a few comments, below.

Cheers

Herbert

On Wed, Sep 29, 2010 at 12:14 PM, Ted Hardie <[email-masked]> wrote:

> be to the introduction document (
> http://www.mementoweb.org/guide/quick-intro/)
Will do when we submit the request for registration in the temporal
registry, in a few weeks from now. However, at that point we may have a
first version of the Memento Internet Draft available, which would then be a
better point of reference.

> dealing with.  This would tell a develop whether or not q-factors are
The possible values for Memento-Datetime (and its associated Accept-Datetime
request header) are specified as:

In the below transactions, values for the Accept-Datetime and
Memento-Datetime headers are datetimes expressed according to the RFC 1123
format referenced in Section 3.3.1 of RFC
2616<http://www.ietf.org/rfc/rfc2616.txt> "Hypertext
Transfer Protocol -- HTTP/1.1".

> q-factor additions crop up to Accept headers in a variety of "Interesting"
This is something that definitely needs further exploration and discussion.
The first version of the Memento Internet Draft will most likely not address
this, but it has come up in our discussions several times. To cut a long
story short, we are not sure that the q-value approach would add significant
value to datetime negotiation, mainly because:

(*) The variant resources exist on a (time) continuum, and are not discreet
as with other dimensions of HTTP content negotiation;
(*) In an archival context, one should be very happy to actually find an
archival resource in the neighborhood of a specified datetime; expressing
multiple preferences with associated q-values feels a bit disconnected from
this reality.

As an alternative approach that might be more aligned with datetime
negotiation (in a continuum), we have been thinking about the ability to
express a duration interval around a datetime mid-point, e.g.:

Accept-Datetime: Tue, 11 Sep 2001 20:35:00 GMT; P10D

would be used to request archival resources in an interval of +/- 10 days
around Tue, 11 Sep 2001 20:35:00 GMT (the xsd:duration syntax is used to
express the interval, but that is just to convey the idea not to propose an
actual syntax.)

As indicated, this is definitely an area that requires further discussion.
Thanks for bringing it up.

> Ainsworth,
> Ainsworth,

-- 
Herbert Van de Sompel
Digital Library Research & Prototyping
Los Alamos National Laboratory, Research Library
http://public.lanl.gov/herbertv/

---

From: Ted Hardie <[email-masked]>
Date: Wed, 29 Sep 2010 14:07:22 -0700

Some comments in-line.

On Wed, Sep 29, 2010 at 12:33 PM, Herbert van de Sompel
<[email-masked]> wrote:
>> be to the introduction document
>> (http://www.mementoweb.org/guide/quick-intro/)

An Internet-draft this would be great; thanks for following through with this.

> format referenced in Section 3.3.1 of RFC 2616 "Hypertext Transfer Protocol
> -- HTTP/1.1".
>

So, I find that a somewhat convoluted way of expressing this.  As you
no doubt recognize,
RFC 2616 discusses three different date formats, and RFC 1123 is a
fairly bare-bones
update to RFC 822, with not a lot of discussion of why the change is
there.   Rather
than have folks follow the links and potentially get confused, why not
include it? The production
in RFC 2616 is fairly easy to provide:

rfc1123-date = wkday "," SP date1 SP time SP "GMT"
date1        = 2DIGIT SP month SP 4DIGIT
                      ; day month year (e.g., 02 Jun 1982)
time         = 2DIGIT ":" 2DIGIT ":" 2DIGIT
                      ; 00:00:00 - 23:59:59
weekday      = "Monday" | "Tuesday" | "Wednesday"
                    | "Thursday" | "Friday" | "Saturday" | "Sunday"
month        = "Jan" | "Feb" | "Mar" | "Apr"
                    | "May" | "Jun" | "Jul" | "Aug"
                    | "Sep" | "Oct" | "Nov" | "Dec"

I would personally err on the side of including it, along with
a reference to the source.  This is largely a stylistic matter, of course,
as long as other readers are clear on what to produce and parse.

> as with other dimensions of HTTP content negotiation;

Not to be pedantic, but the resources are discreet.  Each resource endures
for a specific period, which may or may not be known.

> multiple preferences with associated q-values feels a bit disconnected from

But once you have create the header, you need to understand that it may be
used in multiple ways.  As an example, what happens when someone wants
to use this
using future dates, as part of a pub/sub mechanism?

> express the interval, but that is just to convey the idea not to propose an

In an HTTP context, if there are 5 resources within the duration
interval what is returned
and how are they ordered?  If you have a q-value, you can identify
which one should
be returned.  Alternatively, you can return all of them in a multipart
with appropriate metadata;
for some resources this is practical, but it may not be so for all.

> Thanks for bringing it up.

Any chance one of the authors will be at the Beijing IETF?  I think
this discussion
would be a useful one to have at the APPs area meeting new APPSWG meeting.
You might also consider posting it to apps-open for discussion, when you are
ready to discuss the duration issue.

regards,

Ted Hardie

---

From: Herbert van de Sompel <[email-masked]>
Date: Wed, 29 Sep 2010 15:16:23 -0600

Thanks a lot for your input, Ted. We will definitely include the BNF in our
Internet Draft.

I am afraid we will not be able to make it to Bejing. Several of us work at
a US government lab and traveling to China is not considered ... err ...
essential for us. But we will definitely try and attend the meeting after
Bejing, and look forward to a discussion of the Memento Internet Draft,
there. And, obviously, issues can already be discussed on
[email-masked].

Greetings

Herbert

On Wed, Sep 29, 2010 at 3:07 PM, Ted Hardie <[email-masked]> wrote:

> >> q-factor additions crop up to Accept headers in a variety of
> "Interesting"
> >> ways.
> >>
> >
> >> >    Author/Change controller: Herbert Van de Sompel, [email-masked]
> ,
> >> > Los

---

From: SM <[email-masked]>
Date: Wed, 29 Sep 2010 16:24:52 -0700

Hi Herbert,
At 14:16 29-09-10, Herbert van de Sompel wrote:
>we will definitely try and attend the meeting after Bejing, and look 
>forward to a discussion of the Memento Internet Draft, there. And, 
>obviously, issues can already be discussed on 
><mailto:[email-masked]>[email-masked].

If you are going to submit an Internet-Draft and you would like 
people to comment, I suggest asking on the apps-discuss ( 
https://www.ietf.org/mailman/listinfo/apps-discuss ) mailing list.

Regards,
-sm

---

From: Herbert Van de Sompel <[email-masked]>
Date: Wed, 29 Sep 2010 19:01:30 -0600

OK, will do.

Thanks

Herbert

Sent from my iPhone

On Sep 29, 2010, at 17:24, SM <[email-masked]> wrote:

>> we will definitely try and attend the meeting after Bejing, and  
>> look forward to a discussion of the Memento Internet Draft, there.  
>> And, obviously, issues can already be discussed on <mailto:[email-masked] 
> people to comment, I suggest asking on the apps-discuss ( https://www.ietf.org/mailman/listinfo/apps-discuss 
>  ) mailing list.
>
> Regards,
> -sm