Subject: Re: Draft on TimeStampedData

From: "Denis Pinkas" <[email-masked]>
Date: Thu, 30 Aug 2007 14:44:56 +0200

Adiano,

An additional comment on your draft.

As an option, it might be valuable to be able to include the location of the document (a URL).

Denis

---

From: Alfonso De Gregorio <[email-masked]>
Date: Thu, 30 Aug 2007 16:43:38 +0200

Hi Adriano, Hi Danis,

I would rather suggest to consider to update the TimeStampedData
sequence in the following way:

TimeStampedData ::= SEQUENCE {
           version        INTEGER { v1(1) },
-           fileName     UTF8String,
+           contentURI     ContentURI,
           mimeType       PrintableString,
           content        OCTET STRING,
           timeStamps     SET (SIZE(1..MAX)) OF TimeStampToken }

Where 'ContentURI' is defined as:
ContentURI ::= UTF8String (CONSTRAINED BY { -- conforms to the format of
a URI -- })

By doing this, we'll be able to achieve greater flexibility in naming
the timestamped datum, and we would be free to dereference (resolve)
the URI according to its scheme (e.g., 'cid:', 'mid:', 'news:', 'nntp:',
among others). For instance, by using the 'file:' scheme we would retain
also functional equivalence with the current specifications.

Cheers,
Alfonso

---

From: "Santoni Adriano" <[email-masked]>
Date: Fri, 31 Aug 2007 09:12:54 +0200

I can agree to this, why not.

Adriano

-----Messaggio originale-----
Da: Alfonso De Gregorio [mailto:[email-masked]] 
Inviato: giovedì 30 agosto 2007 16.44
A: Santoni Adriano; [email-masked]
Cc: [email-masked]
Oggetto: Re: Draft on TimeStampedData

Hi Adriano, Hi Danis,

I would rather suggest to consider to update the TimeStampedData sequence in the following way:

Where 'ContentURI' is defined as:
ContentURI ::= UTF8String (CONSTRAINED BY { -- conforms to the format of a URI -- })

By doing this, we'll be able to achieve greater flexibility in naming the timestamped datum, and we would be free to dereference (resolve) the URI according to its scheme (e.g., 'cid:', 'mid:', 'news:', 'nntp:', among others). For instance, by using the 'file:' scheme we would retain also functional equivalence with the current specifications.

Cheers,
Alfonso

---

From: "Santoni Adriano" <[email-masked]>
Date: Fri, 31 Aug 2007 12:34:36 +0200

I agree that an URI is more versatile than a plain filename, but I want to make sure that this field can be easily used by a recipient application to obtain the name of a local disk file into which to save the content. And let us also keep in mind that the 'content' field is mandatory, in my original proposal, so the data should in any case be in there! Unless we make 'content' an optional field.

If we use an URI instead of a simple fileName, and make 'content' an OPTIONAL field, than it would be necessary to issue guidelines for interoperable applications as a separate document. I'd better not.

Besides, would file://offer.pdf be a valid URI ? (I am nor sure)

What I was addressing, originally, is the need to phisically bind a local document (which, once enveloped as per my draft, could be even deleted because it would have been saved into the TimeStampedData structure) with the corresponding "evidence".

That is the main goal, and I want to make sure it is preserved, together with the most possible simplicity.

Adriano

-----Messaggio originale-----
Da: Alfonso De Gregorio [mailto:[email-masked]] 
Inviato: giovedì 30 agosto 2007 16.44
A: Santoni Adriano; [email-masked]
Cc: [email-masked]
Oggetto: Re: Draft on TimeStampedData

Hi Adriano, Hi Danis,

Cheers,
Alfonso

---

From: Alfonso De Gregorio <[email-masked]>
Date: Fri, 31 Aug 2007 13:03:15 +0200

Indeed, the main goal would be fully preserved by locating the binded 
document via an URI, since the file scheme is designate files accessible 
on a paricular host (while others scheme allow to designate resources in 
a universal decentralized information space).

