Monday, March 7 at 1300-1500

Tuesday, March 8 at 0900-1130

=============================

CHAIRS: Robert Sparks <RjS@xten.com>

        Hisham Khartabil <hisham.khartabil@nokia.com>

AGENDA:

Monday 7 March 1300-1500

10m 1300-1310 Administrivia

5m 1310-1315 RPID/cipid/future

• Henning has added "unknown" elements to allow override

• Need to distinguish between what's in a presence document and what's policy about presence - directives to presence servers, etc.

• We haven't figured composition out yet, and Jonathan doesn't want to rev presence trying to accommodate unknown requirements

• You may not want to tell people where you are, you just want to say you're unavailable, etc.

• Need to get consensus on this quickly, people are starting to base products on this work - hum is to include "unknown"

• Should we include source type identification?

• Jonathan concerned about feature creep, especially including authentication for this information

• How many sources of information are there? Don't want an enumerated type because we'll be constantly adding sources

• We will not include source type identifucation in this draft (room consensus)

• Do we need more than example scrubs for revision 6? Want to reissue this right after IETF 62

45m 1315-1400 Presence Data Model

• Significant revision - cut the document in half, taking out processing into separate processing document

• Allow multiple devices, services, persons with same URI/device ID

• "Instance ID" needs to be renamed so won't be confused with GRUU

• Include metadata (timestamp, notes) for humans to resolve ambiguity

• We still have one person, with multiple documents that include information about that person

• Not finished with schema rework

• Presence documents have infinite meaning, without reference to transport, composability, etc. - meaning cannot be context-sensitive

• Broke service component into pieces, added reach information - URI plus anything else one has to do to contact the service (add video to SDP, etc.)

• Capabilities aren't reach information

• Fixed up tel URI in contact

• Added "available for IM, but not voice" service status

• Service is anything you can define with a set of properties

• Issue: Service identifier - do we need an explicit service identifier? Not just Doom, but Push-to-Talk as well - not sure OMA PTT would even interoperate if we DID define explicit service identifer for it - please send a draft if you disagree, and make sure it fits in the data model

• Guideance about reach URI? need more in this document? Is prescaps sufficient? Reach information is enough for this document - does more than that have to be defined in the IETF? Reach information is a child of tuple, not of status

• What about defaults - if you don't mention video, do you have it? Are we ever going to address this? Is it the same answer for prescaps and other domains? Non-existent really is unknown - don't guess why they didn't mention it. Phones aren't going to announce an increasing list of stuff they don't support over time

• Can we at least say that callingcaps and prescaps will be the same? And update the examples?

• Issue: How to say "Available for IM but not audio"? - Draft doesn't propose a single approach (boolean function of media sessions or indicate IM capability only). Presence needs to be presence NOW, dynamic - this isn't LDAP. If we say capabilities can change in the document, is that OK? Seems to be OK, in the room. Cullen - there's a difference between "busy" and capabilities, right? Henning - why announce capabilities that you'll never use?

• Issue: Device ID URN - not a UUID URN, not a GRUU Instance ID, MAC is problematic (can have multiple MAC addresses, MAC addresses can change). Leave Device ID concept in the data model and then figure out how to construct one? A random number, a MAC address, an ESN ...  What you want to correlate with is also important. We punted this to allow the OS to figure out what a device ID is, but it won't stay punted. What's the problem with UUIDs? If the MAC is a visible part of the UUID, is all this going away anyway?

• Can a device have multiple device IDs in different contexts? Then we have to describe the relationships between contexts... Concerns about dragging bytes out of a device ID that might be a MAC address, etc.

• We have two device IDs, and we need to change one of them - this is confusing everyone including Jonathan

30m 1400-1430 Presence Rules

• Significant update since previous version

• <sphere> is problematic because we can unsubscribe people with no idea when they should try to resubscribe

• Added detailed rules for subscription handling, including a case that wasn't included at all

• Timestamp, basic status, contact and device ID are mandatory parts of presence documents, but some ID parts can be hashed or returned as random each time

• Blacklisting is still problematic in the current model - model is additive, with no way to exclude people from "everyone". Identities are easy to generate (not even "forge"). Proposal is to distinguish between authenticated identities and unauthenticated identities - is this OK? Why will blacklists work better in the long run here than they do in e-mail now? Does limiting to a single domain solve enough of the problem? Even AOL buddy lists can have non-AOL identifiers.

• "Everyone in the world except for these two guys" is problematic. We already do "domain except", and this is already vulnerable to identity-minting. Call for sense of room on need for exceptions to <any-identity> matching - but humming was very weak in the room.

• Glob-based matching is cool but feature creep - can we summarily shoot this now? Yes.

• Filter-based subscription handling is cool but feature creep - can we summarily shoot this now? Yes.

• Tel URI identities as watcher identities?

Tuesday 8 March 0900-1130

30m 0900-0930 MSRP (Base and Relay)

• Base protocol is now up to version 10 (under this document name)

• Biggest change is to SDP handling based on strong guidance of MMUSIC chairs - still using Path attrribute, but address and port copied to c= and m= lines for any other devices that see the SDP

