Subject: Re: Related BoFs

From: "Aaron E. Walsh" <[email-masked]>
Date: Sun, 3 Dec 2000 16:06:03 -0500

Hi Leslie and Michael, thanks for the headsup on the
content/caching/resolution BoFs. Is there a specific list or reflector
where this discussion is taking place? I couldn't make the San Diego
f2f, but would like to participate in the conversation if it's not on
this list.

Regards,

Aaron
--
-------------------------------------------------------------------
Aaron E. Walsh  http://www.mantiscorp.com/people/aew/  617.350.7119
-------------------------------------------------------------------

Leslie Daigle wrote:
>
> 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]
> -------------------------------------------------------------------

---

From: Leslie Daigle <[email-masked]>
Date: Mon, 4 Dec 2000 23:08:31 -0500

Hi Aaron,

Hmmmm, now that you mention it, I should announce this BoF on
the URN mailing list :-)

So, no, this is not being discussed on the URN-IETF mailing list;
as far as I know, there is not yet a mailing list for it.  It's
a few ideas that have come together, and the BoF will be the
first real chance to see which parts have resonance to get work
done on them now-now.  So, I imagine some more particular mailing lists
will get set up as a result of that.  Sorry you won't be able
to make the meeting itself, but stay tuned...

Everyone -- the relationship of the c15n BoF to URN work is (in
my opinion) fairly complementary.  In various discussions, it
became apparent that URN resolution mechanisms are (or at least,
have been) fairly focused on providing top-down, authoritative
(from the URN assignment point of view) resolution pointers.  There
are times when the appropriate thing is to start from "where you
are" and work out a more locally-appropriate target for resolution
of an identifier.  This is why it's called "contextualized".

I'll post info here on whatever comes out of the meeting in San Diego.

Cheers,
Leslie.

--

-------------------------------------------------------------------
"Days used to be longer."
   -- ThinkingCat

Leslie Daigle
[email-masked]