[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
What is CONTENT?
- To: <firstname.lastname@example.org>
- Subject: What is CONTENT?
- From: "Mark Day" <email@example.com>
- Date: Tue, 7 Nov 2000 18:09:23 -0500
- Delivery-date: Tue, 07 Nov 2000 15:11:35 -0800
- Envelope-to: firstname.lastname@example.org
The current (-02) draft of the model document includes a formulation of
CONTENT in terms of CONTENT DATA UNITs. No-one on the design team seems to
like this approach very much. I am happy to replace these definitions or
eliminate them entirely, but I find the leading proposed replacement
Barron's suggestion is that CONTENT is a "typed finite sequence of octets."
While this is correct, it seems incomplete.
I think that we need to get across the following points:
1. We are talking about digital content -- that which can be sensibly
carried over IP. ["Typed finite sequence of octets" does this OK -- leaves
out non-octet aligned formats, but are there any worth worrying about?]
2. There is a wide variety of digital content, and we don't want to
inadvertently preclude using a CDN to carry some interesting future format.
Particularly, we have to avoid building file-only CDNs that preclude
streaming delivery and live-stream delivery. ["Typed finite sequence of
octets" is misleading here, I think. For example, a live webcam delivers a
finite sequence of octets but its length is unknown at any point before it
ends, and it is wiser to treat it as a potentially endless source of data.
Any given network packet contains only a short sequence of octets, but
CONTENT refers to the user-level content being moved, not what's inside any
3. When resources are scarce, there is a fundamental tradeoff between
accurate (bit-complete) delivery and timely delivery. A CDN can be asked to
guarantee one or the other, but not both; when it is asked to guarantee
timely delivery, it must also be told what can be dropped, and under what
circumstances. (Bit-complete accuracy doesn't require any understanding of
the format, only ensuring that all the bits are transported accurately).
[Surfacing this issue was the primary motivation for the CONTENT DATA UNIT
formulation, but it didn't do the job very well. However, a "typed finite
sequence of octets" does worse.]
I would welcome other possible solutions to the problem I've outlined. In
the absence of other comment or proposals, I plan to use the "typed finite
sequence of octets" definition, and find a place to include these issues as
notes elswhere within the model document.