[06:16:21] --- reschke has joined
[07:03:14] --- LOGGING STARTED
[07:05:00] --- LOGGING STARTED
[07:08:02] --- LOGGING STARTED
[07:09:21] --- LOGGING STARTED
[07:11:34] --- LOGGING STARTED
[08:34:26] --- reschke has joined
[08:49:32] --- acmahen has joined
[09:01:10] --- warlord has joined
[09:01:36] --- mrose has joined
[09:03:41] --- hardie has joined
[09:03:51] --- anewton has joined
[09:05:35] --- acmahen has left: Disconnected
[09:06:52] <mrose> This message is encrypted.
[09:08:24] <mrose> stpeter [scribe] is booting
[09:09:57] --- eblanton has joined
[09:11:01] --- stpeter has joined
[09:11:10] <stpeter> sorry for the delay
[09:13:26] <stpeter> SEND failures: what about cross-session duplicates?
[09:14:26] <stpeter> client has a failure on a session, creates new session, resends on a new session -- does this require globally unique TR-IDs?
[09:15:42] --- acmahen has joined
[09:16:11] <stpeter> Jonathan Rosenberg: this should work in a world where TCP connections go away
[09:19:36] <stpeter> labelling a session for its purpose
[09:21:02] <stpeter> e.g., i send a large file to you, which clogs up the works -- now i can't use our session for some other purpose
[09:22:25] <stpeter> Rohan Mahy: I'm not commenting on particulars because I disagree with the requirements we're operating under here
[09:22:52] <stpeter> suggestion is to use distinct sessions for things like large content transfer
[09:22:56] --- avri has joined
[09:23:17] <stpeter> what keeps the other end from sending IMs on the session we intended for file transfer?
[09:23:30] <stpeter> MIME type may not be granular enough
[09:23:34] --- lisaDusseault has joined
[09:23:55] <stpeter> session teardown at visiting relay is currently done implicitly
[09:24:12] <stpeter> session destroyed when host connection goes away
[09:24:20] <stpeter> need an explicit operation? need to discuss
[09:24:31] <stpeter> SEND for keepalives
[09:24:53] <stpeter> relay uses SEND requests to determine "liveness" of a session
[09:25:12] <stpeter> endpoints periodically generate empty SEND requests
[09:25:31] <stpeter> this may be overloading of SEND -- better to have a separate keepalive?
[09:27:55] <stpeter> do we need to actively keep things alive in both directions?
[09:28:25] --- eblanton has left: Disconnected
[09:29:09] <stpeter> e.g., what if sending a large message to someone (unidirectional) -- seems wrong to require bidi traffic
[09:30:25] <stpeter> currently require a separate challenge per algorithm -- this is the way HTTP digest works
[09:30:47] <stpeter> do we want to allow multiple algorithms for the same challenge?
[09:31:18] <stpeter> Ted Hardie: the security people don't / wouldn't like this
[09:31:55] <stpeter> security considerations.... Cullen has offered to supply text on TLS certificate usage
[09:32:34] <warlord> uh oh -- do I need to show up to play "security people"?
[09:32:46] <stpeter> and Aki suggests more discussion of interaction between auth mechanisms, man-in-the-middle attacks on digest, etc.
[09:32:52] <stpeter> warlord: :-)
[09:33:06] <warlord> I'm serious -- do you guys need some security clue to show up?
[09:33:17] <stpeter> warlord: no, this will happen out of band
[09:33:20] <warlord> ok
[09:34:08] <stpeter> Cullen Jennings: I don't think self-signed certs will work in the two-relay case
[09:35:00] <stpeter> clean up MIME usage -- content-type syntax, etc.
[09:35:05] <stpeter> need to indicate MIME version?
[09:35:20] <stpeter> should content-type be part of the body?
[09:35:24] <stpeter> what about contenet-disposition and other MIME headers?
[09:36:29] <lisaDusseault> stpeter: any power outlets available there??
[09:36:31] <stpeter> Adam Roach: we should support all the MIME headers
[09:36:38] <stpeter> lisaDusseault: i think not
[09:37:00] <stpeter> lisaDusseault: just unplug someone :P
[09:37:25] <lisaDusseault> lisa is power thirsty ;)
[09:37:32] <warlord> Slirp
[09:37:35] <stpeter> examples: more are good, but could be in separate draft
[09:37:49] <stpeter> congestion issues!
[09:38:02] <stpeter> "are we trashing the commons"?
[09:38:28] <stpeter> several people have requested more discussion of congestion, esp. with regard to sharing connections
[09:39:39] <stpeter> Rohan Mahy: if congestion is a problem, would we support chunking etc.?
[09:39:56] <stpeter> Rohan: the zero-relay requirements are clear
[09:40:24] <stpeter> Rohan: 1+ relay introduces a different set of requirements, which are complicated
[09:41:21] <stpeter> relays mean you have more connections overall, but the additional connections are at the fringe
[09:41:53] <stpeter> Jon Peterson: we discussed this a year+ ago and consensus was that the zero relay case is not useful enough to specify
[09:42:20] <stpeter> Rohan: most pressing is to address relay case (enterprise-to-enterprise)
[09:42:56] <stpeter> Jon Peterson: this is more of a "hearsay" requirement than anything else
[09:43:11] <stpeter> "large providers of IM" have not stepped forward to press on this point
[09:44:52] <stpeter> Cullen Jennings: sending a 1k message every 10 seconds -- is there some level of guarantee that such traffic will get through?
[09:45:37] <lisaDusseault> Is a large provider of IMs a spammer??
[09:45:41] <stpeter> a large provider steps forward to say "connection re-use is a requirement"
[09:45:52] <stpeter> lisaDusseault: who *was* that large provider?
[09:47:36] <stpeter> Jon Peterson: requirements for multiplexing relays are very large (logging, archiving, security, etc.)
[09:47:42] <lisaDusseault> We don't know who that was.
[09:48:05] <stpeter> someone large, though
[09:50:48] <stpeter> perhaps the endpoints don't need to support chunking, but relays or other entities could
[09:51:15] <stpeter> Jon Peterson: we decided previously that MUXing is out of scope
[09:51:45] <stpeter> multiplexing has been out of scope until now
[09:52:18] <stpeter> Ashvalom Houri: may be a bigger issue (at the SIP level, not SIMPLE)
[09:53:25] <stpeter> suggestion to look at TCP multiplexing (been around for a long time)
[09:53:50] <stpeter> (suggestion from Dean)
[09:54:27] <stpeter> look at multiplexing later, but don't do anything now that precludes that later
[09:55:11] <stpeter> Rohan: if we build multiplexing later but it doesn't work, can we deprecate relays?
[09:55:50] <stpeter> Rohan: the people who want relays (may) want relays with multiplexing
[09:56:45] <stpeter> Dean: take MUXing out of MSRP, put it in a separate draft, see if we can make it work
[09:57:00] <stpeter> Rohan: no one wants relays without MUXing
[09:57:32] <stpeter> scribe says: sounds like we need to do some market research...
[09:58:14] <stpeter> Ted vetoes the need for an MSRP Relay WG
[09:58:29] <stpeter> hum: are relays without multiplexing useful?
[09:59:15] <stpeter> hum result: yes, they are useful
[09:59:46] <stpeter> hum: what implementers will implement MSRP?
[10:00:41] <stpeter> hum: who would implement relay only, vs. relay with MUXing?
[10:01:11] <stpeter> much weaker hum to implement relay only for NAT traversal vs. relay with multiplexing?
[10:01:27] <stpeter> hum: should we rip out relays, but it in a separate document?
[10:03:43] --- lisaDusseault has left: Disconnected
[10:04:20] <stpeter> Ted Hardie: ok to pull muxing in a separate document, but set a deadline for coming up with a theory on this (and make it in the near future)
[10:05:32] --- acmahen has left: Replaced by new connection
[10:06:37] <stpeter> Aki Niemi: some people will want to use relays for things other than NAT traversal -- e.g., for policy enforcement, charging, etc.
[10:07:39] <stpeter> Cullen: concern that we're pulling things out of MSRP that make it compelling
[10:08:23] --- lisaDusseault has joined
[10:09:42] <stpeter> consensus seems to be that we remove relays from MSRP
[10:10:38] <stpeter> Cullen: TLS will become unusable once we remove relays
[10:11:03] --- acmahen has joined
[10:12:01] <stpeter> Ben to work with Dean on issues that have been raised on the relay side
[10:12:37] --- resnick has joined
[10:13:23] --- resnick has left
[10:14:24] --- resnick has joined
[10:14:49] <stpeter> Robert Sparks: Presence Document Usage
[10:15:14] --- resnick has left
[10:15:41] <stpeter> several use cases: presence aware voice phones and multimedia devices, etc.
[10:15:42] --- resnick has joined
[10:16:10] <stpeter> can you associate a tuple with a "service"?
[10:16:27] <stpeter> current thinking: a service is indicated by a set of attributes
[10:16:52] <stpeter> goal: attempt to list a core set of services and the attributes that indicate each service
[10:17:17] --- resnick has left
[10:17:31] --- resnick has joined
[10:18:22] --- lisaDusseault has left: Disconnected
[10:19:09] --- lisaDusseault has joined
[10:19:31] <stpeter> brb
[10:19:54] --- resnick has left: Disconnected
[10:19:56] --- resnick has joined
[10:20:04] --- stpeter has left: Disconnected
[10:21:56] --- stpeter has joined
[10:21:58] --- hardie has left: Disconnected
[10:21:58] <lisaDusseault> [taking up stpeters slack]: Ben has a concern with all the use cases, the document being an input not a all-inclusive collection of use cases
[10:22:26] <stpeter> sorry, had to get the latest daily build...
[10:22:37] <lisaDusseault> that was fast.
[10:23:14] <stpeter> process question: will this be input to an informational I-D?
[10:24:22] <stpeter> suggestion that presence scenarios would be useful (like call flows)
[10:25:50] <stpeter> new topic/speaker: Mikko Lonnfors, draft-ietf-simple-partial-notify
[10:26:24] <lisaDusseault> Off topic: anything that can make me giggle this morning is worth sharing: http://www.bushparty.com/htms/hockeylogos.htm
[10:26:33] <lisaDusseault> I like the 2nd page 'injun' ones :)
[10:26:35] <stpeter> ready for working group last call?
[10:26:46] --- hildjj has joined
[10:27:45] <stpeter> the Vancouver Voodoo?
[10:28:03] <stpeter> draft-ietf-simple-prescaps-ext
[10:28:28] <stpeter> changes since -01 -- harmonization with sip-callee-caps, etc.
[10:28:41] <stpeter> open issue: contact URI
[10:28:57] <lisaDusseault> Even worse: Macon Whoopee.
[10:29:01] <stpeter> proposal to not restrict SIP URIs that can be placed as contact URI
[10:29:14] <stpeter> are they allowed to play hockey in Macon?
[10:29:27] <lisaDusseault> Just say it aloud...
[10:29:34] <stpeter> yeah yeah yeah, i knopw
[10:31:09] --- burgere has joined
[10:31:19] <stpeter> what should the contact URI be if <prescaps> elements are present?
[10:33:03] <stpeter> open issue: what capabilities?
[10:33:29] <stpeter> recommended that UA should declare al features associated with particular contact address
[10:33:50] <stpeter> tuples can represent many things: service, device, presentity
[10:34:08] --- lha has joined
[10:34:09] <stpeter> authorization policies may limit the information that is visible for watchers
[10:34:29] <stpeter> proposal: no need to express full feature sets but only those that are relevant for particular service/tuple
[10:34:33] --- lha has left
[10:34:53] --- hildjj has left: [Kicked] You have been kicked.
[10:35:23] --- hildjj has joined
[10:35:30] <stpeter> sorry, just testing the kick functionality on hildjj ;)
[10:35:49] <hildjj> grumble. freaking moderator abuse of power... :)
[10:36:00] <stpeter> heehee
[10:36:00] <warlord> Heh
[10:36:13] <stpeter> it's good to be the room owner
[10:38:00] <warlord> membership has its priviledges
[10:38:59] <stpeter> privileges has no "d" ;)
[10:39:27] <stpeter> open issue: contacting a particular UA
[10:39:42] --- alexeymelnikov has joined
[10:40:09] <stpeter> desire to enable routing based on prescaps elements
[10:40:13] <warlord> So you can tell I went to MIT -- I can't spell.. :)
[10:40:18] <stpeter> heh
[10:40:25] <lisaDusseault> Warlord is talking about PriviLedges, the brand name for the new way the high and mighty stay high.
[10:42:03] <stpeter> open issue for syntax
[10:42:21] <stpeter> <methods>INVITE, !MESSAGE, OPTIONS</message>
[10:43:05] <stpeter> <methods> <method>INVITE</method> <method negated='true'>MESSAGE</method> </methods>
[10:43:13] <stpeter> preference for #2
[10:43:32] <stpeter> open issue: extension tags
[10:43:51] <stpeter> only way to add new tags right now is to define new XML namespaces
[10:46:08] --- resnick has left: Disconnected
[10:46:48] --- resnick has joined
[10:47:09] <stpeter> too heavy?
[10:47:25] <stpeter> proposal: define elements for different types of extension feature tags
[10:47:38] <stpeter> next step: do we adopt this as a WG item?
[10:49:21] <stpeter> sorry, i mistyped the name of the draft under discussion (i called it draft-ietf-simple-*)
[10:49:52] <stpeter> Aki Niemi comes to the front to present
[10:50:36] --- acmahen has left: Disconnected
[10:50:46] <stpeter> 3GPP Requirements for SIMPLE
[10:51:51] <stpeter> draft-kiss-simple-presence-wireless-reqs-03, draft-niemi-something-or-other-*
[10:52:00] <stpeter> 39 requirements in total
[10:52:11] <stpeter> 30 fulfilled or in progress by WGs
[10:52:19] <stpeter> 9i in progress or individual IDs
[10:52:43] <stpeter> IM reqs -- 29 requirements, 9 missing or out of scope, 20 WG, 7 individual I-Ds
[10:52:59] <stpeter> filtering, confference control, hard state publication -- indivbidual
[10:53:48] <stpeter> completely missing -- privbate message in multiparty, message treatment (configuring treatment of incoming IMs), semi-permanent invitations (non interactive invitation, ability to cancel, accept, reject)
[10:55:05] <stpeter> 3GPP milestones -- March '04 MUST have publish, RPID, CPID, XCAP
[10:55:29] <stpeter> SHOULD: precaps, hard-state publication, filtering, throttling, partial notification, content indirection, winfo history, pidf-lo
[10:55:52] <warlord> "privbate"?
[10:56:09] <warlord> (I dont think private has a 'b')
[10:56:13] <stpeter> warlord: i'm not a good typist ;)
[10:56:41] <stpeter> trying to capture things before the slides are taken off the screen
[10:56:57] <warlord> fair enough
[10:57:59] <stpeter> Lisa Dusseault presents on patch/diff/partial updates
[10:58:54] <stpeter> ability to apply a patch to an XCAP document
[10:59:24] <stpeter> need to use strong e tags in HTTP
[10:59:49] <stpeter> Content-type: text/xcap+xml
[11:00:03] --- dizzyd has joined
[11:00:43] <stpeter> uses xpath to determine location of patch in XML file
[11:02:05] <stpeter> </lisa>
[11:02:30] --- resnick has left: Disconnected
[11:02:30] --- lisaDusseault has left
[11:02:40] --- lisaDusseault has joined
[11:02:48] <hildjj> test...
[11:02:58] <lisaDusseault> St peter did your close tag for me dump me????
[11:03:04] <stpeter> lisaDusseault: can you post the URL here?
[11:03:07] <lisaDusseault> (I know -- coincidence :)
[11:03:16] <stpeter> lisaDusseault: should not have
[11:03:33] <lisaDusseault> http://www.sharemation.com/~milele/public/dav/draft-dusseault-http-patch-00.txt
[11:03:34] <stpeter> Hisham Khartabil -- Event Filtering
[11:04:12] <stpeter> draft-ietf-simple-pres-filter-reqs-02
[11:04:20] <stpeter> volunteers did not review
[11:04:24] <stpeter> call for new volunteers
[11:04:50] --- resnick has joined
[11:04:58] <stpeter> draft-khatrabil-simple-filter
[11:05:14] <stpeter> xpath usage removed
[11:05:26] <stpeter> defined own BNF that is a subset of XPath
[11:06:01] <stpeter> added filtering by namespace
[11:06:08] --- dizzyd has left: Disconnected
[11:06:37] <stpeter> applying filters by domain needs to be added to align with xcap-auth?
[11:06:44] --- hardie has joined
[11:06:45] <stpeter> need to de-scope
[11:06:48] --- acmahen has joined
[11:06:58] <stpeter> what's in or out? discuss on list
[11:07:17] <stpeter> conditional inclusions, level, inclusion by namespace, exclusion, type, triggering
[11:08:10] <stpeter> need for use cases
[11:08:17] <stpeter> separate use case document?
[11:08:36] --- stpeter has left: Disconnected
[11:08:46] --- anewton has left: Lost connection
[11:09:28] --- resnick has left: Disconnected
[11:10:00] --- stpeter has joined
[11:10:23] <stpeter> hum to adopt as a WG tem
[11:10:28] <stpeter> s/tem/item/
[11:10:29] --- resnick has joined
[11:10:38] <stpeter> issue: full vs. partial state
[11:10:48] <stpeter> most event packages have full and partial notification built in
[11:10:59] <stpeter> is this element always set to partial when a filter is applied?
[11:11:07] <stpeter> or does it dpeend on the results of the filgter?
[11:11:10] <stpeter> yow
[11:11:13] <stpeter> bad typing
[11:11:21] --- burgere has left
[11:13:03] --- resnick has left: Disconnected
[11:13:06] --- resnick has joined
[11:13:17] <stpeter> issue: subscribe refresh
[11:13:44] <stpeter> scribes misses fast-moving text
[11:15:24] <stpeter> adopt as a WG item?
[11:15:35] <stpeter> only ~5 people have read this draft
[11:16:53] <stpeter> hum to adopt
[11:17:04] <stpeter> room consensus to adopt
[11:17:10] --- resnick has left: Disconnected
[11:17:10] --- hardie has left
[11:17:25] <stpeter> break for lunch
[11:17:29] <acmahen> stpeter..thanks for the good scribe
[11:17:30] <stpeter> bbl
[11:17:35] <stpeter> acmahen: my pleasure
[11:17:43] --- acmahen has left
[11:17:49] <stpeter> hand over the blue sheets!!!
[11:18:08] --- stpeter has left
[11:23:08] --- warlord has left
[11:24:25] --- mrose has left
[11:25:37] --- lisaDusseault has left: Disconnected
[11:32:13] --- reschke has left
[11:38:11] --- hildjj has left: Disconnected
[11:42:34] --- avri has left: Disconnected
[12:55:03] --- warlord has joined
[13:01:54] --- leg has joined
[13:04:54] --- hardie has joined
[13:05:10] <hardie> Jonathon goes through changes in xcap
[13:05:19] --- mrose has joined
[13:05:31] --- resnick has joined
[13:05:33] <hardie> post gone; added auid grammar
[13:05:40] --- resnick has left: Lost connection
[13:05:51] <hardie> vendor auids now java-style
[13:06:07] <hardie> etags added
[13:06:52] --- resnick has joined
[13:07:25] --- stpeter has joined
[13:07:50] <stpeter> hardie: would you like me to scribe again?
[13:08:26] <stpeter> what mime thpe is indicated in put request and get response?
[13:09:00] <stpeter> proposal: application/xml when XML doc -- better than text/xml
[13:09:11] <stpeter> text/plain for attributes
[13:11:22] --- hardie has left
[13:11:40] <stpeter> hmm
[13:11:50] --- stpeter has left
[13:11:54] --- stpeter has joined
[13:13:42] --- resnick has left: Disconnected
[13:13:45] --- lisaDusseault has joined
[13:13:49] <stpeter> odd
[13:14:47] <stpeter> brb
[13:15:14] --- mrose has left
[13:16:49] --- mrose has joined
[13:17:55] <lisaDusseault> That was the right decision w.r.t. ETags :)
[13:18:44] <stpeter> heh
[13:19:50] --- resnick has joined
[13:20:08] --- resnick has left: Lost connection
[13:20:09] --- resnick has joined
[13:21:25] --- resnick has left: Disconnected
[13:21:27] --- hildjj has joined
[13:24:02] --- resnick has joined
[13:24:24] <lisaDusseault> There are deep assumptions in WebDAV -- which are related to the way HTTP is implemented -- about what you can do to a resource.
[13:25:05] <lisaDusseault> Since a resource is anything you can name with a URI before the '?', if you have a URI of the form Jonathan showed, then there are deep assumptions that piece has properties and locks.
[13:25:30] <lisaDusseault> It would be a huge data model change to WebDAV to say that there are things which have URIs (without '?') that you *can't* lock or have properties on.
[13:25:37] <leg> so you would prefer using some sort of range retrieval?
[13:25:41] <lisaDusseault> You bet.
[13:32:21] --- resnick has left: Disconnected
[13:32:27] --- resnick has joined
[13:33:18] <leg> it seems that they want some sort of standardized uri to reference subparts of the document.
[13:35:20] <leg> having these sub-document URIs makes it smell less like http.
[13:35:28] --- JoelMHalpern has joined
[13:38:18] --- rjs3 has joined
[13:42:49] <lisaDusseault> So the major goal is actually to be able to write down a single URL -- a single link -- which allows a standard HTTP stack to download only part of a XML conf fing.
[13:42:56] <lisaDusseault> s/fing/file.
[13:43:11] <leg> yes, that appears to be the case.
[13:43:15] <lisaDusseault> I think I know how to do that & it goes back to Jonathan's '?' portion in the URL.
[13:43:29] <lisaDusseault> As long as you use that '?' for GETs only, not for PUTs, I'm cool :)
[13:43:58] <lisaDusseault> So we could define something that is again a general-purpose building block for HTTP, which is a query schema for requesting only part of a XML document.
[13:44:00] <JoelMHalpern> Personally, it looks like with Jonathan's proposed syntax it is simply up to the "file system" under the receiving server to provide the right magic.
[13:44:26] <leg> though it would be nice if a cache that has the entire buddy list can respond to a partial GET without going to the server. but then again, since this is likely going over https maybe it doesn't matter.
[13:44:35] <lisaDusseault> That query schema for partial XML retrieval would define a URL parameter that is only valid on GET requests.
[13:44:40] <lisaDusseault> True
[13:45:09] --- hardie has joined
[13:45:28] <leg> i suppose something slimy would be a client can rewrite this special URI with ? into a GET with range...
[13:46:11] <lisaDusseault> Why would you have to ? A server advertising support for the 'XML document part retrieval' feature would parse the parameter & return a GET response.
[13:47:07] <leg> as would an intermediary i guess.
[13:47:19] <lisaDusseault> Now that's a cool idea :)
[13:47:53] <lisaDusseault> The intermediary that wanted to cache the entire document could strip the query off and then get the whole thing, then self-apply the query parameter rule.
[13:48:14] <leg> yes.
[13:48:32] <leg> but intermediaries shouldn't have to be xcap-aware.
[13:48:38] <lisaDusseault> they wouldn't have to be.
[13:48:52] <leg> if you make a reserved GET parameter.
[13:48:53] <JoelMHalpern> I have seen at least one case where the boundary between the whoel document and the part might not be obvious to the user and might change over time.
[13:48:58] <lisaDusseault> Intermediaries are already aware that a document GET result may vary unpredictability with query parameters on GET Request-URIs.
[13:49:19] <lisaDusseault> Joel: that's really interesting but hard... I think this actually might be easier than we've been making it.
[13:51:02] <JoelMHalpern> From a non-webdav perspective, this has looked pretty simple and clean to me. I may be missing some of the problems.
[13:51:34] <lisaDusseault> Yeah, the problems certainly become quite obvious when you consider how LOCK and UNLOCK and PROPFIND and PROPPATCH would have to be made to work,
[13:51:59] <lisaDusseault> against a URL like /lisa/buddies.xml/people/friends/jonathan/imurl
[13:52:11] <JoelMHalpern> I can imagine that properties would significantly complicate things.
[13:52:38] <lisaDusseault> WebDAV probably makes it worse. Without WebDAV, I would still call it a problem or a challenge, however it's more surmountable.
[13:52:46] <JoelMHalpern> LOCK / UNLOCK I suspect it is more that the structure may mandate more locks than one wants.
[13:53:02] <lisaDusseault> Ted's right about servers doing all sorts of interesting things with 'live' resources and magic urls.
[13:53:27] <lisaDusseault> But usually the thing identified in the URL up to the '?' maps to a file somewhere. It's after the '?' that the magic comes, usually.
[13:54:18] <leg> do intermediaries break URLs at the ? or do they treat the whole thing as an atomic unit? (i don't even know where in the specs to look for this sort of thing.)
[13:54:45] <JoelMHalpern> I just tend to think of this as a web server and its file system cooperating to deliver a simple view of a complex structure.
[13:55:06] <lisaDusseault> It's a difficult question. The problem is that URL parameters were designed to work with GET and POST and they work very well with those methods on intermediaries.
[13:55:33] <lisaDusseault> I could look around some, but I don't think URL parameters were defined for other methods, like HTTP DELETE.
[13:55:38] <lisaDusseault> Or PUT.
[13:55:57] <JoelMHalpern> And we really need this on PUT
[13:56:07] <lisaDusseault> An intermediary could be implemented that believed that a PUT to /lisa/buddies.xml?xmlloc=people/jonathan was the same thing as a PUT to /lisa/buddies.xml.
[13:56:33] <lisaDusseault> And even if that might be unwise, or dangerous, or even uncompliant, we woudln't know it until we started running into wierd network bugs.
[13:56:53] <leg> but they don't today, which means that the intermediary doesn't know to invalidate the cache of /lisa/buddies.xml when a put happens to a different uri.
[13:57:08] <lisaDusseault> Yes, that's exactly right.
[13:57:53] --- resnick has left: Replaced by new connection
[13:57:53] --- resnick has joined
[13:58:12] <JoelMHalpern> With what has been proposed I would guess that anything provided in a GET response above the leaf would have to be set not to cache.
[13:58:37] <JoelMHalpern> While unfortunate, is that really fatal? This is not widely shared information after all.
[13:58:49] <lisaDusseault> The URL ending in *.xml might also have to be set not to cache.
[13:59:18] <lisaDusseault> It isn't fatal, but it obviously makes caching difficult to useless to XCAP.
[13:59:47] <JoelMHalpern> Yes, and we shoudl document that limitation whatever way we go.
[14:00:12] <lisaDusseault> Depends on how much they'd need HTTP caching to work, just like the WebDAV-incompatibilities might be OK depending on whether they ever want WebDAV LOCK, UNLOCK, PROPFIND, PROPPATCH, or ACL to work.
[14:00:41] <lisaDusseault> Personally, I would think they would find the WebDAV ACL functionality to be a piece that they desperately want and never ever ever want to go through the hell of defining themselves.
[14:00:54] <leg> yes, ACL seems to be important.
[14:01:25] --- Eliot Lear has joined
[14:02:30] <leg> i wonder if controlling how long clients cache the information is important, or if it's assumed the user will just force a refresh when they know it might've changed.
[14:02:53] <JoelMHalpern> The server can also indicate in the response that the information is not to be cached.
[14:03:28] <leg> clients have to cache buddy lists.
[14:04:11] <JoelMHalpern> But is the client app a web browser or a custom app that understands the semantics?
[14:04:25] <leg> one assumes a custom app.
[14:04:43] <JoelMHalpern> If the client app has to use the HTTP cache timeout as its timeout, that would indeed cause complications
[14:05:07] <JoelMHalpern> But if it uses a different model, then we can use the proper field to control intermediate caching
[14:05:52] <JoelMHalpern> Alternatively, we could view that the time for a client to use the list is also a suitable time limit for allowing caches to return that information.
[14:06:53] --- Eliot Lear has left
[14:07:35] --- mrose has left
[14:07:40] --- mrose has joined
[14:07:49] --- hildjj has left: Disconnected
[14:08:04] <lisaDusseault> leg: It can be a custom app most of the time. But if the data is in a fairly standard format, a normal WebDAV client (or even HTTP) could synchronize this data, use it offline, or back it up, or migrate it to a different place.
[14:08:52] <lisaDusseault> Another thought about Chris Newman's point a while back. Application data *is* frequently stored on a HTTP server, and browsers download it.
[14:09:08] <lisaDusseault> E.g. my Money data could be a big ol' HTTP resource (I know people who do this!)
[14:09:42] <lisaDusseault> It's handled by browsers in a standard way: when the MIME type is one the browser doesn't understand it hands off to an application that *has* registered for that MIME type, if it exists.
[14:11:23] <JoelMHalpern> And can that app cache that data according to its own rules?
[14:11:48] <lisaDusseault> Joel: I would expect that app would use ETags and ask the server periodically if the ETag had changed.
[14:12:15] <lisaDusseault> We've had discussions about synchronization enhancements for HTTP, but those would obviously start from ETags.
[14:12:22] --- mrose has left
[14:12:45] <JoelMHalpern> ETag does sound like the right answer
[14:12:48] <lisaDusseault> From that basis, synchronization might involve change notifications (over a more appropriate protocol than HTTP) or Collection state tags ("CTags") or both.
[14:13:57] <lisaDusseault> Actually, I wrote a high-level proposal for this 4 years ago.
[14:13:58] <lisaDusseault> http://www.sharemation.com/~milele/public/rsync-specification.htm
[14:14:43] <lisaDusseault> That proposal was for a Linux tools-and-services company that wanted Linux clients to be able to synchronize and backup massive amounts of data.
[14:20:44] --- michael has joined
[14:21:41] --- mrose has joined
[14:22:14] --- resnick has left: Disconnected
[14:23:15] --- hardie has left: Disconnected
[14:30:46] --- mrose has left
[14:36:08] --- lisaDusseault has left
[14:38:27] --- lisaDusseault has joined
[14:39:32] --- lisaDusseault has left
[14:42:20] --- lisaDusseault has joined
[14:46:08] <lisaDusseault> Another minor light turned on for me... still thinking about XCAP
[14:46:22] --- JoelMHalpern has left
[14:46:26] <lisaDusseault> HTTP/WebDAV people have been thinking about doing "structured documents" for a long time
[14:47:01] <lisaDusseault> The PATCH method for XML documents, plus a query parameter that knows how to get a piece of an XML document, might make that XML document a sufficiently powerful structured document (with the right schema)
[14:47:20] <leg> sufficiently powerful to do ... ?
[14:47:21] --- rjs3 has left: Disconnected
[14:47:30] <lisaDusseault> I should define my terms - a "structured document" is a document that can be rendered in a single view, but has several components.
[14:47:43] <lisaDusseault> A web page with images could be authored as a strucutred document.
[14:48:04] <lisaDusseault> It might behave like a collection under some conditions - e.g. list children - and as a resource under others (e.g. ACL)
[14:48:21] <lisaDusseault> It's currently not a well-defined concept, just random thoughts.
[14:50:04] <leg> foo
[14:50:18] --- stpeter has left
[14:53:26] --- warlord has left
[15:01:12] --- lisaDusseault has left: Disconnected
[15:07:14] --- michael has left
[15:08:26] --- leg has left: Replaced by new connection
[15:09:57] --- alexeymelnikov has left