W3C home > Mailing lists > Public > www-tag@w3.org > November 2010

Reviewing Momento - http://mementoweb.org/guide/rfc/ID/

From: Tim Berners-Lee <timbl@w3.org>
Date: Sun, 21 Nov 2010 12:38:47 -0500
Message-Id: <208CBE1D-5E16-4BBD-BC5D-503A78D97AFF@w3.org>
Cc: w3t Team <w3t@w3.org>, TAG List <www-tag@w3.org>
To: Tim's Notes <timbl+notes@w3.org>
Reviewing Momento - http://mementoweb.org/guide/rfc/ID/
Incomplete notes from a plane.

General complaint applies to many specs:

The spec uses the words "RECOMMENDED" as in RFC2616 which immediately flags a 
concern that it does not define a protocol cleanly, in the sense of describing (a) what
the parties do and (b) what good that brings.    Whenever a spec uses MAY or RECOMMENDED
it is in fact defining >1 protocol, one more powerful than the other.  It is wise to 
explain not just a slider scale of from 0 .0 to 1.0 of how "MUST" something is, but
to enumerate the different protocols with their conformance and what they deliver.

Example: 
	The link: rel=timegate header is only RECOMMENDED.
	If you don't do it, Section 3.0 breaks.
	Therefore, for the protocol in section 3.0, rel=timegate is mandatory.


Maybe the spec needs to be factored into two specs, a timsegate discovery protocol and a memento
protocol?

Step 2: The entity-header of the response from URI-R includes an HTTP "Link" header with a Relation Type of "timegate" pointing at a TimeGate (URI-G) for the Original Resource.

Just using the present tense like "includes" is actually more effective than an over-exhuberance 
with RFC2616 capitals.



2.1.1

"The presence of a Memento-Datetime header and associated value for a given resource constitutes a promise that the resource is stable and that its state will no longer change." --> is a  a:FixedResource
where 
@prefix a: <http://www.w3.org/2007/gen/ont#>.


Or in the tabulator link vocabulary

{ ?m log:uri [ is link:requestedURI of [ link:Response  [ httph:momento-decline []]]  } => ( ?m a a:FixedResource }.


"Similarly, if an application is mirroring the resource at a different URI, it SHOULD retain the resource's Memento-Datetime header and value if mirroring the resource does not include a meaningful change to the resource's state. For example, this behavior allows duplicating a Web archive at a new location while preserving the Memento-Datetime values of the archived resources."

So what breaks if another location does not  preserve the momento-datetime: header?
Suppose a different value is given, or none at all?
Presumably if the mirror is pointed to as a timegate for R, then everything breaks.
If it isn't nothing breaks. Is that right? 

2.1.1.1

"The q-value approach is not supported for Memento's datetime negotiation because it is well-suited for negotiation over a discrete space of mostly predictable values, not for negotiation over a continuum of unpredictable datetime values."  
Algorithm?  How to detremine bets fit


" Not using an interval indicator is equivalent with expressing an infinite interval around the preferred datetime."


But what is the algorithm for determining the best fit?


3.0

Step 4: The entity-header of the response from URI-G includes a "Location" header pointing at the URI of a Memento (URI-Mj) for the Original Resource. In addition, the entity-header contains an HTTP "Link" header with a Relation Type of "original" pointing at the Original Resource, and an HTTP "Link" header with a Relation Type of "timemap" pointing at a TimeMap (URI-T). Also HTTP Links pointing at various Mementos are provided using the "memento" Relation Type, as specified in Section 2.2.1.4.

The time map header is transferred but not used in this protocol 3.0

________________________________________
Received on Sunday, 21 November 2010 19:59:17 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Thursday, 26 April 2012 12:48:29 GMT