Subject: [core] Block names

From: Robert Cragie <[email-masked]>
Date: Fri, 13 May 2011 10:31:17 +0100

Block1 and Block2 are not very helpful names. As they are tied to 
request and response, how about something like BlockFromReq for Block1 
and BlockFromRsp for Block2 or something?

BlockFromRsp in Request -> (expecting) A block in response
BlockFromRsp in Response -> A block in response
BlockFromReq in Request -> A block in request
BlockFromReq in Response -> (received) A block in request

Robert

---

From: Likepeng <[email-masked]>
Date: Fri, 13 May 2011 09:38:56 +0000

> Block1 and Block2 are not very helpful names.
+1. When I read Block draft, I have to take notes to remind me from time to time which one is for what purpose.

> BlockFromReq for Block1 and BlockFromRsp for Block2 or something?
How about BlockReq and BlockRsp? BlockReq is for Put/Pust, and BlockRsp for Get.

Kind Regards
Kepeng
-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Robert Cragie
Sent: Friday, May 13, 2011 5:31 PM
To: core
Subject: [core] Block names

Block1 and Block2 are not very helpful names. As they are tied to request and response, how about something like BlockFromReq for Block1 and BlockFromRsp for Block2 or something?

BlockFromRsp in Request -> (expecting) A block in response BlockFromRsp in Response -> A block in response BlockFromReq in Request -> A block in request BlockFromReq in Response -> (received) A block in request

Robert

---

From: "Kovatsch Matthias" <[email-masked]>
Date: Fri, 13 May 2011 11:34:23 +0000

Hi

I also had comment on that and just want to merge them.
My idea would be Block2 --> Block-Down(stream/load/{}) and Block1 --> Block-Up(stream/load/{}).

Matthias wrote:
> > > Would it be possible to provide meaningful names for the Block options? 1 and 2 in the order 2 (=17), 1 (=19) might cause a lot of confusion...
> > > Block2 corresponds to server-side generated blocks and Block1 to client-side
> > > generated blocks, right?
> > > 
> > > So, what about Block-Server and Block-Client or suchlike instead?

Carsten wrote:
> > As long as people don't start to think Block-Server options are always
> > sent from the server and Block-Client options are sent from a client... 
> > 
> > We went through a couple of these (Block-Request, Block-Response...) and
> > decided Block1 and Block2 actually had the smallest confusion factor.  But I'm
> > open to any suggestion.  If people like B-S and B-C, I'm all for it.  (Spec
> > reception, again, is a funny thing.)  But let's brainstorm for good names for a
> > little more.

Bye
Matthias

---

From: Robert Cragie <[email-masked]>
Date: Fri, 13 May 2011 13:08:20 +0100

I put the 'From' in as both options can be used in either request or 
response, so BlockReq might seem as that's what only you use in a request.

I think the same could apply to your Size option for consistency:

SizeFromRsp in Request -> (expecting) A (maximum) size in response
SizeFromRsp in Response -> A size in response
SizeFromReq in Request -> A size in request
SizeFromReq in Response -> (would not typically occur as it's meaningless)

In this way, the SizeFromRsp option in a request could be used to inform 
the responder that the requester cannot handle any more than the size in 
the option (even if it is sent in blocks) and the responder can then 
simply respond with a 4.13 (Request Entity Too Large) if it knows the 
resource is too large, although it may be better to relax the name to 
just 4.13 (Entity Too Large) in this case.

Robert

---

From: Carsten Bormann <[email-masked]>
Date: Fri, 13 May 2011 14:58:45 +0200

> My idea would be Block2 --> Block-Down(stream/load/{}) and Block1 --> Block-Up(stream/load/{}).

If we have Up and Down, we inevitably will also get Charm, Strange, Top and Bottom.
(However, the latter four are much heavier, and therefore maybe not appropriate for a lightweight protocol.)

Gruesse, Carsten

---

From: "Kovatsch Matthias" <[email-masked]>
Date: Fri, 13 May 2011 13:09:54 +0000

> appropriate for a lightweight protocol.)

Is it just a problem with the abbreviations that one's mind could get tunneled to physics, or is there a real problem naming the the options according to whether they define an upstream or a downstream block? These are the two kinds of blocks we have, right?

Regards
Matthias

---

From: Robert Cragie <[email-masked]>
Date: Fri, 13 May 2011 14:50:53 +0100

There is no use of 'up(stream/load)' and 'down(stream/load)' in CoAP. 
Hence suggesting using Req (Request) and Rsp (Response), which are of 
course central to CoAP.

Robert

---

From: "Kovatsch Matthias" <[email-masked]>
Date: Fri, 13 May 2011 13:58:22 +0000

> Hence suggesting using Req (Request) and Rsp (Response), which are of

But we have servers and clients and upstream usually means client->server and downstream server->client.

I must +1 Carsten's opinion that Block-Req could be confused with "that option is to be set in a request and Block-Rsp in a response".

---

From: Robert Cragie <[email-masked]>
Date: Fri, 13 May 2011 15:06:08 +0100

Which is why is suggested BlockFromReq and BlockFromRsp

Robert

---

From: Linyi Tian <[email-masked]>
Date: Wed, 18 May 2011 09:24:03 +0800

Hi, All

If we agree with Charles Palmer's suggestion ( the size in the first
response returns the actual size of the data) then we don't need the
SizeFromRsp at all. The requester would know whether it can handle the data.

Cheers,
Linyi

>>Sent: Friday, May 13, 2011 8:08 PM
>>To: Likepeng
>>Cc: core
>>Subject: Re: [core] Block names
>>
>>> +1. When I read Block draft, I have to take notes to remind me from time
to
>>time which one is for what purpose.
>>>
request and
>>response, how about something like BlockFromReq for Block1 and
>>BlockFromRsp for Block2 or something?
>>>
>>> BlockFromRsp in Request ->  (expecting) A block in response BlockFromRsp
>>in Response ->  A block in response BlockFromReq in Request ->  A block in
>>request BlockFromReq in Response ->  (received) A block in request
>>>
>>> Robert
>>>
>>
>>_______________________________________________
>>core mailing list
>>[email-masked]
>>https://www.ietf.org/mailman/listinfo/core