Re: High-level capabilities
David J. Fiander (davidf@worf.mks.com)
Fri, 07 Jun 1996 08:22:23 -0400
David G. Durand says:
> At 11:57 AM 6/6/96, Jim Whitehead wrote:
> >3. Retrieval of derivation relationships between versions of an entity: The
> >ability to trace the development and ownership of an entity provides
> >visibility into the development of that entity, and into the namespace of
> >version identifiers for versions of that entity.
>
> I agree that tracing ancestry relationships is useful. I'm not sure what
> kind of insight you can gain into the "namespace" of <em>opaque</em>
> version identifiers. You should be able to gain information about the
> relationships of specific instantiated items in the namespace, but more
> insight than that breaks the opaqueness of the version-id.
This retrieval of the the relationships can be accomplished two
different ways: create a new method: "HISTORY", or perhaps
"INDEX"; provide a cgi-bin which takes a URL and returns the
history. The former ensures that the functionality is always
available in a standard way, while the latter keeps the protocol
small.
> >4. Writing to a given version of an entity: Once changes have been made to
> >an entity, versioning policies often dictate that the changes be written
> >into a new, stated version of that entity.
>
> I think that this is mainly a server issue, not a protocol one.
While the server is the final arbiter when it comes to what, if
any, version identifier (VID) is assigned to a checked-in
version, the protocol should provide a mechanism for the client
to specify the desired VID. (This becomes important in an
SCCS-based environment, since SCCS allows a single user to have
multiple different versions of the same file locked. The user
must specify which version she's checking in.)
> >6. Parallel development support: Since it frequently occurs that multiple
> >people edit the same entity simultaneously, this type of activity must be
> >supported. User agents must be supplied with enough information to inform
> >their users when they are entering a parallel development situation, and
> >they must be supplied with the versions of parallel entities so they can
> >provide merge support for the entity contents. Futhermore, since it is
> >currently beyond the state of the art to provide merge support for certain
> >entity types (e.g., MPEG video), it must be possible to disallow parallel
> >development on these entity types.
>
> Server issue. I don't think this affects the protocol at all.
Given that the requirements of the (deleted) point 5 are met,
then yes, this is a server issue.
> >7. Visibility control: Through the user agent, it should be possible to
> >control the external visibility of an entity. For example, this is useful
> >for ensuring that working revisions of an entity are not accessible by the
> >entire world.
>
> This sounds like a non-minimal requirement to me, because it is another
> policy issue Some servers might control this automatically, or require
> manual intervention via some separet communication channel. Do we perhaps
> need a general protocol for negotiating server policy options? Then we'd
> have a way to standardize setting of such options, but leave the door open
> to the wide variety of different policies.
I agree with David. authorization (security) and authentication
(identity) issues are server issues. In the words of the ANSI C
standard, it's a "quality of implementation" issue.
> >8. Configuration support: The user must be able to create versioned
> >collections of versioned entities. When creating online documentation, an
> >author will create multiple pages, which may, for example, contain an HTML
> >document and supporting bitmap graphics and applet objects. The author
> >will want to make a versionable collection of the entities which comprise
> >each page, as well as a versionable collection of all the pages.
>
> This seems like the update portion of requirement 2. Seems like a
> non-minimal issue to me (except possibly again in dealing with the "current
> version").
Well, it's non-minimal but, in the long run, configuration
management is important. We have to leave room in the early
specification for CM to be slotted in later. One interesting
problem is that, given that a user has a set of pages that are
consistent, how does she check them <em>all</> in and ensure that
the server's view of the world is always consistent?
> >Note that you might not want all users to be able to employ all
> >capabilities all the time. For the development of these requirements, I
> >have assumed a super-user who would be able to do everything, all the time.
> >Access control mechanisms can limit which users can employ which
> >capabilities.
>
> We seem to be at policy again. I had been assuming that HTTP authorization
> mechanisms would provide sufficient security so that a server could
> implement whatever policy it wants.
David's right. This is quality of implementation again. A
server that hangs loose and lets just anybody check in or lock
pages, with no way to tighten access up, won't win.
- David