Recorded by Dean Willis

3/7/05 13000-1500

RPIDS

Henning Schulzrinne

Slides presented

Issue: Debate on "unknown" element for lists (like activities) -- "empty" vs "null" Do we need to be able to distinguish between an empty element and a non-existent element?

Noted that we use the same syntax for both publication and notification. Should we include discussion of the composition aspects of the schema?

Argued: We don't want to use the presence documents themselves as a statement of policy on composition functions. If it tells the presence service how to do something, it doesn't belong in the presence document.

Comment: Is this just a terminology issue: If we replace "unknown" with "other", would that solve the problem?

Comment: it seems to be useful to have the ability to differentiate an explicit assertion of neutral state vs a state about which no assertions are being made, independent of the composition policy.

Poll: Should we include unknown elements at each enumeration? Rough consensus in favor of inclusion.

Issue: Do we include source/type identification? This seems to be problematic from an authorization perspective, and impossible to completely enumerate. Proposed that we exclude source/type identification from the current effort. Proposal accepted.

plans are to release -06 immediately after IETF 62.

Presence Data Model

Jonathan Rosenberg

Slides presented.

Changes since last rev reviewed.

Open Issues:

Issue #1 Do we need an enumeration of services? A service registry has been proposed. Author proposes not, that reach information suffices.

Comment: The reach information is useful and adequate to solve the problem.

Noted: Reach information is a child of tuple, not status. This needs to be clearly stated in the document.

Comment: The examples need to be consistent with recommendations in callee-caps.

Note: Add discussion about the interpretation of non-existing data to data model. Prescaps need to follow the callee-caps model.

Issue #2: Available IM, Not Audio

Do we need to address this in the data model? Author believes the current text leaves the decision open.

Consensus to add to the data model words indicating that capabilities can change, and to include example possibly based on Aki's example.

Debate point: Just because I'm busy for IM, it doesn't mean I can't receive IM. Can we distinguish between capabilities and availabilities? Does "future status" work? It might if we eliminated the target time for future status -- "I expect to be available for calls sometime".

Issue #3: Three Dimensions

Do we need to model these in the data model? Proposed "No". Consensus reported on this proposal.

Issue #3 Device ID URN

Proposed to note that these things can change, that they can be derived from different things, and punt the detail implementation for each of these to new drafts.

Issue that we need to be able to differentiate an correlate information from separate devices vs. correlate information for one device with multiple IDs.

So, what's the problem with UUIDs? Since they are randomly generated, sometimes from a MAC, can they be correlated with a MAC address? Are they "invertable? Arguable that they are not -- one cannot assume that just because a UUID has a MAC address in it that the UUID is from the device that has that MACC address.

Action Item: We need to check on relationship between UUID and ESN, MEID, IMEI, and IMSI from mobile worlds.

Noted that this mechanism works, it just works better if we have more information.

Proposed: To note that the draft use a UUID URN as the baseline, and allow others as available. Rough consensus observed.

Issue: Multiple device IDs.

Noted that we need to clean up the difference between the device-ID element and the ID element of the device. Rough consensus reported on a single device ID per device.

Presence Authorization Rules

Jonathan Rosenberg

Slides presented

Changes since last draft reviewed.

Issue #1: Blacklists and matching.

Proposal offered by author. Response controversial. Noted that real world cases seem to require cross-domain listing now.

Much debate ensued. Author will add many caveats about identity minting. Henning and others will discuss additive properties.

Poll: Inconclusive.

Issue #2: Glob Matching

Proposed and accepted; do not add this feature.

Issue #3: Filter-based sub-handling

Proposed: leave as is; Accepted.

Issue #4 Tel URI

Action item: Make sure it works with tel URI as an identity.