[19:33:02] --- randy has joined
[19:40:08] --- leslie has joined
[19:41:00] --- hardie has joined
[19:44:00] --- anewton has joined
[19:47:22] <hardie> quiet room
[19:47:39] <anewton> yeah
[19:49:43] --- lisaDusseault has joined
[19:51:13] <randy> Would someone please start scribing?
[19:52:28] <lisaDusseault> I will for now.
[19:52:41] <anewton> thank you.
[19:52:48] <anewton> I owe you a beer
[19:52:51] <randy> Thank you!
[19:53:01] <lisaDusseault> Jon Peterson's saying that some stuff should be extracted from the big spec.
[19:53:07] <lisaDusseault> (Didn't catch what stuff)
[19:53:37] <lisaDusseault> Hannes says that the spec does provide guidance on how to use GML.
[19:54:34] <lisaDusseault> Hannes: In the GML profile, you can restrict the complete vocabulary.
[19:54:56] <lisaDusseault> Jon: Yeah, and some of the authors of GML prefer this approach (the profile) to doing full GML. Although there's some disagreement.
[19:56:15] <lisaDusseault> Hannes asks for volunteers who know GML to help.
[19:56:25] <lisaDusseault> Chair: Are we more concerned with performance or usage issues?
[19:56:39] <lisaDusseault> Hannes: For me, usage issues.
[19:57:16] <lisaDusseault> Jon: It could be, performance, if you use on extremely low memory devices. But what I'm hearing here is, usage. I agree you need to get further than "use GML feature set blah" and actually get feature set experiments. Play with it.
[19:57:54] <lisaDusseault> Jon's presenting draft on PIDF
[19:58:35] <lisaDusseault> Jon is threatining to read from the poetry of John Donne.
[19:59:35] --- hardie has left
[19:59:37] <lisaDusseault> There will be a new official WG draft version of Jon's PIDF draft for geopriv.
[19:59:54] <lisaDusseault> There is very little that still needs to be done but "civil location formats" do need to be done.
[20:02:10] <lisaDusseault> Jonathan Rosenberg wants to make sure there's good alignment betweein SIMPLE and geopriv on this topic.
[20:02:50] <lisaDusseault> JR thinks the geopriv info is valuable for SIMPLE.
[20:03:12] <lisaDusseault> Jon P offers two ways to do this. No, four ways,.
[20:03:37] <lisaDusseault> He likes having the geopriv stanza as a separate element in PIDF so that it's clear what geopriv policy applies to.
[20:03:51] --- jm has joined
[20:04:05] <lisaDusseault> JR: When we use this schema component, we'll need to know what the scope of the retention rules are, to the geopriv data or to the rest of the PIDF data.
[20:04:29] <lisaDusseault> JP:"Groovy".
[20:05:51] <lisaDusseault> JP: that's it.
[20:06:26] <lisaDusseault> Henning: A question of where this belongs; somebody asked me whether the object should indicate the source of the object.
[20:07:09] <lisaDusseault> HS: So you can know whether the location info comes from GPS or something else.
[20:07:19] <lisaDusseault> JP I don't really see the use of that.
[20:07:43] <lisaDusseault> Henning: If you have mutliple locations, this allows the observer to make a more informed decision the likely correct one.\
[20:08:13] <lisaDusseault> JP: What we've said so far is the important property is after composition.
[20:08:32] <lisaDusseault> Chair dude: I think the source of the data is information potentially useful but not absolutely needed in short term.
[20:08:49] <lisaDusseault> Chair warns of overly complex designs and real deadlines missable.
[20:09:24] <lisaDusseault> Chair is Randy Gellens, BTW, I can't see him too clearly from back here in the cheap seats.
[20:09:51] <randy> There's plenty of pricy seats open at the front
[20:10:04] <lisaDusseault> Andrew Newton: You're talking about embedding location in other docs, right?
[20:10:11] <lisaDusseault> JP I'm talking about PIDF docs.
[20:10:19] <lisaDusseault> AN: The whole thing wrapped by MIME.
[20:10:29] <lisaDusseault> JP There's already a MIME type for PIDF, yes
[20:10:54] <lisaDusseault> I should have trademarked the use of "stanza" in protocol architecture :)
[20:11:02] --- hardie has joined
[20:11:31] <lisaDusseault> Randy: I don't know how much you paid for your seat, but I'm all set up here, and I can hear which should be enough :)
[20:12:12] <lisaDusseault> JR points out that the existence of MIME type isn't enough when the doc Xml schema is extensible.
[20:12:31] <lisaDusseault> JP: The way PIDF is designed, to have minimal interoperability and extensibility above it.
[20:12:53] <lisaDusseault> Anything that supports PIDF and looks at it, will always understand it, and possilby ignore the geopriv bit.
[20:13:39] <lisaDusseault> Ted Hardie: If you are looking for geopriv data, and you're opening a PIDF document, ou should have no problem.
[20:13:53] <lisaDusseault> It will at least undersand the portions of the stanza that tell it what the format is.
[20:14:06] <lisaDusseault> Henning: there are two types of extensions, mandatory and optional
[20:14:21] <lisaDusseault> JP: It's a little different; you're not allowed to have top-level subelements.
[20:15:06] <lisaDusseault> HS: If I send you a PIDF with no geopriv, and you expect geopriv, the recipient has no clue ...
[20:15:29] <lisaDusseault> HS: We should consider a way for the sender to know the recipient didn't understand it.
[20:16:08] <lisaDusseault> Ted: So what's the behavior of something you don't understand, and is that compatible witht the privacy requirements of geopriv.
[20:16:20] <lisaDusseault> JP: If you don't understand geopriv, you have to discard it. So there is a failsafe.
[20:17:24] <lisaDusseault> JR: It's not the case that all the extensions must be understood. Anything applies to the elemnt and all of its children.
[20:18:15] <lisaDusseault> Ted: Everybody go read the spec.
[20:18:32] <lisaDusseault> Ted: I want to go back to civil location stuff. Do we expect to inherit this or ...
[20:18:40] <lisaDusseault> JP: Conclusion at Washington: we need something now.
[20:19:26] <lisaDusseault> Ted: Civil location could be a giant rathole. WG should do what it can quickly and leave open for further extension.
[20:19:31] <lisaDusseault> JP: Preaching to the choir.
[20:20:01] <lisaDusseault> Ted: Then you should change "what needs to be changed in this draft" to be clear we're not going into a long discussion
[20:20:55] <lisaDusseault> Henning: there are some sleeping objectives here (???)
[20:21:24] <lisaDusseault> Andrew: WG hum for explicit statements including civil location in geopriv policy
[20:21:42] <lisaDusseault> Hum was in favour.
[20:22:09] --- leslie has left: Disconnected
[20:22:32] <lisaDusseault> Andrew: Do you foresee a need for standardizing subject name...
[20:22:38] <lisaDusseault> JP There is supposed to be a pres uri.
[20:22:45] <lisaDusseault> JP I will put that in.
[20:23:03] <lisaDusseault> Next up : Henning, permissions, roles.
[20:23:52] --- jm has left
[20:24:14] <lisaDusseault> Henning is discussing history of design team and drafts.
[20:24:59] <lisaDusseault> Henning: The important part is not the schema details but the design assumptions.
[20:25:19] <lisaDusseault> HS: It's easy to add features that done one way break things badly, in antoher way cannot do that.
[20:25:52] --- lisaDusseault has left: Disconnected
[20:28:06] --- lisaDusseault has joined
[20:28:21] <lisaDusseault> HS: Describes the three places for policy enforcement.
[20:28:50] <lisaDusseault> JR: In SIMPLE you have filters. What you don't have, is rejecting the subscription on the basis of policy, which is har dto do.
[20:29:24] <lisaDusseault> JR: This was in XCAP-00 but it's gone.
[20:29:51] <lisaDusseault> Hannes asked about the name info being not there
[20:30:06] <lisaDusseault> JR: Yes, that is there, you can ask for only street address. Subscription would be accepted then you'd simply not get them.
[20:31:10] <lisaDusseault> JR: No way to differentiate, in that modle, you're not allowed to see that data, as opposed to it's not avail.l
[20:32:47] <lisaDusseault> Guy at mike: do you have a way to limit granularity?
[20:32:49] --- michael has joined
[20:32:54] <lisaDusseault> JR: Filtering work is at early stages.
[20:33:05] <lisaDusseault> JR. It's a syntactic reduction you're asking for, not semantic.
[20:35:02] <lisaDusseault> Nice slides being shown, I hope HS posts them.
[20:35:55] <lisaDusseault> HS: We are protocol neutral; the geopriv info could be conveyed via email, SOAP, WebDAV, FTP, there's no consensus to restrict to one, or we have to decide to day as it has conseuqences.
[20:36:58] <lisaDusseault> HS: We don't do external references in SIMPLE, but it's necessary if you assume this propagates along ?
[20:37:17] <lisaDusseault> HS: The rules here might modify for specific recipients, not just the geo info but also privacy flags.
[20:38:12] <lisaDusseault> HS: Having multiple sets of rules - company vs. personal eg - led to a design assumption that should be explicit:
[20:38:24] <lisaDusseault> HS: that rules should be atomically addable
[20:38:35] <lisaDusseault> HS: a union of permissions applied by matching rules
[20:39:03] <lisaDusseault> HS: So in this model rules can't revoke.
[20:41:30] --- lisaDusseault has left: Replaced by new connection
[20:43:09] --- leslie has joined
[20:43:26] --- randy has left: Disconnected
[20:44:54] --- lisaDusseault has joined
[20:45:08] <lisaDusseault> [argh. I keep getting booted off wireless.]
[20:45:21] <lisaDusseault> HS is listing non-goals
[20:45:38] <lisaDusseault> HS: points out that calsched is at the bottom of the slippery slope and we don't want to follow
[20:45:39] <hardie> it's the ad hoc network growing in strength. Try nailing down your WLAN ID
[20:46:28] <lisaDusseault> HS is done now topic is logging.
[20:47:58] <lisaDusseault> James: Can't we have logging, when we have a location service, so that you don't hit my target directly... so that it logs whenever somebody else gets my location?
[20:49:33] <lisaDusseault> HS: Logging is easily done by having a logger subscribe to this info.
[20:49:34] --- randy has joined
[20:49:52] <lisaDusseault> HS: Let's not try to distinguish what's logging and notification in the first version.
[20:50:05] <lisaDusseault> James: I would think location notificaiton wouldnot be in the first phase.
[20:52:52] <lisaDusseault> Discussion of encryption attribute
[20:53:05] <lisaDusseault> James Kempf: You never wnat to open up to a bidding-down attack.
[20:53:31] <lisaDusseault> Sorry people, I need to go do work elsewhere now :)
[20:53:38] <lisaDusseault> Hope you find another xmpp logger
[20:53:47] --- lisaDusseault has left
[20:57:59] <randy> How to identify authentication of target user
[20:59:13] <michael> discussion about to much flexibility causing the user to have to attempt a trial and error approach...
[20:59:52] * anewton owes Michael a beer as well
[21:00:30] <michael> seems there is consensus for only having one level since there was no way to recover from either party not being able to handle one of hte other states.
[21:00:50] <michael> notifications: Require notice to hte rule maker if lcoation is provided.
[21:01:07] <michael> Henning: for the first versoin all of this can be handle by current mechanisms....
[21:01:49] * michael is not up to snuff on geopriv so his scribing will probably suck.
[21:01:57] --- lisaDusseault has joined
[21:02:12] --- hildjj has joined
[21:02:41] --- hildjj has left: Disconnected
[21:03:08] --- resnick has joined
[21:03:33] --- resnick has left
[21:03:49] <michael> suggestion that we keep notificaoitns on the radar screen.... henning: create a separate event notification mechanism....
[21:03:49] <randy> John Morris notes that logging introduces its own privacy concerns since it creates records that are searchable etc
[21:04:45] <michael> the statement that if its reserved for other systems and their notification mechanism it means geopriv doesn't need to deal with it.
[21:06:02] <michael> an overview of what simple did in this case....
[21:06:10] <michael> they call it reactive authorization....
[21:08:35] <michael> the suggestion is that geopriv simply give guidelines for other protocols and their notification frameworks for when those notifications contain location information.
[21:09:39] <michael> Andy is calling for a hum
[21:10:00] <michael> not sure what the options are hyet
[21:10:43] <michael> hum is for if you think we should have asection on consideration for a using protocol where one of those considerations is notifications.... hum passes
[21:10:57] <michael> did I get that right?
[21:11:09] <randy> yes, thank you
[21:11:13] --- lisaDusseault has left: Disconnected
[21:11:14] <michael> slide on naming (fun!)
[21:11:26] <randy> (actually, hum indicated concensus)
[21:11:29] <michael> Currently defines protocol specific identifies rather than generic ones
[21:11:46] <michael> some protocols (sip, xmpp) naturally have user identifies in URIs (sip:alice@example.com)
[21:12:03] <michael> May not be the same as ID used to authenticate (e.g. HTTP/SIP digest identify)
[21:12:25] <michael> from the mic: you'll never be able to get away from the identifiers of each system....
[21:13:02] <michael> you almost want to have a using protocol template. each using protocol would make statmetns aobut idetnfiiers used.
[21:14:43] <michael> henning: he wants something better than what's in the document now... which is just an HTTP basic auth technique.
[21:15:38] <michael> hennign: you have the problem where you'll have hte same rule set for multiple using protocols. so how do you use identifiers in those rule sets that work across those using protocols.
[21:16:20] <michael> the suggestion is that each ruleset would have allow using protocol specific subelements (i.e. using namespaces)
[21:16:48] <michael> andy: in order for this to be used immediately someone has to define those using protocols templates immediately
[21:18:16] <michael> discussion on how to structure the XML so that something can be down now that is using protocol independent....
[21:21:06] <michael> ted hardie: it sounds like the group is going back and adding new requirements.
[21:21:35] <michael> I'm not clear on what his suggestion is so I'll let him restate it when he sits back down
[21:22:19] <randy> Ted suggests we develop a using protocol profile ourselves
[21:23:12] <randy> Ted is concerned that we otherwise heading towards re-opening requirements for using protcol
[21:25:53] <michael> can someone pick this up for a few minutes..... I have a phone call
[21:27:10] --- hildjj has joined
[21:28:51] --- jis has joined
[21:28:52] --- hildjj has left: Disconnected
[21:29:56] <randy> Exceptions: e.g., all users of company x except a
[21:30:07] <randy> Ted: exceptions are very useful but very hard to get right
[21:30:50] <randy> Ted: someone (client or server) needs to enumerate members of group and exclude the member
[21:31:05] <randy> Ted: please work on this later, not sooner
[21:33:09] <randy> HS: can do this as either external references to group store or as self-contained
[21:33:37] <randy> JR: we need domains, we'd need to tie this to using protocol
[21:33:46] <randy> JR: can cover this in using protocol
[21:34:52] <randy> JP: q: rule such as 'no one at cisco can get my location in evening except these six employees of my group who can get my location 7/24'?
[21:35:04] <randy> Ted: that's OK, we can do that now.
[21:35:35] <randy> Ted: what we want to avoid is a rule such as "my bowling league can get my location except for these members'
[21:36:03] <randy> Ted: a broken 'except' that only does string match won't be useful enough to be worth doing
[21:37:48] <randy> Andy: hum if you think we can go forward without an except mechanism for the first release
[21:37:48] <randy> (very few hums)
[21:39:15] <randy> Allison: let's try again: initial phase has only additive rules, not string match, as proposed by Henning, in order to get document done this quarter
[21:39:31] <randy> (good number of hums)
[21:39:51] <randy> Allison: hum if you want to add Henning's string match proposal to the first release
[21:39:59] <randy> (about the same number of hums)
[21:40:23] <randy> Floor: don't divergegeopriv and xcap right away
[21:40:34] <randy> HS: doesn't want to diverge
[21:41:19] <randy> JR: proposal to move forward without divergence: do this in using protocol
[21:41:36] <randy> Allison: capability isn't as interesting as concerns about xcap
[21:42:12] <randy> Ted: if we do that, how do we avoid having to do this in each using protocol
[21:45:36] <randy> Ted: ask chairs to ask for hum: if SIPPING adds match against domain but without except
[21:45:45] <randy> Andy: restate: if XCAP has matching rule for domain but doesn't have exception is that OK to use XCAP?
[21:45:59] <randy> (Moderate number of hums)
[21:46:52] <randy> We have concensus to do that
[21:48:07] <randy> Slides: authorization policy of xcap
[21:48:43] <randy> slides: defaults: null values in draft now
[21:48:59] <randy> Slides: split into two categories: permission and transformations
[21:49:24] <randy> slides: examples
[21:49:59] <randy> slides: everyone is allowed access to country location info and to distribute
[21:50:30] <randy> slides: one recipient is allowed access to country location info but not to distribute
[21:51:14] <randy> slides: because of additive rules. We need to look at how defaults are handled to that we get this right. This is an open issue.
[21:51:24] <randy> Any other business?
[21:51:42] <randy> John Morris has 1 or 2 slides
[21:51:57] <randy> Floor: bring up how to deal with emergency calls
[21:53:10] <randy> slides: emergency calls have problems:
[21:53:22] <randy> slides: route based on location; psaps serve areas
[21:54:36] <randy> slides: location must appear on 1st message (e.g., SIP INVITE) since it is used for routing
[21:54:36] <randy> slides: intermediaries need to know location; not end to end problem
[21:54:47] <randy> slides: post-dial delay very important; difference betwen 2-4 seconds is huge; above 5 seconds people adandon calls
[21:55:07] <randy> slides: with crypto and intermediaries it can be a problem
[21:56:15] <randy> slides: rules about accuracy, retention, disclosure get applied at other end based on laws
[21:56:58] <randy> John Morris: practical effect: rule maker doesn't matter
[21:57:09] <randy> (Brian Rosen's slides)
[21:57:20] <randy> slides: s/mime is reasonable requirement
[21:58:06] <randy> slides: we want to say that using protocol supports TLS (or IPSEC)
[21:58:25] <randy> slides: for emergency calls
[21:58:46] <randy> slides: create default rule for emergency calls
[21:58:59] <randy> slides: make hop-to-hop assumptions
[21:59:28] <randy> JP: shouldn't we give guidance to using protocols instead of just "SHOULD support TLS or IPSEC"?
[21:59:53] <randy> Brian Rosen: we can argue about specific words in document
[22:00:42] <randy> John Morris: emergency calls should be the exception and not an exception
[22:04:16] <randy> Randy: this seems to be very US-centric, E-911 centric
[22:04:27] --- anewton has left: Disconnected
[22:04:31] <randy> John Morris: we can try and be explicit without being US-centric
[22:04:34] --- leslie has left
[22:04:35] <randy> We're done
[22:04:37] <michael> wheee! bar time!
[22:05:19] --- hardie has left: Disconnected
[22:08:26] --- hildjj has joined
[22:09:06] --- hildjj has left
[22:09:27] --- jis has left
[22:22:48] --- randy has left: Disconnected
[22:42:43] --- michael has left