[00:49:34] martin.thomson joins the room [00:49:58] martin.thomson has set the subject to: GEOPRIV, IETF 79 [00:50:58] Rosen, Brian joins the room [00:51:23] martin are you in the room now? [00:51:33] Valley C? [00:52:02] The tools agenda is borked, and I'm not sure I have the right audio channel [00:54:37] valley C [00:54:48] sorry, was reading your email [00:54:58] and disagreeing thoroughly [00:55:07] can someone say something in the mic [00:55:12] of course [00:55:35] thanks [00:55:42] i have it correct [00:55:42] gee, that delay isn't too bad [00:55:48] it's channel 8 [00:55:53] yesterday, Cullen was getting about 1:30 delay [00:56:10] ugh [00:56:23] martin.thomson has set the subject to: GEOPRIV, IETF 79, Audio Channel 8, [00:56:32] yeah, he gave up trying to interact [00:57:12] we should use skype [00:57:29] richard joins the room [00:58:02] good evening, brian! [00:58:33] hello richard [00:58:41] how is it going? [01:00:05] richard is up and about, he's not ignoring you [01:00:21] np [01:00:50] sm joins the room [01:02:43] I'm jabber scribing [01:02:51] thanks! [01:03:18] prefix with "mic:" if you want something said [01:03:22] will do [01:03:53] Gonzalo joins the room [01:03:53] not bad, brian, not bad [01:03:57] attendance is a little light today [01:04:12] We are 11 people at CUSS. How many do you have there? [01:04:30] a few more than 11 Gonzalo [01:04:45] We just became 12 here! :) [01:04:50] 30 [01:05:04] Randall Gellens joins the room [01:05:28] i coung 28 [01:05:29] ray joins the room [01:05:42] whoa, mr math! [01:08:01] Minor_Issue joins the room [01:08:07] No significant progress, lots of minor issues [01:08:21] Colman Ho joins the room [01:08:35] Jonathan Lennox joins the room [01:09:15] as0-d91k joins the room [01:09:26] - now HELD deref [01:09:30] draft now includes HTTP GET support [01:09:51] James P at mic [01:13:20] Richard now talking about extensions to PIDF-LO [01:15:04] brian, is this a fair summary [01:15:20] yes, this is a good summary [01:16:32] I don't think there is an intention to change behavior of existing elements [01:17:33] Ted admonishes a photographer in Mandarin... [01:20:31] stpeter joins the room [01:21:22] Brian, is the issue here that you think the NENA-style authorities will limit themselves to things they register or find in the registries? [01:21:37] (I guess that's not an issue, but the theory here?) [01:21:42] the "x-" discussion has happened on the apps-discuss@ietf.org list [01:22:32] Hannes presenting on geolocation policy [01:22:47] No [01:23:06] Okay, thanks for clearing that up. [01:23:12] I think we should encourage re-use [01:23:27] So Street Prefix is Street Prefix everywhere you need a street prefix [01:23:32] RjS joins the room [01:24:01] A general use element should go in the existing registry and be generally useful [01:24:02] brian: maybe a FCFS registry of optional extension elements? [01:24:19] that would enable folks to publish what they're doing [01:24:21] That would be the registry for the second ("local") extensions [01:24:25] Brian: And your concern is that registering elements in the namespaces minted by specific authorities increases the complexity [01:24:30] providing a source for moving things into the "official" list [01:24:59] I have to claim to understand some bit of the australian schema is I wish to use the "Street Prefix" element they created [01:25:02] no, it's not the complexity, it's the lack of review and re-use [01:25:55] well, so suppose the Austrailian addressing authority created a new namespace with 10 new elements, one of which was street prefix. [01:26:09] You could, if you knew about it, use that one element in your PIDF [01:26:18] and an element from the Austrian namespace [01:26:29] and 2 elements from the U.S. namespace [01:26:52] but ignore the other 15 elements in those namespaces [01:27:02] I think that a registry that notes the tuples (namespace, element) does what you want, without changing the extensibility mechanism. If there does arise a need to harmonize, you can use a generalized schema for the ones folks agree on. That means clients that understand the old pre-harmoized version and the new harmonized version both work, though there is some additional complexity in validation. [01:27:05] you end up with a valid, but messy PIDF [01:27:20] Brian: yes, but the messy doesn't show up to humans [01:27:34] Colman Ho leaves the room [01:27:50] The ext/localExt makes it ONE namespace [01:27:57] and keeps all the other characteristics [01:28:08] while adding either a lot or a little review [01:28:54] the "little review" just tries to keep things like spelling consistent, and re-use as much as possible [01:29:01] small barrier [01:29:01] Colman Ho joins the room [01:30:11] Brian: But the ext/localExt elements may not all be understood [01:30:38] There is Morality Considerations [01:31:08] As long as the lie isn't so bad that you need to set the Evil Bit [01:31:43] bar [01:31:45] I can set the evil bit if I want to set it [01:31:45] versus [01:32:19] bar [01:32:21] as with any other element, you ignore the ones you don't understand [01:33:20] well, it would be Avenue right? [01:34:32] there has to be an xmlns:ext somewhere [01:35:12] One, at the head of the PIDF, which covers all the extCAtypes [01:35:12] Brian: I think the point you just made "as with any other element, you ignore the ones you don't understand" reinforces the core point. If you have a registry of "intended to be common extensions" that uses a namespace/element tuple, the results are exactly the same; anyone who want to implement them can and any other aspects of that schema can be ignored. [01:35:17] What am I missing? [01:36:00] The review can occur even then, yes? [01:36:02] There is ONE place to look for all extensions, and a review of them, either relatively hard review or relatively minor review [01:36:23] with the -local-civic approach, there is nowhere to look and no review [01:37:11] If you have a registry, with a review, but each element has a namespace, it works, it's just incrementally harder to construct the name [01:37:21] The existence doesn't function as a gating function when the elements it registers can be independently minted. You can put one up, encourage review and re-use either way. You can't force this use either way. [01:37:28] (existence of a registry) [01:37:32] I don't care all that much about this point. I want the registries a lot more than I care how the XML looks [01:37:33] fnord fnord fnord fnord [01:37:44] beauty contest! [01:38:08] Brian: I think the registry with namespace, element tuples works with the existing system well, and you may well be able to get folks to use it. [01:38:30] well, the difference is that if each extension has "it's own" namespace (which no one is actually proposing) then you have a whole lot of them potentially [01:38:34] But my dog left this hunt a long time ago, so it's functionally just some guys opinion [01:38:52] brian: potentially, but probably not in reality [01:40:17] Again, this is a minor point to me, but pressing on, the namespace isn't getting anything of value, and it is making the PIDF more complex for not getting value [01:41:11] It's slower (have to import all the schemas), it's bigger, and it's not helpful [01:41:41] brian: the value is not breaking LoST [01:42:05] foo:A7bar:A8 [01:42:41] ext:extCAtype+STP [01:42:56] as -local-civic suggests [01:42:59] speaking of hacks (but I don't disagree, Brian) [01:43:49] it works, it's just ugly. If we change LoST so that it just allows extCAtype names to exist in the list, it's less ugly [01:43:54] no schema change [01:44:18] that does take a schema change, sadly [01:44:23] why? [01:44:34] etc. are defined as QName lists [01:44:45] the current schema prohibits it, as richard says [01:44:58] brian: The namespace is a core part of the identifier in XML. That's its value in *both* cases. The concern with importing the whole schema is an implementation issue with how the client imports namespaces is a bit of a red herring, because it will have to import a extension list in any case. The difference in memory in a reasonable implementation seems pretty minor to me. [01:45:52] it's ONE namespace (the extension namespace) for ALL extension CAtypes [01:46:17] Ah, I see the point [01:46:34] importing the registry is the same as importing the namespaces. True [01:46:54] I don't think you actually do that, but it's a valid point [01:46:55] Martin now presenting on location obscuring [01:49:09] -local-civic says: To deal with this problem, a set of pseudo-elements are defined. These pseudo-elements exist in the "urn:ietf:params:xml:ns:pidf:geopriv10:civicAddr:ext" namespace, like the "EXT" element, but are not defined in the corresponding schema. The local name of each of these elements is formed from the string "CAtype" plus the decimal value of the "CAtype" attribute. This pseudo-element name is included in addition to the "EXT" element name. [01:50:12] so we need to revise -local-civic :) [01:50:40] well, it's a solution to the LoST problem without updating the LoST schema [01:51:01] pk joins the room [01:51:05] I would use the name, not the number [01:51:17] pk leaves the room: Computer went to sleep [01:51:53] i don't see why you would use a hack when the current mechanism works, just for the sake of some syntactic sugar [01:52:14] back to explosion of namespaces [01:52:25] It's a tradeoff [01:52:35] yeah, let's shelve this for now [01:52:39] okay [01:52:44] martin's showing us pretty pictures :) [01:52:53] I'm lookin at them [01:56:07] pk joins the room [02:25:26] not global addressing [02:28:03] right [02:36:14] paul.erkkila joins the room [02:46:03] possible better 3rd-party solution: http://meetings.apnic.net/__data/assets/powerpoint_doc/0006/24576/Lepinski-APNIC-30-Geolocation-Registry.ppt [02:46:14] PDF: http://meetings.apnic.net/__data/assets/pdf_file/0005/23486/Lepinski-APNIC-30-Geolocation-Registry.pdf [02:47:50] should this be an OGC thing? [02:57:23] interesting... [02:57:27] ray leaves the room [03:01:09] RjS leaves the room [03:03:51] RjS joins the room [03:09:12] ietf-privacy@ietf.org [03:10:10] Gonzalo leaves the room [03:13:04] Randall Gellens leaves the room [03:13:07] RjS leaves the room [03:13:18] Rosen, Brian leaves the room [03:14:05] as0-d91k leaves the room [03:15:00] richard leaves the room [03:19:13] Colman Ho leaves the room [03:22:14] paul.erkkila leaves the room [03:25:29] martin.thomson leaves the room [03:27:05] Jonathan Lennox leaves the room [03:28:04] pk leaves the room: Computer went to sleep [03:29:07] Minor_Issue leaves the room [03:40:27] hardie joins the room [03:58:19] stpeter leaves the room: Disconnected: connection closed [04:45:23] hardie leaves the room [04:56:19] martin.thomson joins the room [04:56:30] RjS joins the room [04:59:27] martin.thomson leaves the room [05:04:08] RjS leaves the room [05:12:02] stpeter joins the room [05:34:39] sm leaves the room [05:38:29] stpeter leaves the room [09:10:06] pk joins the room [09:10:13] pk leaves the room