Subject: Related BoFs

From: Leslie Daigle <[email-masked]>
Date: Fri, 17 Nov 2000 17:48:16 -0500

Howdy,

FYI, I draw your attention to the various content/caching/resolution
bofs to be held in San Diego on Tuesday afternoon.

In particular, this one tackles something of the converse of URN
(global) resolution, and is currently scheduled for Tuesday, 5pm-6pm.

Leslie.

-----------8<----------------8<----------------8<--------------

Contextualization of Resolution BOF (c15n)

Day, Date at Time
==============================

CHAIR: Michael Mealling <[email-masked]>

DESCRIPTION:

The URN WG's Dynamic Delegation Discovery System (DDDS) describes a
generalized architecture for 'top down' resolution of identifiers such
as URIs.  This works well when a (software) client wants or needs to
dynamically determine the explicit authoritative delegation of
resolution.  However, there are times when it is desirable to
incorporate other elements of contextual control information in
determining, for example, the  "appropriate copy" of a resource --
preferrentially finding a "local" copy of a journal rather than
(re)purchasing one from the authoritative publisher.  This is generally
applicable to all URI resolution, but it is more specific than "web
caching".  Software systems being built to solve this in today's
deployed systems are using specialized, non-interoperable, non-
scalable approaches.

Some current experimentation and a straw proposal are described below.

This BoF is chartered to determine if there is interest/wherewithal to
determine a standard vehicle to process contextualized resolution that

   a) is not application- or protocol-specific and
   b) ties in with global resolution systems (such as DDDS) in order
      to preserve authoritative resolution chains, where applicable

Beyond the "appropriate copy" scenario, this should equally be
applicable in non-document contexts -- e.g., IP-telephony (enterprise
dialing schemes taking precedence over, but linked to, global
numbering).

While the focus of this BoF is on standardized resolution
steps/mechanisms, not "metadata" or "knowledge transactions",
discussion must reflect that "context" generalizes beyond
location/area (e.g., to "who's paying for this", etc).

AGENDA:

  . Agenda bashing [2 min]
  . Introduction/Overview of C15N [10min]
  . Discussion of Straw Proposal (below) [20min]
  . Relationship to other work -- at IETF, W3C, etc [5min]
  . Discussion of proposed charter [20min]
  . Yes/no

All of the above should be considered in relation to the web-caching,
proxying, and content-delivery BoFs also occurring this week
(OPES, CDNP, WEBI).

Sample current implementation
-----------------------------

Some experiments have been carried out elsewhere -- e.g., the SFX
project described at:

http://www.dlib.org/dlib/october99/van_de_sompel/10van_de_sompel.html

and in

http://www.doi.org/workshop_19sep00/doi_wkshp_0900_llversion.ppt

Today, this work uses HTTP cookies -- so that the (web) client asks the
global resolution for an identifier (from a reference), and sends
a cookie which is a key for the appropriate context.  The
global system uses this key to redirect the query to the appcopriate
local knowledge server (address), which makes the judgement
about where an appropriate copy of the resource shall be obtained.

Straw proposal
--------------

As the starting point for discussion of how to solve this problem,
we propose the following optional additional steps for resolving
URIs in a contextualized fashion:

There are 3 primary elements:

        . context object -- the identifier and some description of
          context

        . local knowledge server [_not_ defined by us, or even
          by application; rather, we define the abstract operations
          for interacting with it]

        . application linkage to a global resolution authority
          (e.g., DDDS for URNs, http resolution standard, etc)

In order to ground the discussion in some semi-concrete proposal
a strawman proposal based on XLink for link typing and RDF for
context object expression will be used. In this case, the extended
XLink would relate three resources - the local resource, the desired
remote resource, and the RDF info containing the context. Each locator
will have a typed arc that determines the types of traversals
available. Additional discussion may include how this context object
may be passed to various proxies/caches for resolution based on that
context -- strictly as a tie-in with other replication, caching and
content delivery work under discussion at the IETF.

Xlink is described at http://www.w3.org/XML/Linking
RDF is described at http://www.w3.org/RDF/

Open questions
--------------

These currently include:

        . Can/should this be transparent to the client software, or
          must/should it be an external negotiation in a separate
          protocol?

        . Is this configured or dynamically controlled?

        . Is this "get appropriate copy", or "get appropriate
          transformation" (i.e., to a new identifier, appropriately
          contextualized)

        . Can this support multiple, overlapping contexts (e.g.,
          location and "who's paying for this")

--

-------------------------------------------------------------------
"Logic can hold only a certain amount of sway over the rational
 mind."
   -- ThinkingCat

Leslie Daigle
[email-masked]
-------------------------------------------------------------------