• Protocol field changed to msrp/tcp

• Reference is now to SDP-New

• New response codes, mostly for relay work (408/timeout, 413/stop sending message, 423/parameter out of bounds)

• Added security consideration language about TLS implications of running peer-to-peer vs with relays

• Two new list issues recently - MSRP allows incremental ACKs/should sender be able to express a preference? List consensus looks like "no" - failover to new connection can give overlapping byte ranges/should use new data if you can, but don't have to if you've already rendered the old data. Not sure we need a clarification at all - can use note instead of normative language

• Working group last call for Base draft starting now

• Biggest change in relay draft is to Basic instead of Digest - over TLS, this is as strong as digest and easier and faster because there is no challenge

• Lots of organizational changes to relay draft

• Added Max-Expires, text about multiple relays

• Do we need stateless relay implementation in this document? It's a separate appendix with no normative language now - Ben is concerned that the normative/non-normative distinction is lost on people outside the IETF and they'll say the conform to it. Will be removed in next draft

• Cullen thinks Relay is ready for WGLC now, but some cleanup could be done

15m 0930-0945 MSRP conferences

• Draft has been around for a while now

• Proposing a new DISTSEND MSRP method plus new MSRP headers (Distribution, DataTime)

• How to do nicknames

• Usage of Message/CPIM in MSRP conferences

• Notable requirements - all participants see same message sequence, determine identity (or nickname) of message sender, send a message to a subset of the conference

• How does MSRP insert DISTSEND messages into the message sequence sent to participants?

• Is there a chicken-and-egg possibility of changing lots of protocols to accommodate XCON? If this is a general problem we need a solution that's not tied to a single media type.

• Is anyone keeping the conference framework up to date with what's going on in SIMPLE, XCON, and SIPPING? Umm, no. We still need XCON to settle on conference rosters, etc. to move forward here.

• Need to move requirements for MSRP into XCON - we're doing piece-meal design of conferencing and need a general solution in XCON

• Meaning of nicknames is a huge disconnect on the list - Nicknames are URNs, not routable, but hierarchic - allow anonymity and provide scoping. Open issue - how to negotiate nicknames to guarantee uniqueness within a conference - this is not a simple problem and doesn't belong in this working group

• Proposed location of nickname issues depends on chosen solutions (blech!)

• Does failure of one recipient to receive a message prevent all recipients from receiving any more messages? No good answer here.

• Nicknames isn't IM and isn't XCON - it's either SIP or SIPPING

• Jonathan - as soon as you start to talk about nicknames you open all the questions you open for any kind of identifier - validation, scope, etc.

15m 0945-1000 XML Patch Operations based on XPath Selectors

• Purpose of draft is to remove overlapping parts of xcap-diff and partial-pidf which reference patch-ops

• Remaining bugs - Whitespace text node handling in <add> and <remove>, namespaces/comments/processing instructions, adding nodes immediately before or after an element that already exists in the patched document

• Jonathan is concerned about the scope of this document - is it an alternative to XCAP? If so, that's a problem we shouldn't be trying to solve - the mechanisms you're starting with don't care about whitespace, for example - draft isn't intended to replace XCAP, but many places in the document describe alternatives to XCAP operations

• Are we really producing a general XML transformation mechanism? In the IETF? This all comes back to scope

• We have a bunch of working groups inside and outside the IETF that want to transform XML documents - we should either do something very limited or come up with a general scheme that will be used by all these groups

• Multiple ways to do things isn't good for interoperability, and this is another way to change a document

• Need to support patch AND XCAP when you get a diff document back and want to do something else - this is not what we want to require

• Do we want to redirect this effort or engage with W3C on a general solution?

• Should we be using XCAP log format, and not a diff document at all?

• There is a generalized diff format open source implementation at sourceforge now - maybe this is a place we should go?

• If we do something general-purpose, it probably won't be in this group

• If we do something specific to XCAP, don't we still have to handle PIDF documents too?

• Room consensus - more general approach? narrow scope? no room consensus, taking this to the mailing list

15m 1000-1015 Policy capabilities / presence capabilities

• Expecting that clients will routinely connect to provider networks that don't understand all of the policies in use on that network - how to figure out what client does understand?

• Three drafts, two in SIMPLE and one in GEOPRIV

• sub-handling and component-id are recursive

• Adopt two SIMPLE documents as WG documents? Room consensus is to adopt both documents

5m 1015-1020 Prescaps update

• How to merge two documents with priorities that don't overlap/mutually exclusive?

• Some confusion about whether policy caps ended up with an enumeration or with numbers

• Do have open issues - update XML scheme according to SIMPLE XML, presence characteristics/status discussion

30m 1430-1500 Presence Processing

• Mostly the bottom half of the previous data model document, with few changes (for lack of time)

• Composing unknown attributes? Select one specific value - perhaps <ambiguous>?

• Overrides? Use most recent occurance based on INSTANCE ID, otherwise composition policy controls this

• Rest of open issues will be worked on the mailing list - there are actually quite a lot of them

60m 1030-1130 Schema design working session

• (Did not stay for working session)