OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

dss message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: RE: [dss] timestamping profile wd-05


Trevor,

> -----Original Message-----
> From: Trevor Perrin [mailto:trevp@trevp.net]
> Sent: Friday, March 12, 2004 1:42 PM
> To: Dimitri Andivahis
> Subject: RE: [dss] timestamping profile wd-05
> 
> 
> At 12:37 PM 3/12/2004 -0500, you wrote:
> 
> >Trevor,
> >How about this alternative to your second paragraph below:
> >
> >"The client SHOULD only send a single input document
> >if the server receiving the request returns time-stamps
> >that can only cover one document per time-stamp (e.g. RFC 3161)."
> 
> If the server "returns time-stamps that can only cover one document per 
> time-stamp", then the client MUST only send a single input 
> document, SHOULD 
> isn't right for that case, since SHOULD means "there may exist valid 
> reasons in particular circumstances to ignore a particular item":
> http://www.faqs.org/rfcs/rfc2119.html
> 

I have no major issue changing SHOULD to MUST in the quoted 
sentence above.

Having said that, the reason I left it as a recommendation was 
because I assumed the DSS server returning RFC 3161 timestamps 
would be allowed to define its own policy for requests 
with multiple input documents:  it might utilize the first input only 
for the RFC 3161 time-stamp and ignore the remaining ones,
or it might reject the request altogether.

Another point: if there is a valid business reason to have 
a DSS server returning both XML tokens and RFC 3161 timestamps
(depending on the client request), the MUST sentence
limits submitted requests for XML tokens to one input document only 
for absolutely no technical reason.

> The above text also doesn't say what do if the client doesn't know what 
> type of time-stamp the server returns.  The below text covers that case: 
> the client should play it safe, and send a single document.
> 
> So I still like the below text better.  What are your objections to the 
> below text? (do you think it's ambiguous?  or do you think it's 
> behavior is 
> wrong?).
>

The reason I am not happy with the text below is that 
it makes a blanket recommendation for restricting 
the contents of time-stamping requests to any DSS server
based on a limitation of the RFC 3161 method.  
If it goes in the draft as is, any time-stamping method 
that promotes using more than one input document in the request 
will have to explain why there are "valid reasons" 
in their context to "ignore" a recommendation that is sanctioned 
by this profile (as per http://www.faqs.org/rfcs/rfc2119.html).
It would be odd if a profile that is a specialization of the timestamping
profile would be un-doing recommendations of the parent profile.

> 
> >"The client MUST only send <DocumentHash> input documents.  The 
> client MUST
> >NOT sent <Document> input documents.
> >
> >The client SHOULD only send a single input document, since some types of
> >time-stamps (e.g. RFC 3161) can only cover one document per time-stamp."
> 
> 
> Trevor 

Dimitri



[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]