Request for Comment

I wanted comment on these ideas before I did anything with them. Note that 
the following contains very rough drafts.
		Thanks,
			Yaron

New Content-Range types. Currently, Content-Range only allows one to 
specify byte ranges. However there are often situations where one would 
like to be able to specify a page, a paragraph, or other arbitrary entity. 
It would be nice to be able to request the fourth page of an entity. Of 
course the request may not always be meaningful or the token type used in 
the request may not be understood by the server, but I do not believe that 
is a big deal. The spec for the header would be something like:
Content-Range = "Content-Range" ":" content-range-spec
content-range-spec      = byte-content-range-spec | token-jump
byte-content-range-spec = bytes-unit SP first-byte-pos "-"
                                 last-byte-pos "/" entity-length
entity-length           = 1*DIGIT
token-jump = jump-type number-jumps
jump-type = token
number-jumps = 1*DIGIT
A jump-type could be "Paragraph", "Page", or whatever. The number-jumps 
specifies which jump-type to set, retrieve, whatever. There are some truly 
ugly semantics here, for example, what if one PUTs a "Page 3" but the 
content is so long it leaks into "Page 4"? Is this a legal put? The problem 
would have to be dealt with on a jump-type by jump-type basis.

The document Judith sent out contained the following section:
RETENTION SCHEDULE / ARCHIVING / BACKUP / RESTORE
Create schedule for deletion based on any of the following:
last accessed date
author
any catalog value or set of catalog values
manual selection
Monitor deletions
Audit deletions
Notify based on schedule for deletion
Move infrequently used materials to alternative storage locations or 
devices
Automatically
Transparent to online users
Configurable
Configurable archiving
Evaluate for archiving based on: authors, creation date, document type,
keywords, last edit date, retention date, any catalog value
Incremental and full backups
Scheduled backups or manually initiated backups
Restore specific data or files from backup

Do we want to put support for these features into the standard? By 
supporting these items I mean moving the responsibility for ordering the 
events from the client to the server. We could add a delay header:
Delay-Header = "DelayHeader" ":" HTTP-date
I can hear the thoughts in the heads of several of you saying "But wait, we 
need a repeat header so we can say things like copy files to these URLs 
every Thursday of the month for the next year." This is known as scheduling 
and is a rat whole so deep that entire conferences have been lost inside of 
it. Trust me, you would rather send 12 DelayHeaders.

I realize that DMA is about as popular as an Electro Magnetic Pulse but 
someone (read: NOT ME) should really go through the DMA spec, 
http://www.aiim.org/dma/spec75/index.html, and see how well we measure up.

Currently there is no way to delete the contents of a directory. A 
directory is really just a sitemap file which allows one to group various 
unrelated URIs together. However if one were to want to delete all the URIs 
in the directory one would have to send delete requests for each URI. The 
logic extends if one wants to delete a directory and all its sub 
directories. One of the reasons for this behavior is that many of the 
common container commands, such as copy and move, have no meaning in this 
context. If I have a container with URLs foo/bar and bar/foo then the only 
way to copy them is to specify for each one where they are to go. If I 
order "copy foo/bar and bar/foo to foobar" what does this mean? However 
delete and undelete are different, they have a very obvious meaning in the 
context of our containers. Should we add headers in the mime-type for 
delete, undelete, and destroy to allow the command to be applied to the 
contents of a directory in a possibly recursive manner?

Received on Thursday, 31 October 1996 00:29:28 UTC