Subject: [Simple] Data model compromise regarding unique service URI: summary so far

From: "Vijay K. Gurbani" <[email-masked]>
Date: Fri, 28 Jan 2005 16:26:27 -0600

Folks:

I have been trying to keep notes on the discussion we have been
having on Jonathan's compromise email on the unique service URI
and its follow ups.

This is the summary of that discussion so far; interspersed with
it are some other observations worth documenting.  These points,
at the very least, indicate how the design of the PDM is
influenced by our understanding of the problem.

Please look through them for sanity:

1) Everyone agrees on this: we allow for multiple services with
   the same URI, but in the data model very clearly define its
   meaning as *ambiguous*; additional tuple meta-data will normally
   need to be present to help clarify the actual meaning. As such,
   the data model would recommend against doing this without
   meta-data to further clarify (JDR).

2) Regarding meta-data, PIDF "notes" and "timestamps" elements
   are a form of meta-data.  We wish there was more meta-data,
   but there is a limited supply of "hard" meta-data.   The
   only major item we're missing is probably a better description
   of the source of the data (calendar vs. manual entry vs. a
   device vs. compositor).  Other meta data is likely to be "soft",
   e.g., indications of likelihood of correctness (HGS).
   We also have some meta-data in form of prescaps.

3) Watcher behavior: Do we want to define the behavior of a
   watcher?  Yes (HGS), No (JDR, PK).

4) Composition: Composers are allowed to be smart, but we cannot
   force them to be.  The problem is that the composer is a program,
   with at best limited rule-based intelligence, while the watcher
   is often staffed with a real human being that can, in many
   cases, make sense of conflicting information based on external
   knowledge ("I know that Alice is on vacation right now, so
   the location information placing her at home in this person
   entry must be from the cell phone she left at home.") (HGS).

5) Composition redux: We do not know enough about composition
   to prescribe a certain algorithm or manner of composing.  The
   best we can do right now is to specify a union policy as the
   default composition policy.  Smart composers can do more, but
   what that "more" is a function of the composer.

6) Composition redux II: Is it a requirement that a compositor
   have access to registration data?

6) Dispatching: Dispatching is a problem.  We cannot do it based
   on SDP since there may not be an SDP in an INVITE.  Dispatching
   based on something like method and event ID may run into problems
   as well. One can imagine folks sending SUBSCRIBE on an existing
   dialog, and using INVITE for setting up the dialog. If dispatch
   to something that supports SUBSCRIBE is based on the initial
   request method, this won't work either.  Dispatching based on
   caller-prefs is a possibility, but how would a watcher indicate
   preference for caller-prefs in a document?

Thanks,

- vijay
-- 
Vijay K. Gurbani  vkg@{lucent.com,research.bell-labs.com,acm.org}
Wireless Networks Group/Internet Software and Services
Lucent Technologies/Bell Labs Innovations, 2000 Lucent Lane, Rm 6G-440
Naperville, Illinois 60566     Voice: +1 630 224 0216

_______________________________________________
Simple mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/simple

---

From: Henning Schulzrinne <[email-masked]>
Date: Sat, 29 Jan 2005 05:21:22 -0500

>   watcher?  Yes (HGS), No (JDR, PK).

I think this is mainly a difference of wording, not opinion. I think we 
can agree that the information delivered to the watcher should be 
precise enough so that it can behave predictably. This includes the case 
where it may simply have to deliver the information to the human watcher 
with an indication of "I don't know which view is correct".

>   preference for caller-prefs in a document?

There are probably two options here:

(1) Usage of prescaps indicates ability to support caller preferences.

(2) Additional flag in prescaps that indicates such support.

I think (2) would be better. After all, support of caller preferences is 
itself a capability. It seems easy enough to add this to the prescaps work.