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

[Herbert van de Sompel <[e-mail]>]

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
[e-mail].

Greetings

Herbert



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

> Some comments in-line.
>
> On Wed, Sep 29, 2010 at 12:33 PM, Herbert van de Sompel
> <[e-mail]> 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 <[e-mail]> 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
> >> <[e-mail]> wrote:
> >> > PROVISIONAL MESSAGE HEADER FIELD SUBMISSION TEMPLATE:
> >> >    Header field name: Memento-Datetime
> >> >    Applicable protocol: http
> >> >    Status: provisional
> >> >    Author/Change controller: Herbert Van de Sompel, [e-mail]
> ,
> >> > 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
> >> > [e-mail]
> >> > 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/