Re: provisional registration Memento-Datetime header
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
memento-dev <at> googlegroups.com.
Greetings
Herbert
On Wed, Sep 29, 2010 at 3:07 PM, Ted Hardie
<ted.ietf <at> gmail.com> wrote:
Some comments in-line.
On Wed, Sep 29, 2010 at 12:33 PM, Herbert van de Sompel
<
hvdsomp <at> gmail.com> wrote:
> 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 <
ted.ietf <at> gmail.com> wrote:
>>
>> 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.
>>
>
> 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.
>
An Internet-draft this would be great; thanks for following through with this.
>>
>> 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.
>>
>
> 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 "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.
>>
>> 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.
>>
>
> 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;
Not to be pedantic, but the resources are discreet. Each resource endures
for a specific period, which may or may not be known.
> (*) 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.
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?
> 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.)
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.
> As indicated, this is definitely an area that requires further discussion.
> 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
>
>>
>> regards,
>>
>> Ted Hardie
>>
>> On Wed, Sep 29, 2010 at 10:18 AM, Herbert Van de Sompel
>> <
hvdsomp <at> gmail.com> wrote:
>> > PROVISIONAL MESSAGE HEADER FIELD SUBMISSION TEMPLATE:
>> > Header field name: Memento-Datetime
>> > Applicable protocol: http
>> > Status: provisional
>> > Author/Change controller: Herbert Van de Sompel,
hvdsomp <at> gmail.com,
>> > 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
>> >
>> >
>> > _______________________________________________
>> > Ietf-message-headers mailing list
>> >
Ietf-message-headers <at> ietf.org
>> >
https://www.ietf.org/mailman/listinfo/ietf-message-headers
>> >
>> >
>
>
>
> --
> Herbert Van de Sompel
> Digital Library Research & Prototyping
> Los Alamos National Laboratory, Research Library
>
http://public.lanl.gov/herbertv/
>
--
Herbert Van de Sompel
Digital Library Research & Prototyping
Los Alamos National Laboratory, Research Library
http://public.lanl.gov/herbertv/
<div>
<p>Thanks a lot for your input, Ted. We will definitely include the BNF in our Internet Draft.</p>
<div><br></div>
<div>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 <a href="mailto:memento-dev <at> googlegroups.com">memento-dev <at> googlegroups.com</a>.</div>
<div><br></div>
<div>Greetings</div>
<div><br></div>
<div>Herbert</div>
<div><br></div>
<div> <br><br><div class="gmail_quote">On Wed, Sep 29, 2010 at 3:07 PM, Ted Hardie <span dir="ltr"><<a href="mailto:ted.ietf <at> gmail.com">ted.ietf <at> gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote">Some comments in-line.<br><div class="im">
<br>
On Wed, Sep 29, 2010 at 12:33 PM, Herbert van de Sompel<br>
<<a href="mailto:hvdsomp <at> gmail.com">hvdsomp <at> gmail.com</a>> wrote:<br>
> Dear Ted,<br>
> Thanks for your feedback. I insert a few comments, below.<br>
> Cheers<br>
> Herbert<br>
><br>
> On Wed, Sep 29, 2010 at 12:14 PM, Ted Hardie <<a href="mailto:ted.ietf <at> gmail.com">ted.ietf <at> gmail.com</a>> wrote:<br>
>><br>
>> Howdy,<br>
>><br>
>> First, I would suggest that the pointer given in the specification<br>
>> document<br>
>> be to the introduction document<br>
>> (<a href="http://www.mementoweb.org/guide/quick-intro/" target="_blank">http://www.mementoweb.org/guide/quick-intro/</a>)<br>
>> because leaping into the middle of the guide cited doesn't tell you<br>
>> anything<br>
>> about what this is for. Without that, it is sort of hard to tell<br>
>> whether the header<br>
>> is well-specified.<br>
>><br>
><br>
> Will do when we submit the request for registration in the temporal<br>
> registry, in a few weeks from now. However, at that point we may have a<br>
> first version of the Memento Internet Draft available, which would then be a<br>
> better point of reference.<br>
><br><br>
</div>An Internet-draft this would be great; thanks for following through with this.<br><div class="im">
<br>
>><br>
>> Second, I would suggest that you include in the linked document (<br>
>> guide or other)<br>
>> ABNF or similar pseudo-code indicating what you expect in the two<br>
>> headers you are<br>
>> dealing with. This would tell a develop whether or not q-factors are<br>
>> permitted,<br>
>> for example.<br>
>><br>
><br>
> The possible values for Memento-Datetime (and its associated Accept-Datetime<br>
> request header) are specified as:<br>
> In the below transactions, values for the Accept-Datetime and<br>
> Memento-Datetime headers are datetimes expressed according to the RFC 1123<br>
> format referenced in Section 3.3.1 of RFC 2616 "Hypertext Transfer Protocol<br>
> -- HTTP/1.1".<br>
><br><br>
</div>So, I find that a somewhat convoluted way of expressing this. As you<br>
no doubt recognize,<br>
RFC 2616 discusses three different date formats, and RFC 1123 is a<br>
fairly bare-bones<br>
update to RFC 822, with not a lot of discussion of why the change is<br>
there. Rather<br>
than have folks follow the links and potentially get confused, why not<br>
include it? The production<br>
in RFC 2616 is fairly easy to provide:<br><br>
rfc1123-date = wkday "," SP date1 SP time SP "GMT"<br>
date1 = 2DIGIT SP month SP 4DIGIT<br>
; day month year (e.g., 02 Jun 1982)<br>
time = 2DIGIT ":" 2DIGIT ":" 2DIGIT<br>
; 00:00:00 - 23:59:59<br>
weekday = "Monday" | "Tuesday" | "Wednesday"<br>
| "Thursday" | "Friday" | "Saturday" | "Sunday"<br>
month = "Jan" | "Feb" | "Mar" | "Apr"<br>
| "May" | "Jun" | "Jul" | "Aug"<br>
| "Sep" | "Oct" | "Nov" | "Dec"<br><br>
I would personally err on the side of including it, along with<br>
a reference to the source. This is largely a stylistic matter, of course,<br>
as long as other readers are clear on what to produce and parse.<br><div class="im">
<br>
>><br>
>> Third, I would suggest you consider a modification similar to that in<br>
>> Accept-Language,<br>
>> allowing you to include a series of time values and q factors for<br>
>> them. If you would really<br>
>> like August 28, 1963, but would okay with August 29, 1963 or August<br>
>> 30, 1963, the<br>
>> q-factors would allow you indicate which would be better. I also<br>
>> strongly suspect<br>
>> that if you don't do this some bright spark will do it for you later,<br>
>> as we've seen<br>
>> q-factor additions crop up to Accept headers in a variety of "Interesting"<br>
>> ways.<br>
>><br>
><br>
> This is something that definitely needs further exploration and discussion.<br>
> The first version of the Memento Internet Draft will most likely not address<br>
> this, but it has come up in our discussions several times. To cut a long<br>
> story short, we are not sure that the q-value approach would add significant<br>
> value to datetime negotiation, mainly because:<br>
> (*) The variant resources exist on a (time) continuum, and are not discreet<br>
> as with other dimensions of HTTP content negotiation;<br><br>
</div>Not to be pedantic, but the resources are discreet. Each resource endures<br>
for a specific period, which may or may not be known.<br><div class="im">
<br>
> (*) In an archival context, one should be very happy to actually find an<br>
> archival resource in the neighborhood of a specified datetime; expressing<br>
> multiple preferences with associated q-values feels a bit disconnected from<br>
> this reality.<br><br>
</div>But once you have create the header, you need to understand that it may be<br>
used in multiple ways. As an example, what happens when someone wants<br>
to use this<br>
using future dates, as part of a pub/sub mechanism?<br><div class="im">
<br>
> As an alternative approach that might be more aligned with datetime<br>
> negotiation (in a continuum), we have been thinking about the ability to<br>
> express a duration interval around a datetime mid-point, e.g.:<br>
> Accept-Datetime: Tue, 11 Sep 2001 20:35:00 GMT; P10D<br>
> would be used to request archival resources in an interval of +/- 10 days<br>
> around Tue, 11 Sep 2001 20:35:00 GMT (the xsd:duration syntax is used to<br>
> express the interval, but that is just to convey the idea not to propose an<br>
> actual syntax.)<br><br>
</div>In an HTTP context, if there are 5 resources within the duration<br>
interval what is returned<br>
and how are they ordered? If you have a q-value, you can identify<br>
which one should<br>
be returned. Alternatively, you can return all of them in a multipart<br>
with appropriate metadata;<br>
for some resources this is practical, but it may not be so for all.<br><div class="im">
<br><br>
> As indicated, this is definitely an area that requires further discussion.<br>
> Thanks for bringing it up.<br><br>
</div>Any chance one of the authors will be at the Beijing IETF? I think<br>
this discussion<br>
would be a useful one to have at the APPs area meeting new APPSWG meeting.<br>
You might also consider posting it to apps-open for discussion, when you are<br>
ready to discuss the duration issue.<br><br>
regards,<br><br>
Ted Hardie<br><div>
<div></div>
<div class="h5">
<br>
><br>
>><br>
>> regards,<br>
>><br>
>> Ted Hardie<br>
>><br>
>> On Wed, Sep 29, 2010 at 10:18 AM, Herbert Van de Sompel<br>
>> <<a href="mailto:hvdsomp <at> gmail.com">hvdsomp <at> gmail.com</a>> wrote:<br>
>> > PROVISIONAL MESSAGE HEADER FIELD SUBMISSION TEMPLATE:<br>
>> > Header field name: Memento-Datetime<br>
>> > Applicable protocol: http<br>
>> > Status: provisional<br>
>> > Author/Change controller: Herbert Van de Sompel, <a href="mailto:hvdsomp <at> gmail.com">hvdsomp <at> gmail.com</a>,<br>
>> > Los<br>
>> > Alamos National Laboratory, <a href="http://public.lanl.gov/herbertv/" target="_blank">http://public.lanl.gov/herbertv/</a><br>
>> > Specification document(s): <a href="http://www.mementoweb.org/guide/http/" target="_blank">http://www.mementoweb.org/guide/http/</a><br>
>> > Related information:<br>
>> ><br>
>> > Van de Sompel, H., Sanderson, R., Nelson, M.L., Balakireva, L.,<br>
>> > Ainsworth,<br>
>> > S., Shankar, H. (2010) An HTTP-Based Versioning Mechanism for Linked<br>
>> > Data.<br>
>> > Proceedings of the 3rd Workshop on Linked Data on the Web<br>
>> > (LDOW2010).Arxiv<br>
>> > preprint. <a href="http://arxiv.org/abs/1003.3661" target="_blank">http://arxiv.org/abs/1003.3661</a><br>
>> ><br>
>> > Van de Sompel, H., Nelson, M.L., Sanderson, R., Balakireva, L.,<br>
>> > Ainsworth,<br>
>> > S., Shankar, H. (2009) Memento: Time Travel for the Web. Arxiv preprint.<br>
>> > <a href="http://arxiv.org/abs/0911.1112" target="_blank">http://arxiv.org/abs/0911.1112</a><br>
>> ><br>
>> ><br>
>> > _______________________________________________<br>
>> > Ietf-message-headers mailing list<br>
>> > <a href="mailto:Ietf-message-headers <at> ietf.org">Ietf-message-headers <at> ietf.org</a><br>
>> > <a href="https://www.ietf.org/mailman/listinfo/ietf-message-headers" target="_blank">https://www.ietf.org/mailman/listinfo/ietf-message-headers</a><br>
>> ><br>
>> ><br>
><br>
><br>
><br>
> --<br>
> Herbert Van de Sompel<br>
> Digital Library Research & Prototyping<br>
> Los Alamos National Laboratory, Research Library<br>
> <a href="http://public.lanl.gov/herbertv/" target="_blank">http://public.lanl.gov/herbertv/</a><br>
><br>
</div>
</div>
</blockquote>
</div>
<br><br clear="all"><br>-- <br>Herbert Van de Sompel<br>Digital Library Research & Prototyping<br>Los Alamos National Laboratory, Research Library<br><a href="http://public.lanl.gov/herbertv/">http://public.lanl.gov/herbertv/</a><br>
</div>
</div>
RSS Feed