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

Herbert van de Sompel <hvdsomp@gmail.com> Wed, 29 September 2010 21:15 UTC

Return-Path: <hvdsomp@gmail.com>
X-Original-To: ietf-message-headers@core3.amsl.com
Delivered-To: ietf-message-headers@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4AAFC3A6C85 for <ietf-message-headers@core3.amsl.com>; Wed, 29 Sep 2010 14:15:45 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.998
X-Spam-Level:
X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_38=0.6]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kgaN7pIPpbWf for <ietf-message-headers@core3.amsl.com>; Wed, 29 Sep 2010 14:15:43 -0700 (PDT)
Received: from mail-qw0-f44.google.com (mail-qw0-f44.google.com [209.85.216.44]) by core3.amsl.com (Postfix) with ESMTP id 14ADD3A6D9B for <Ietf-message-headers@ietf.org>; Wed, 29 Sep 2010 14:15:39 -0700 (PDT)
Received: by qwc9 with SMTP id 9so855133qwc.31 for <Ietf-message-headers@ietf.org>; Wed, 29 Sep 2010 14:16:24 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type; bh=qO9Y7UKmJL7/h7t95hJdg9IrgiOWwjtSpZ4BwlZg2bE=; b=mhjN6NaRGeb4p04nwyOJEQdu6LCG9qxTOkAEfW90TUcsLZSda3hSn0LLeYdrN3csbh qW3DahDaRX/AFEvp8TSKFlTlkXXDhFYcl2rVzwpqQ7a2yJq7PIZbZ/QbfA6rmVvYAHha WCgFZ3/X9CVGz4L+CFVP6OzS6iB+ijGtu2k7o=
DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=AnpuFmOMjUmSSl5WYSFZM5bgfb5wW2PrEeJygvwHdGTUKpEmp2Hm3JlJES4Y9zHg9a h4CWFu3iFZ7Ppnc/R3+DAjkcJbn55KTJHn9X/lQ98IQx+AcTm5oIWEXiagclCTthyo7p G1r9G+TY79zfbscnz3ulf7OlGhkKDiQaqzOTc=
MIME-Version: 1.0
Received: by 10.229.101.197 with SMTP id d5mr1645418qco.220.1285794983506; Wed, 29 Sep 2010 14:16:23 -0700 (PDT)
Received: by 10.229.84.147 with HTTP; Wed, 29 Sep 2010 14:16:23 -0700 (PDT)
In-Reply-To: <AANLkTi=D485pMu4ttezC2O3p5gmch8CjxofGe2CxB6yK@mail.gmail.com>
References: <20C2683B-A640-4EA6-A324-8541CD6B97BD@gmail.com> <AANLkTimyU8bcFfLYkiaDFgdBkBwNf7oFc44BN4VQBxLC@mail.gmail.com> <AANLkTi=rTfbpVfNmQ_bZ7_wtGjJxtqXyHdsTW6trgDFg@mail.gmail.com> <AANLkTi=D485pMu4ttezC2O3p5gmch8CjxofGe2CxB6yK@mail.gmail.com>
Date: Wed, 29 Sep 2010 15:16:23 -0600
Message-ID: <AANLkTin4k59Bw-RhksAHnFMDxZCw8b8GGH+cV2kLY7pB@mail.gmail.com>
From: Herbert van de Sompel <hvdsomp@gmail.com>
To: Ted Hardie <ted.ietf@gmail.com>
Content-Type: multipart/alternative; boundary=001636aa2b8c3efbb404916c7972
Cc: "Michael L. Nelson" <mln@cs.odu.edu>, Ietf-message-headers@ietf.org
Subject: Re: [Ietf-message-headers] provisional registration Memento-Datetime header
X-BeenThere: ietf-message-headers@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: "Discussion list for header fields used in Internet messaging applications." <ietf-message-headers.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/ietf-message-headers>, <mailto:ietf-message-headers-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/ietf-message-headers>
List-Post: <mailto:ietf-message-headers@ietf.org>
List-Help: <mailto:ietf-message-headers-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ietf-message-headers>, <mailto:ietf-message-headers-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 29 Sep 2010 21:15:45 -0000

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@googlegroups.com.

Greetings

Herbert



On Wed, Sep 29, 2010 at 3:07 PM, Ted Hardie <ted.ietf@gmail.com> wrote:

> Some comments in-line.
>
> On Wed, Sep 29, 2010 at 12:33 PM, Herbert van de Sompel
> <hvdsomp@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@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@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@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@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/