Subject: [core] draft-ietf-core-block-08 - Tokens in requests

From: Klaus Hartke <[email-masked]>
Date: Wed, 11 Apr 2012 06:31:47 +0200

Does the client need to use the same token in each request when up- or
downloading a representation in multiple parts?

Most if not all implementations with support for Block1 at the
Plugtest seemed to assume this.

However, the only statements in the draft regarding tokens are that
(a) the client MAY use non-empty tokens and
(b) if the client does multiple unrelated uploads at the same time, it
SHOULD use different tokens.

Klaus

---

From: Carsten Bormann <[email-masked]>
Date: Wed, 11 Apr 2012 13:13:50 +0200

> downloading a representation in multiple parts?

Downloading (GET with Block2): No.  Why?

Uploading (PUT, POST with Block1): Yes, if server answers with M=1. 
(Not needed otherwise.)

> Plugtest seemed to assume this.

I didn't count them.  Yes, there were some prominent ones with interesting assumptions about Tokens, whether wrt Blocks or in some other ways.

> (a) the client MAY use non-empty tokens and

(Which is not new information.)

> SHOULD use different tokens.

Yes.

There is also:

   In this case, when reassembling the representation from
   the blocks being exchanged to enable atomic processing, the
   reassembler MUST compare any Token Options present (and, as usual,
   taking an absent Token Option to default to the empty Token).  If
   atomic processing is not desired, there is no need to process the
   Token Option (but it is still returned in the response as usual).

(which I think is the juicy bit.)

In the preceding

   If multiple concurrently proceeding block-wise request payload
   transfer (e.g., PUT or POST) operations are possible, the requester
   SHOULD use the Token Option to clearly separate the different
   sequences.  

I now think that "use the Token Option to" is confusing language.
This is not about sending a non-default value.
As the Token Option has a default value, there is no way to not "use" it.
What was meant was not that you go ahead and send non-default values (that isn't even always necessary), but that you use it in a way that different Block1 sequences between the same endpoint pairs have different Token option values.  This apparently needs to be clarified.

Grüße, Carsten

---

From: Klaus Hartke <[email-masked]>
Date: Wed, 11 Apr 2012 20:29:18 +0200

> (which I think is the juicy bit.)

The only situation in which the client is the reassembler, is when it
downloads a representation in multiple parts. Of course it needs to
compare the token in each response to the token it used in the
request, otherwise it would not be able to match a response to its
request. But there is no statement that requires a client to use a
certain token in its requests.

Klaus

---

From: Carsten Bormann <[email-masked]>
Date: Wed, 11 Apr 2012 23:22:15 +0200

> certain token in its requests.

This is in the context of Block1 ("block-wise request payload transfer"), so the server is the reassembler.

Grüße, Carsten

---

From: Bert Greevenbosch <[email-masked]>
Date: Thu, 12 Apr 2012 06:18:55 +0000

<snip>
</snip>

This relates to my earlier comment on combined Block1/Block2 in a Put/Post request. To the last block in a Put/Post request, the server can send multiple responses, using the Block2 option. As the client does not send new requests, the server has to maintain the same token in those multiple responses.

This may be taken even further, as also for small Put/Post requests, that do not require Block1, the server may want to respond with a larger payload in its response, and thus use Block2.

Best regards,
Bert

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Klaus Hartke
Sent: 12 April 2012 02:29
To: [email-masked]
Subject: Re: [core] draft-ietf-core-block-08 - Tokens in requests

Klaus
_______________________________________________
core mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/core