Subject: Re: [core] #245: Compression vs. Block

From: "core issue tracker" <[email-masked]>
Date: Mon, 05 Nov 2012 18:48:17 -0000

#245: Compression vs. Block

Changes (by cabo@…):

 * owner:  draft-ietf-core-block@… => cabo@…
 * status:  new => assigned

Comment:

 Assuming that there is no further discussion, I'll reflect this
 clarification in clap-11.

-- 
-----------------------------+--------------------------
 Reporter:  cabo@…           |       Owner:  cabo@…
     Type:  other technical  |      Status:  assigned
 Priority:  minor            |   Milestone:  post-WGLC-1
Component:  block            |     Version:  block-08
 Severity:  In WG Last Call  |  Resolution:
 Keywords:                   |
-----------------------------+--------------------------

Ticket URL: <http://trac.tools.ietf.org/wg/core/trac/ticket/245#comment:1>
core <http://tools.ietf.org/core/>

---

From: Klaus Hartke <[email-masked]>
Date: Mon, 5 Nov 2012 21:08:58 +0200

> The intention is to transfer the content-coded representation,
> which is sliced up in blocks.

Isn't one use-case of -block the retrieval of a part/slice of a
representation without necessarily retrieving all parts? How does a
client decompress such a slice? Or is the use-case not applicable for
compressed representations?

Klaus

---

From: Carsten Bormann <[email-masked]>
Date: Mon, 5 Nov 2012 14:24:59 -0500

> compressed representations?

There are indeed compression schemes that allow you to independently work with slices of a larger data item.
Unfortunately, these typically require some flexibility in the size of the compressed slice to remain efficient.
-block doesn't have that: Everything is a power of two.  So if you need to do this, -block is a bad match.
I'd expect you are better off using URI parameters to select the slice then.
But I don't know a specific use case*) for that, so I can't discuss this very intelligently.

Grüße, Carsten

*) apart from compressed paging, but I don't think this is very relevant here.