More specifically, the scheme is defined in RFC1738 and it takes the form:

  file://<host>/<path>

So, file://offer.pdf is not a valid URI. Yet, file:///offer.pdf  or 
file://localhost/offer.pdf would be both valid - notice the third '/', 
the delimiter between the <host> and the <path> part.

Ciao,
Alfonso

---

From: "Santoni Adriano" <[email-masked]>
Date: Fri, 31 Aug 2007 13:43:40 +0200

It's not nice, from a privacy viewpoint, to put into a TimeStampedData envelope information about my private hostnames or even pathnames. If I was to send a TimeStampedData envelope to someone else, this latter would receive also such information in the URI, which they do not need to know (they only need a filename when they want to detach the original content from the envelope).

Adriano

-----Messaggio originale-----
Da: Alfonso De Gregorio [mailto:[email-masked]] 
Inviato: venerdì 31 agosto 2007 13.03
A: Santoni Adriano
Cc: [email-masked]; [email-masked]
Oggetto: Re: R: Draft on TimeStampedData

Indeed, the main goal would be fully preserved by locating the binded document via an URI, since the file scheme is designate files accessible on a paricular host (while others scheme allow to designate resources in a universal decentralized information space).

  file://<host>/<path>

So, file://offer.pdf is not a valid URI. Yet, file:///offer.pdf  or file://localhost/offer.pdf would be both valid - notice the third '/', the delimiter between the <host> and the <path> part.

Ciao,
Alfonso

---

From: Alfonso De Gregorio <[email-masked]>
Date: Fri, 31 Aug 2007 15:17:35 +0200

This is not necessarily the case. In fact, those who are concerned with 
the possible disclosure of private informations in the URI can still use 
a special form of URI called 'URI Reference'.
An URI Reference may take several forms: full URI, fragments, or even 
the trailing component of the URI (i.e., traling component of the 
pathname, in presence of the 'file:' scheme).

The recipient/consumer of  TimeStampedData envelope can convert the URI 
Reference to a full (absolute) form by appending it to a base URI - 
configured locally.
For instance, a valid URI Reference can be 'offer.pdf'.

The data structure should be updated accordingly:

+           contentLabel     ContentLabel,

Where 'ContentLabel' is defined as:

ContentURI ::= UTF8String (CONSTRAINED BY { -- conforms to the format 
of  a URI -- })
ContentURIRef ::= UTF8String (CONSTRAINED BY { -- conforms to the format 
of  a URI -- })

ContentLabel ::= CHOICE {
	contentURI	[0]	ContentURI,	
	contentURIRef	[1]	ContentURIRef,
}

   -- Alfonso,   who'll be travelling in the next ten days with limited 
access to the mbox

"What's in a name? That which we call a rose
By any other name would smell as sweet.", Shakespeare

---

From: "Santoni Adriano" <[email-masked]>
Date: Fri, 31 Aug 2007 15:55:34 +0200

In such a case, I do not object to using an URI Reference.

A

-----Messaggio originale-----
Da: Alfonso De Gregorio [mailto:[email-masked]] 
Inviato: venerdì 31 agosto 2007 15.18
A: Santoni Adriano
Cc: [email-masked]; [email-masked]
Oggetto: Re: R: R: Draft on TimeStampedData

This is not necessarily the case. In fact, those who are concerned with the possible disclosure of private informations in the URI can still use a special form of URI called 'URI Reference'.
An URI Reference may take several forms: full URI, fragments, or even the trailing component of the URI (i.e., traling component of the pathname, in presence of the 'file:' scheme).

The recipient/consumer of  TimeStampedData envelope can convert the URI Reference to a full (absolute) form by appending it to a base URI - configured locally.
For instance, a valid URI Reference can be 'offer.pdf'.

ContentURI ::= UTF8String (CONSTRAINED BY { -- conforms to the format of  a URI -- }) ContentURIRef ::= UTF8String (CONSTRAINED BY { -- conforms to the format of  a URI -- })

"What's in a name? That which we call a rose By any other name would smell as sweet.", Shakespeare