See also: IRC log
<matt> open v2 issues
<matt> [[reviewing issue list, determining which open issues should be v2]]
<matt> Scribe: matt
lbolstad: We're going to go
through the V1 issues offline and close them
... Dropping 'Last Position'
dougt: It's not in the spec, no one wants it, not an issue any more.
lbolstad: We'll close
<trackbot> ISSUE-6 -- Is enableHighAccuracy the right naming for this attribute? Should we have it at all? -- OPEN
andreip: We may rename it, we all
sort of knew what it was...
... What we use it for is to power up the GPS in addition to network providers when the flag is true.
... The user for instance may spend a lot of time on their homepage, and they don't need precise position, but just roughly where the user is.
... It's enough to get us relevant results, but doesn't need to be precise enough to power up the GPS.
... Which would consume more battery, etc.
steveblock: The motivation was to reduce battery usage, not to fuzz the results.
andreip: So, the new name for the attribute was useLowPower.
dougt: I don't think I like exchanging one ugly name for another.
Hixie: What would changing mean? Adding a second attribute?
andreip: And put in the doc that
... Allan Thompson strongly disagreed.
dougt: I think this goes back to having the web app ask for accuracy settings.
andreip: But that doesn't solve the power problem.
Hixie: You end up having to know
a magic number for accuracy.
... Using low power is a magic flag that you know 100% accuracy whether you'll trigger the high power mode. While accuracy would mean knowing some arbitrary threshold.
andreip: It's an unfortunate name.
jmorris: Can some of this be solved by even in v1 adding an extra sentence or two of explanation for this?
andreip: What we said was that this was a hint, and could result in more power usage, etc.
jmorris: The explanation given here was a bit more clear than what's in that text.
andreip: State that it's about power consumption.
<scribe> ACTION: andreip to update enableHighAccuracy flag to further clarify that it's about power consumption - V1 [recorded in http://www.w3.org/2009/11/03-geolocation-minutes.html#action01]
<trackbot> Created ACTION-50 - Update enableHighAccuracy flag to further clarify that it's about power consumption - V1 [on Andrei Popescu - due 2009-11-10].
<dougt> hmm. yesterday we talked about dropping removing nsIDOMGeoPositionError::UNKNOWN_ERROR.
amachin: Do you prompt the user that you might use the GPS? You may be indoors and not want to waste the power.
andreip: I don't think there's a need to prompt the user again.
<dougt> does that mean the numeric values are reset?
pecclesi: Isn't it always slower response times and more power?
dougt: Not necessarily. GPS for instance could give faster response times in a watch.
<trackbot> ACTION-50 -- Andrei Popescu to update enableHighAccuracy flag to further clarify that it's about power consumption - V1 -- due 2009-11-10 -- OPEN
lbolstad: Heading and velocity, ISSUE-7
dougt: Not in favor of moving attributes around, can't really move attributes from an interface.
-> http://dev.w3.org/geo/api/spec-source-v2.html V2 Editor's Draft
andreip: Can't really move heading and speed without supporting both.
dougt: declination was another one we'd want to add.
matt: Looking forward, we'll have heading and speed off the Position object in coords with a heading and speed. Will the address object have heading and speed as well?
dougt: I don't think an address resolver would have heading and speed at all.
jmorris: There will be some devices that have only civic address and not lat/lng.
dougt: From my perspective, the location providers have to provide lat/lng.
jmorris: There are Cisco boxes shipping today that provide just civic addresses for instance.
dougt: If you had our browser installed, the location provider that sits inside our code has to known lat/lng as well as civic, so we can negotiate which is more important.
jmorris: Seems odd to have the w3c design for a subset of the usecases.
dougt: We do this all the time... we've thrown out lots of use cases, like emergency services, etc.
jmorris: There are some percent of computing devices in the world that are desktops, that don't have lat/lng.
dougt: But they do these days.
jmorris: That would make a small business who put these things in their offices have to go figure out lat/lng, even if they're just ordering pizza that relies on address.
dougt: Maybe a mailing address is perfectly permissible and the API could support that. For my purposes it has to provide lat/lng.
lbolstad: The current implementations implement the current API, what's the reason for requiring lat/lng?
dougt: From the Web API side,
there's really only one, to determine the accuracy of the civic
... We're determining the civic address without a level of confidence.
... From the Web developer perspective it makes things more complicated, they have to check both coords and the address side to figure out which to use.
... If you say you *always* have to have lat/lng then you don't have to fallback, etc.
lbolstad: Then why do civic address at all?
dougt: There are lots of use
cases for civic addresses.
... Much more accessible for the little guy.
andreip: When you contact a
location provider you can often get both lat/lng and address in
the same query.
... Why is it so hard for these providers to give a lat/lng?
pecclesi: It's a string variable
that's been shipping over the last 10 years.
... PSAP -- public safety access point
jmorris: Lots of devices in the
US are legally required to provide civic addresses and not
... Those devices, and the new ones that will be rolling out over the next ten years or so, are only going to provide civic.
dougt: Why is this a problem if for the most part, Web browsers require lng/lat is that game over?
lbolstad: Why lat/lng?
dougt: For comparison purposes. How do you get the best accuracy between providers?
jmorris: Why not allow the user to provide you with the best location? Pizza delivery for instance, why not let the user say the front gate at an address, rather than lat/lng.
dougt: That's not covered in this spec...
jmorris: If a device only wants
to provide civic, for whatever reason, whether it's capability,
knowledge, hassle, whatever, it seems like a Web API should
support it and not fail if there is no lat/lng.
... It might be reasonable, power consumption issues aside, to send both.
andreip: The downside is that the application now has to fallback.
jmorris: If you have lat/lng and civic send them both every time.
andreip: But you could get back an empty coords and just civic, the app now has to look at the civic address to.
matt: That's no worse than today...
andreip: Well, one way it's an error code, the other is a success and then further digging.
jmorris: We've got fairly narrow
use cases, and with just small changes to the spec we could add
use cases that we might not even be seeing.
... I'm surprised that fx would insist on just getting lat/lng even if it gets civic.
dougt: If you have civic, just
civic and don't have a way of quantifying the accuracy of that
address, it's hard to figure out if you should use it.
... If I get a civic address and no coords, how do I know that civic address is accurate? I could then get another lat/lng from another source and then decide which is more accurate.
lbolstad: Isn't that an
implementation detail? You happen to have multiple
... We're shipping on a Cisco IP phone, not with geolocation support right now... but in an imaginary case where we were to update it, and without using an external provider, there would be a location API that only returns a civic address.
... Now if we shipped with both access to the device API and to google? we would have to determine which is better too.
dougt: I think this is all an implementation detail. We might have constraints beyond the API though.
[[ could civic addresses also include an accuracy figure? ]]
jmorris: Are you only going to work with location providers where you can negotiate the type of information?
dougt: If they provided accuracy information we could do something with the civic addresses?
jmorris: Something like the Cisco
system would have an incredibly high level of accuracy...
... Would it help if this API said something like "We may provide you with lat/lng and civic and if we have lat/lng and unless there is a contrary user instruction (user doesn't want to use GPS, etc) we will always send lat/lng... but we will always send lat/lng if we have it."
dougt: Could build this with the
same options now, and you may have coords only, civic only or
... And it's not up to the author to determine which they get back.
pecclesi: It could also be a localized string.
dougt: We'd also have to figure out how to format it,e tc.
jmorris: In the US NENA is
essentially using the IETF civic address format.
... RBarnes had urged the group to look at what IETF is doing on orientation/velocity.
<jmorris> Richard Barnes suggests that this WG look at http://tools.ietf.org/html/draft-singh-geopriv-pidf-lo-dynamic-07
<jmorris> ... for orientation, velocity, heading
-> http://lists.w3.org/Archives/Member/member-uwa/2009Nov/0001.html discussion in UWA over our privacy response
lbolstad: Let's continue into the issue list with the assumption that civic addressing will be in v2 and discuss this information later.
dougt: We should get someone to spec out the interface including heading/speed, civic addressing and what else? orientation?
andreip: I think orientation should be a separate spec.
pecclesi: But other devices don't have orientation.
dougt: yes they do.
... I don't think orientation should be hung off the geolocation object.
... Like in our orientation implementation we used DOM events.
jmorris: I thought the API could be used for turn by turn directions for instance... don't you want orientation there?
andreip: We're talking about orientation of the device.
lbolstad: Compass and device orientation, are they related?
dougt: Related, but not necessarily the same.
andreip: What do we mean by compass?
lbolstad: Heading implies movement?
dougt: it's a vector.
steveblock: it's a velocity, you
... a compass is just a source of orientation data.
lbolstad: Augmented reality apps for instance need this.
andreip: I don't think orientation should be part of this spec. This WG, but not the same spec.
steveblock: Heading is used to describe the velocity, while orientation is the device itself and nothing to do with the velocity.
jmorris: In some contexts they might be the same.
amachin: vertical speed we don't
... speed is 2d.
dougt: Let's step back. Driving directions may not need orientation right?
steveblock: What do you mean when you say compass though?
dougt: Which direction is magnetic north.
steveblock: Compass is just a
source of orientation data.
... You thought we might only need compass and not orientation, but I'm not sure what you mean by that.
dougt: So, if I knew where I was
and what direction is north, then you don't need heading.
... For instance a GPS when you start knows what direction you are facing.
steveblock: Right, and a GPS if you're stopped the GPS may jitter and heading will change, but not orientation.
dougt: e.g. an iPhone that has
orientation, but not compass... it's got an accelerometer, but
doesn't know what direction it's facing.
... My view of orientation is that it's basically what you get from an accelerometer.
steveblock: A compass or a accelerometer are just sources of data.
dougt: Orientation won't tell you true north, but gravity effects.
<andreip> see Sensor.TYPE_ORIENTATION
dougt: I think of orientation as accelerometer, but that's not right. We'll need both.
steveblock: You're right that an
accelerometer could give you *some* orientation information,
e.g. down, but nothing in the horizontal plane.
... I think we need to see accelerometer and compass as sources of data for the orientation API.
... You could imagine an API making use of both sources to provide orientation information.
dougt: so you could simulate
somethings with accelerometer but not others.
... So neither of these need to be under geolocation object.
lbolstad: Should heading and speed be moved to that new interface?
steveblock: No, those are rate of change things.
dougt: What do we want to do here? Two new DOM events?
steveblock: I don't think we have use cases under geolocation because we don't have use cases for acceleration. Also the gesture processing for instance requires signal processing, so it's a different set of use cases.
dougt: So don't do this under the charter?
steveblock: No, I'm saying it does'nt make sense to include acceleration data under geolocation.
dougt: No, I think these things should be entirely off the geolocation object.
matt: We all agree that this doesn't belong in the geolocation object.
jmorris: If you have two different objects and one has location and the other has this additional information, might you not have to synchronize these?
steveblock: That was my point
about the use cases, we don't have one for acceleration
... You will need to know the time that the measurement was made, not the time you received the event.
lbolstad: Why wouldn't orientation go on geolocation?
andreip: There are use cases for orientation without geolocation.
agrees that acceleration and orientation information do not
belong on the geolocation object.
... WG will work on separate orientation and acceleration spec.
lbolstad: Are we going to add elevation to the coords interface?
steveblock: Elevation is the third component of the velocity vector.
<dougt> two new dom events: http://pastebin.mozilla.org/680818
dougt: what is the use case here?
lbolstad: is the proposal vertical speed or angle?
steveblock: It wasn't very clear.
dougt: We have heading and groundspeed but not vertical speed.
steveblock: We have two out of three components.
lbolstad: The use case of for vertical speed?
dougt: can't you do that with change in altitude?
steveblock: you could do these
all via differentials, but the raw data is more accurate.
... If we've got two of the three, why not all three?
dougt: Maybe a new interface of position.velocity?
steveblock: Current coords is somewhat orthogonal to civic address, but velocity wouldn't be. You could have a velocity on civic addressing.
dougt: Perhaps we remove it for
... Deprecate these two and replace it with something else, might not even be under geolocation or as a DOM event.
steveblock: I think your speed
probably has the same options as your position options.
... Not going to get an altitude velocity without a GPS.
dougt: I got pushback, folks from the DOM side want to use DOM events for things. It's safer, reuse hardened code paths, etc.
steveblock: I think velocity
belongs in geolocation and if we have velocity it should be
... Just need to come up with a name.
pecclesi: Call it vertical speed.
steveblock: Currently the language of the velocity is just 'speed', so it's now difficult to back out...
dougt: Could we add both groundspeed and verticalspeed and deprecate speed.
steveblock: That's an unusual way
to specify the three as now elevation is no longer the tangent
between the two.
... Typically you have a magnitude and two angles or three cartisians.
... Action item to find the right name?
... Angle between the velocity and the horizontal plane.
jmorris: Seems that elevation angle is the term used?
<scribe> ACTION: steveblock to figure out correct term for 'elevation angle' [recorded in http://www.w3.org/2009/11/03-geolocation-minutes.html#action02]
<trackbot> Sorry, couldn't find user - steveblock
<scribe> ACTION: matt to figure out why tracker doesn't know steveblock [recorded in http://www.w3.org/2009/11/03-geolocation-minutes.html#action03]
<trackbot> Created ACTION-51 - Figure out why tracker doesn't know steveblock [on Matt Womer - due 2009-11-10].
<scribe> ACTION: block to figure out correct term for 'elevation angle' [recorded in http://www.w3.org/2009/11/03-geolocation-minutes.html#action04]
<trackbot> Created ACTION-52 - Figure out correct term for 'elevation angle' [on Stephen Block - due 2009-11-10].
<trackbot> ACTION-51 Figure out why tracker doesn't know steveblock closed
<scribe> ACTION: andreip to start strawman orientation and acceleration draft [recorded in http://www.w3.org/2009/11/03-geolocation-minutes.html#action05]
<trackbot> Created ACTION-53 - Start strawman orientation and acceleration draft [on Andrei Popescu - due 2009-11-10].
<scribe> ACTION: matt to figure out charter issues with v2 and orientation/acceleration [recorded in http://www.w3.org/2009/11/03-geolocation-minutes.html#action06]
<trackbot> Created ACTION-54 - Figure out charter issues with v2 and orientation/acceleration [on Matt Womer - due 2009-11-10].
lbolstad: Moving on to ISSUE-76
<trackbot> ISSUE-76 -- Real vs 'fake' location -- OPEN
jmorris: Geopriv has worked on
this issue a lot.
... They've figured out ways to define boxes, and ways to fuzz and minimize the attack of repeated query attacks.
... I personally think that fuzzing is a good option to be able to offer, but I'm not sure if there is interest here.
... Are we figuring out how to fuzz, or are we figuring out how to close the item?
dougt: In our original work we
had fuzzing, and I like the idea whole bunch. We analyzed
... It's very easy to determine where people are even if they are fuzzing, so we dropped the feature, but I'd be very interested in figuring out how to implement this safely.
dougt: I don't believe there's a
need for an API change.
... We might change the accuracy, but the Website will never know.
... it's purely the users' discretion to tell them where they are.
jmorris: I agree in terms of the information handed over to the API, but in V2 you might want to have something, such as directions to the user agent to allow fuzzing.
dougt: Our prototypes had 'tell them where you are', 'don't tell them anything' or 'lie about where you are'... I could go into the details.
jmorris: I would suggest we get RBarnes or others from geopriv to weigh in more heavily.
andreip: Was the result a box or a lat/lng?
dougt: If we just had civic we could fuzz that very easily, just zipcode.
jmorris: Fuzzing lat/lng is obviously harder, but I think it's not that you have to send the entire coordinates of the bounded geometry, but rather a random point within that.
dougt: The problem with that is if they watch you, they can determine where you are. This attack only happens with watch not single shot.
jmorris: The folks on the geopriv list spent a year working on this, I don't have the knowledge of it all, but I'd suggest that you consider whether fuzzing is possible.
<scribe> ACTION: dougt to mail RBarnes about fuzzing [recorded in http://www.w3.org/2009/11/03-geolocation-minutes.html#action07]
<trackbot> Created ACTION-55 - Mail RBarnes about fuzzing [on Doug Turner - due 2009-11-10].
dougt: I'm pretty sure this won't have API changes. We don't want the website knowing this is in effect at last for lat/lng.
jmorris: I think it would be
better not to tell the Website whether fuzzing occurred or
... That reveals private information as well. I might trust Matt but not Steve and that is private information too.
... Fuzzing in v2 could urge implementors to support, but doesn't require changes for the website, but may urge implementors to change UI, etc.
lbolstad: We mean doesn't effect the API itself.
jmorris: Right, it might change the doc, but not the API itself.
lbolstad: What if the UA gets
fuzzified data from their location provider. If the user makes
this choice then it has to go into the API because the user has
to notify the location provider that they want fuzzy
... If fuzzying took place in the location provider the API would have to change.
andreip: No, we wouldn't. It's a change in the API between the UA and the location provider..
<lbolstad> yes, it would require a change in the API between the UA and the location provider
dougt: The location provider doing the fuzzifying would solve these problems.
<trackbot> ISSUE-18 -- Data 'fuzzing' to a bounding box or a municipal region -- OPEN
<trackbot> ISSUE-76 -- Real vs 'fake' location -- OPEN
jmorris: If the UI allows fake addresses, then the user would have the ability to get feedback from a service. e.g. I know in next week I'll be in Rome, and there is a service to find interesting things around your location, and you want to know what to do in Rome, you could fake your address.
steveblock: I think that's outside the spec of this WG.
amachin: Sometimes when using cellid location there is error for instance.
steveblock: From the point of view of the Web app the API is for the users location, regardless of whether it's wrong or not.
dougt: There's no change to the API for lying about the location.
steveblock: Might have to look at
a use case.
... The user faking their position, and then there is the fallback if you can't get a location, get the default that the user may have typed in.
dougt: We looked at this stuff, and we had the user ability to type in a location. I don't like the idea of a website to make that choice for a user.
steveblock: there's forging versus fallback.
[[ @@ some stuff about selecting location providers, separate issue ]]
jmorris: The current v1 spec saying that there is no promise that this location is true, is probably the most important bit from a privacy perspective.
jmorris: That enables my office to write a firefox widget to go supplant some of the geolocation stuff in fx to allow users to fake their location.
amachin: I wouldn't call it faking, it might be the right location. It's a custom location.
jmorris: It doesn't have to use
the term fake at all, just that it might not be the actual
... It's just good that the spec doesn't force truth or prohibit untruth.
[[ preliminary discussions on multiple location providers ]]
lbolstad: Current editor's draft has an address interface.
lbolstad: Did we agree upon a format?
jmorris: I don't think we agreed
upon any particular format, that we pushed it off on to
... Do you want this to work in countries that have more complicated addresses?
... I know Geopriv has developed a fairly robust civic format. I know that NENA and Census folks are also heading towards the same format.
... So, I think this group should look closely.
andreip: The biggest problem that we had at the time was the naming.
jmorris: It's confusing, a1-a6 for instance because outside of Western cultures the concept of street doesn't translate or isn't as precise, etc.
andreip: The proposal in the v2
spec was based on part of Gears and part of the MS
... The Gears format we use worldwide.
jmorris: MikeSmith said that this format would work in Japan.
<dougt> MikeSmith: ping?
<MikeSmith> dougt: what's the question?
jmorris: You could certainly
provide an overlay and explanation of them.
... The biggest question is not so much whether a particular proposal might work in Japan, but whether the W3C should try to conform with what is increasingly getting acceptance.
lbolstad: Where is it getting accepted?
pecclesi: ??Emergency services organization??
<MikeSmith> dougt, yeah, from what I remember of the discussion, the proposed set of fields would be adequate for civic addresses in Japan
dougt: We aren't covering emergency services in our use cases.
<andreip> yep, I posted the URL above
<andreip> here it is again
<MikeSmith> andreip: thanks
jmorris: It's not that we're suggesting building emergency services on the Web, but that the API if it becomes the ubiquitous way of transferring location in the Web, then isn't there value in it working with emergency services if it's not the primary goal.
dougt: If the use cases are about having a ubiquitous format for location on the Web, then maybe, but I'm not sure that's one of the goals.
andreip: We don't have use cases that cover this need...
jmorris: My sense is that this is a narrow concept of what the w3c should be doing.
dougt: We've looked at MS's
format in Office, it's a subset of civic addressing format we
have. It's not very user friendly. If we can get over
... The largest software developer in the world has a format that isn't nearly as complicated as the geopriv one. I don't want to add an api that is any more complicated than needed.
<andreip> the original proposal is here
-> http://lists.w3.org/Archives/Public/public-geolocation/2009Mar/0044.html maps geopriv fields to v2 as proposed by Andrei
lbolstad: how widely is the geopriv stuff implemented?
jmorris: It is being implemented
very widely because it is the format that the law requires in
the US that providers give to Public Service Answer
... That's a transitional thing as we switch from circuit switched emergency systems to packet switched.
... Every carrier in this country has to be able to produce location in this format and so my assumption is that at some point they may be location providers to you.
... I appreciate why you're pushing back for ease of use, but I urge you to continue to think about it.
dougt: I can't think of an API that is that complex on the Web.
matt: WRT to naming?
jmorris: but to take the table from 4119 and stick it as an appendix to this, and that coders would be able to figure it out.
lbolstad: What's the problem with the proposal?
matt: It doesn't just map it merges.
dougt: It's one-directional.
lbolstad: Would the IETF want the same field names exposed through the API?
jmorris: I think they would say that it would not be hard for an implementer to take the full set of 4119 field names and to quickly plot them into something familiar.
dougt: Here's a strawman, we have
8 things proposed (minus additionalInformation field) none of
those overlap with anything in rfc4119. The names don't
... What if we do this in baby steps, we could have those 8 and then also have a1-a6 raw format.
... Like the 8 we have in v2 (minus additionInformation) and then have a separate bit with civic addressing either inline or as another object in there.
matt: Not another addressRFC4119 interface within position?
dougt: No, I don't think you'd want that.
jmorris: Even on street name... Salt Lake City has a bizarre street convention.
pecclesi: Tokyo it's the order of time that streets were made since the railroad.
jmorris: There are names in SLC
that are things like East 300 South and South 300 East that are
... That's some of the granularity the IETF spec has.
... so IETF has leading street prefix and trailing street prefix.
andreip: I think those get coalesced into just street.
jmorris: I think my conflating these you increase the chance of confusion.
lbolstad: Is there a need to compare civic addresses?
dougt: I don't think you can compare.
lbolstad: Well that was one of the reasons given to use IETF naming.
steveblock: Perhaps represent the complete rfc4119 address as a json string that you could evaluate yourself.
jmorris: A string with a delimiter?
steveblock: yes, well, JSON.
jmorris: I'm not versed enough to know...
dougt: So we'd have this simplified version and then the more complete rfc4119 version there as well.
jmorris: There are some addons to rfc4119.
lbolstad: So how widely adopted?
jmorris: RBarnes is at a workshop about harmonizing the emergency services address format... I'm assuming that the global effort is heading in this direction.
lbolstad: We didn't rule out emergency use cases last time.
jmorris: Seems like an
appropriate action for me to go get RBarnes to pitch on what
this group should be using soon.
... I think it's rfc4119 but perhaps also plus some variant, but I'm not sure.
steveblock: Presumably as part of the rfc4119 spec there's a mapping to addresses.
jmorris: My understanding is that each national entity like NENA registers with IANA some mapping.
matt: I see in IANA there's a registry for methods of acquisition for RFC4119, but not seeing mappings: http://www.iana.org/assignments/method-tokens
<andreip> oasis standard here: http://www.oasis-open.org/committees/ciq/Downloads/ciq_all.zip
-> http://www.ietf.org/rfc/rfc4776.txt country specific mappings
steveblock: We could offer conversions.
jmorris: rfc4776 created an IANA registry.
-> http://www.iana.org/assignments/civic-address-types-registry IANA civic address types registry
dougt: You could add methods that
take on converting.
... I don't necessarily like that idea.
andreip: It'd require we comply to rfc4776.
<jmorris> http://www.ietf.org/rfc/rfc5139.txt looks like it updates 4119
lbolstad: It's probably not sufficient to map just 4119 but 5139 as well.
jmorris: I think we should do
5139 rather than 4119.
... 4119 came out 03/04 and there's been effort to figure out the gaps in this, but it wouldn't surprise me if RBarnes or the IETF folks said 5139 covers the known gaps.
-> http://www.ietf.org/proceedings/09nov/agenda/geopriv.html IETF Geopriv meeting agenda for 12 November 2009
lbolstad: We have a mapping of
4119 into v2 fields that is lossy. some things are dumped into
... We will need to provide an updated mapping for 5139 potentially, it's possible those new fields all go into additionalInformation.
... the mapping needs to be written into the specification
... And we will add a DOMString that is optional called TBD?? that represents the address in RFC 5139 or 4119 or whatever. The contents of the attribute would be the full address provided by the RFC format.
<dougt> matt: ty
lbolstad: The string will contain a JSON object that contains the fields required to support the intended RFC.
<lbolstad> or some other format, if Geopriv have a better suggestion
matt: JSON allows us to support formats that might not be out there yet.
dougt: let's get input from the IETF on what information would go in that string.
<scribe> ACTION: lbolstad to send mail RBarnes about what IETF information should go into the raw address string [recorded in http://www.w3.org/2009/11/03-geolocation-minutes.html#action08]
<trackbot> Created ACTION-56 - Send mail RBarnes about what IETF information should go into the raw address string [on Lars Erik Bolstad - due 2009-11-10].
<scribe> ACTION: andreip to put field mapping information into the spec [recorded in http://www.w3.org/2009/11/03-geolocation-minutes.html#action09]
<trackbot> Created ACTION-57 - Put field mapping information into the spec [on Andrei Popescu - due 2009-11-10].
<scribe> ACTION: andreip to add new DOMString attribute that has the raw address information in it. [recorded in http://www.w3.org/2009/11/03-geolocation-minutes.html#action10]
<trackbot> Created ACTION-58 - Add new DOMString attribute that has the raw address information in it. [on Andrei Popescu - due 2009-11-10].
jmorris: I heard keep additionalInformation until you find out more from IETF.
dougt: So, the new Position interface will have one or both of Coordinates or Address, agreed?
jmorris: This sounds OK to me.
Proposed ACTION: andreip to update the mapping with RFC5139 information and include in the spec
lbolstad: And reverse geolocation?
dougt: This is like providing a
Web service standard for reverse geolocation?
... I think this is out of scope, not needed for use cases.
matt: It may be out of scope for this charter, but we should be considering future work as well. I'm not particularly excited by it.
dougt: A Web service could be setup that takes a lat/lng and returns JSON with a mailing address or whatever, but it isn't necessarily something the UA would want.
steveblock: Andrei you mentioned potentially adding a flag to request address.
andreip: This is an implementation decision.
dougt: The less options we give to the Web developer the better.