Publish: go right to open issues The versioning information in body requires global clock sync Proposal: CSeq orders pubs from particular client. Each tuple assigned a timestamp for the tuple. Subsequent updates use If_Unmodified_Sinc header. If violated, server responds with 412. If multiple tuples, the unmodified since applies to all. An automata will not override without human interaction. RJS: Likes it, but there is a case to invisitigate. Might require more explicit decision to override. When automota wakes up and sends first thing, it will not have unmod-since header. This only applies when it first comes on network. JDR: Not a problem, like tuple-ids. Only case to be confused is when reading existing tuple, you know their is existing state. RJS: THen in no case would you configure publisher with tuple-id. Must be created or learned everytime it wakes up. JDR: Doesnt see why rjs: Problem when automata wakes up and conflicts. jsr: should store persistant last-modified. rjs: Need to document that requirement. jp: jdr and he talked last night, not on same page. Model assumes things publish when they have new info but not any other time. automata may be publishing based on something not current. Why would it do this at all? adam: cat bumps keyboard. jp: This is problem where we accept most recent publication rather than most recently created tuple. Do not necessarily occur at same time. keith: FIne for continued activity, problem when pc first comes up. jp: why? robert: maybe it publishes calendar jp: that is important--speculative info. Freshness based on _when_ the tuple created, not on speculatin of future. Better to use timestamps, even with clock sync problem. Otherwise, we need explicit rules to prevent conflicts. robert: Even with timestamps, what if 2 things think they are authoritative. jp: Only create tuples when there is activity. jr: imposes requirements on deciding what timestamp is. refreshes are odd jp: refresh when you know info is active. allow to expire if not interactin with user. Ben: what about intervening actions between intering speculative things and when they take effect. adam: could put time to take effect. robert: 412 prevents conflict when old device things it is authoritative jp: if it thinks it is authoritative it will overite rs: the whole point is how to tell it it is no longer authoritative. jr: that requires human interaction to make something authoritative. rs: network action can remove authroty, but human requried to give it. aki: it does seem to work--can override zombie publisher if it requires human interaction to turn back on. jp: creates human and admin problems. aki: 2 more issues--CSeq when publish does not have dialog. How do you id tuple? jr: may not matter--client never starts transaction until most recent pub completed. CSeq not really needed. aki: if 2 things pub same tuple, need synced id jr: when you override, you first look at precence and see the ID. rs: doesn't matter other nokia (on): does this require SIP to be protocol to get tuples jr: needs to support semantic. rs: preservation of tuple id not important at comp if comp is consistent in tuple ids in its output. aki: No, because you need the input ID rs: true adam: creates one-second race condition window. propose make it into an integer version number rather than date aki: put a cookie in there room: restart problems jr: probably ok.http also lets you learn how stale stuff is. If not needed, sequence number is best. adam: info could still be included. pk: do all fail if one tuple fails? jr: next slide: do we pub tuples independently? multiple tuples or non-tuple data make things hard. what about pidf note? jp: use data manipulation system jp: what about absense of compositor? what if notification comes from multiple sources? to what degree would watcher perform similar analysis? Having trouble articulating question. jr: can someone provide a use case where this does not work? aki: works with adam's fix. jr: (back to paul's problem) requirement that pub fails or succeeds atomically. speaker: how do you know which conflicted if multiple exist. jp: need to have text describing the human interaction meaning. jr: can we describve case where you cant determine authority paul: what about aggregate presentities (multiple people) jr/rs: right down that we don't care about people conflicting aki: If refresh never overrides new data, problem should be fixed. jr/rs: can override if human decides. jr: repeat problem about changes happens in future. did not think the not-effective-till header was not popular. bs: neither model works aki: only need to solve refresh overriding new data. jr: allow user to set timestamp that state was created. something makes context specific determination if authority. bs: can we use something like a q number? jr: we have had that problem elsewhere aki: This is where default state comes into play. (jp does not like) jp: if it needs to be removed, it is not soft state. jr: automata do not manipulate default at will. jr: q value not unreasonable, but how do you select across devices adam: instead of q values, might decide descrete publishing contexts, and assign priorities. jr: propose use timestamp and user interaction for now, leave rest for future. aki: cant we put source info in tuple (adam's proposal with new words) paul: more flexible if policy chooses ordering, not spec aki: can add on later jr: made progress on discussion, but have not concluded anything jp: proposal, allow both timestamping and user-info, make local policy driven decisions. aki: what if new gets deleted? jp: getting back to defining what presence is--should publish what is happening now. Number of tuples: can you pub with multiple tuples, or each in separate pub. Can do it, but need some additional indication of which went wrong in a failure. rs: anyone object to a single tuple? . [limit to one tuple.] What about note? Seem to be okay to use data manip for note. adam: is this for other event packages? Intended to be useful for other packages. Other packages must define their atomicity. rs: do you also have to define document structure? Need to think through in terms of generic packages. (need text in document about this) For presence, tuple and whole pres-doc makes sense. pres-doc means "here is my doc", tuple means " merge this tuple" Publishing a tuple requires an tuple xml fragment to be defined. Lable vs id (solved earlier) Number of documents: scope of publish is for any event package. should we have one doc for pub, and another for precence details? Chair: editor discretion adam: Should split. [decision: don't separate] Deletion with expires:0 To delete tuple, pub with expires:0. Spec says body is empty. What tuple are you deleting? could use body with matching tuple id, or tuple id could be in header, with only value in body. [decision: use minimal tuple in body with value closed] CSeq and call-id: spec says resuse call-id and increment CSeq, but server never looks at these. With versioning, onlu id and timestamp matter. Proposal: remove call-id and CSeq rules. [decision: remove them] Call Forwarding: user forwards Aor X to Y. SOmeone publisehs to X, goes to Y. compositor looks at to fied to determin AOR being published to. Seems wrong. Proposal: ESC should look at request-URI to determine AOR. Does not work in call forwarding case. Don't want to delegate sub and pub for short-lived call forwarding. Solution:L call forwarding apps should only look at invite. robert: would you not put method dependent routing in place? adam: even with subscribe, this causes problems. demultiplexing on method is not what you want. Keith: need to discuss forwarding device intelligence. jr: where does it go? [No decision about where it goes, except somewhere else.] Migration: When migrating subscription, the UA needs to have the state of presentity. If others are publishing, you need publish to migrate too. Will be an interval before new PA gets all publishes. Proposal: ignore this adam: new PA could do a fetch before migrating, [decision: ignore it, maybe put in a note mentioning we thought about it. Will take action to capture somewhere, not in this doc] jdr: propose stop here, take rest to list. *****Topic change to XCap: Who has read? Will give a little tutorial, but not much. submitted xcamp, buddy list usage draft. authorization policy usage draft coming soon. Do people like the direction? kd: yes--but at what point does IETF just define xml and let world figure out how to use it. A good amount of semantics on how to interpret xpath spec. rjs: fits in spirit of providing baseline mechanism. person on bridge: supports protocol and rjs statement. [chair action to determine how to move items to wg item status] Issue 1: separating document and component identifiers HTTP URI has part to id doc, and query string id'ing doc-part. Should we use a # to separate them? should we not separate at all? Proposal:# rjs: do not try to separate only with path sep. adam: # does not go out on wire--client side interpretation only. Not sure if that if 2616 or just common usage. [Adam will check] [Adam - must not include fragment on the wire] Adam: suggests we use separator, figure what out offline. Issue 2: Multiple components: Get, put, post only address single component. No easy way to set a number of things in one atomic transaction. Could set common parent tree, but inefficient. We do have an atomicity requirement. could make xpath string point to multi things, and put several in body in order. Proposals:1, only allow whole common subtree. (not common case) 2. build some sort of wrapper for multiple component in body. Is it a problem to do N separate transactions instead of one atomic? rjs: Think about manipulating auth policy. Can you create incorrect or inconsistent state after individual transactions, where you need multiple operations in atomic xaction? Adam: gives some examples. One possibility would be to lock the document with webdav, make changes, unlock. [RJS: to move forward, we need to scetch some use cases.] [Investigate whether webdav locking solves problems.] If we use locking, consistency requirement only needed at end of lock. Issue 3: Metadata XCap does not allow xpath to include metadata functions. Do we want to allow them? [no] 4: Server Awareness: Spec says server must understand the application. May be possible to relax for some situations: no computed data, no data constraints, baseline auth policy. Do we want this? RJS: propose define a "datastore" application that meets this requirements for generic use for things that can live with it. Base spec can be silent, this can be done in future. [Accept rjs proposal] 4.1 XML extensibility Application usage defines schema, which server must know. What is schema is extensible and user requests something in an extension the server does not know about? Proposal: server must understand all namespaces. 5. Server Authorization XCAP has trivial default auth policy. More complex ones must be defined by application. Is this ok? aki: HTTP only has digest for identity. BTW, this is close to netconf. They are aware, not many comments opposed, but could be issue with IESG. ng: How does server recognize related application usages? The auth policy usage must specify this. kd: Conferencing will have similar problems for group management. Do we expect that to work the same way? The conference control stuff is command oriented--this does not fit well. Setting up static policies and group lists, etc, may fit. xcap not yet discussed with conf design team. [Found no reason to object to proposal] 6. Put vs Post XCap uses put to replace, post to append (add sibling) Put not quite right because get(put(foo))<> foo. Proposal: use POST, use query string with replace or append parm using "?" delimiter. RJS: will make proposal giving common semantic for creating things at a particular level. RJS: proposal good in concept, need to figure out syntax. adam: how do you create doc in first place? jr: Also post. 7. Do we need to talk abouot HEAD? Proposal: mention for completeness. Chairs: Good meeting, please send notes. Will form design team for whats a tuple.