Wiki

Edit this Page View Revision History

Calls 2011-09-Summit

Meeting Details

Notes for the Open311 GeoReport v2 Community Summit September 30, 2011 2:00-4:30pm Original notes taken at: http://etherplans.org/open311-2011-09-30

Current spec: http://wiki.open311.org/GeoReport_v2 Meeting Details: https://docs.google.com/document/pub?id=1hbsPwQHNrxGqTgZHTGQgujqoFNQD5pDQt52KvhigibQ

Agenda:

10 mins: Introductions 10 mins: Open311 current state and roadmap 10 mins: Review list of GeoReport issues 70 mins: GeoReport enhancement discussion 20 mins: Follow-up & next steps

Tickets:

eg http://developer.open311.org/ticket/33

#33 Define Media Handling (eg multipart post) + PFA, AN, PW #35 Define Comment Handling, + PFA, Kam, AN #37 Define Update Request (eg to update status and status_notes) + PFA, Kam #55 Clarify error handling, + PFA, Kam, AN, PW #51 Add full update history as part of Get Service Requests + PFA, Kam #56 Allow for subscribing or callbacks on future events (eg PuSH) + Kam #28 Add updated_datetime as parameter to GET Service Requests #52 Add page and page_size parameters to GET Service Requests +AN #39 Add option to load all Service Definitions in a call to Get Services #26 Add lat/long as a request parameter for GET Services + Kam, PW #29 Rename address to address_string in Get Service Requests +PW #31 Add location accuracy for coordinates on Post Service Request #38 Add compass heading to improve location accuracy #32 Add device make and model for debugging Post Service Request submissions #54 Provide an authentication mechanism +AN, Btown #53 Support multiple languages and robust internationalization, +PFA, Kam, PW, Btown

New Tickets

These have been added to the tracker since the call or still need to be added (if they’re listed as #00)

#60 Require JSON +Kam #61 Namespacing & extensibility +AN #62 Clarify that service_request_id does not have to be an integer +PW #63 JSONP Cross Domain handling +KL 00 General community management and improvements to documentation and tools (eg iodocs, validator), +PFA, Kam 00 Clarify API key handling +AN 00 Optional/Required fields in the base spec (not the custom field extensions) +AN 00 Add secondary questions to Request object 00 Field length limits / Regular Expression rules +AN 00 CAPTCHA-equivalent (NYC wants for data quality, flood attack prevention) +AN 00 Non-spatial SRs +PFA, +AN 00 List of Permissions in Service Discovery 00 Conditional fields, +AN 00 Additional data in response to SR submit +AN 00 Distinguishing Identity of OPEN311 Server (Logo.url, color, bgcolor, etc) +BTown 00 Index of Deployments / Geodatabase of Deployments +Btown

Kam’s Lets Just Pick Corner ;)

Seem really simple and/or could be easy optional standards we just need to pick a standard.

I’m going to interpret this as meaning these are some issues that Kam thinks could/should be addressed for v2.1 -phil

63 JSONP Cross Domain handling 62 Clarify that service_request_id does not have to be an integer #28 Add updated_datetime as parameter to GET Service Requests #52 Add page and page_size parameters to GET Service Requests #31 Add location accuracy for coordinates on Post Service Request #33 Define Media Handling (eg multipart post) #51 Add full update history as part of Get Service Requests #39 Add option to load all Service Definitions in a call to Get Services #26 Add lat/long as a request parameter for GET Services

Major Topics

Authentication:

2 conditions: 1) eg in Alexandria, some services are expare exposed based on credentials (permissions to access certain services). in NYC we want to limit the ability to retrieve status to certain people. Peter Watkins - privacy and convenience. Privacy,e g 211. Convenience to view just your own requests. API Keys aren’t user specific, more app specific. identification vs authentication. Authentication helps ensure identification. Not all of this data is public, eg couldn’t all be called through FOIA, so there are real privacy needs authentication for back-end updates. Security - how do you prevent a lot of submissions of fake/bad/malicious data. Authentication not a hard requirement for this, but would help. From SCF - no authentication is required, anything can be submitted. It has been abused before, but we’ve handled with rate limiting and other filtering on server side to process those. Protection against more aggressive things like anonymous, aggressive governments? Authentication would require accounts, use something like a CAPTCHA to get account. Mark: CAPTCHA prevents other modalities, eg SMS Andrew: NYC does currently accept anonymous requests, but uses a CAPTCHA for web, but accepts all via SMS, phone. Data quality is main concern. Also concern of being flooded with requests. Peter: device_id can be used as identifier. If not authenticated for SR, get routed to URL with more information. balance between access and security conflation of preventing attacks and identities they are separate issues, but authentication might help control both. Kam: balance between human interaction and machine to machine interaction Andrew: other specs that can help inform this? Dave: This is from very IT perspective, goal is to ease customer service. Balance between excessive security and ease and quality of service. How are things currently limited/authenticated in NYC? Could spin up lots of virtual phone lines and flood NYC 311 with calls/sms. Yes, it’s a balance of convenience and security Andrew: like idea of token, rate limit the token. Peter: cities with authentication use cases work together and propose solution propose approaches for various security environments, eg WS sec Mark: Peter: API keys are used for lots of users, want to be able to pinpoint specific users. Table this specific discussion.

Andrew Nicklin: Namespacing within the spec, eg this is done in XML, not sure about JSON. Could create a specific namespace for extensions that factor in these issues.

Kam: has to jump off, recognizes need for security. Urge us to use existing standards that are proven secure rather than just trying to do something that isn’t particularly effective and complicates the spec. Low hanging fruit to priortize, eg JSONP

Error Handling

  • A structured data object returned about what was wrong, eg array of fields that were malformed or not provided.
  • Idea of keeping the http error codes, having more complex data in payload.
  • Peter: implementations should start pooling the common errors and help define
  • Error codes that would allow the client to automatically respond to problem, eg highlight the fields that are problematic. Add structure to the error response to list issues specific to fields, explain what was wrong with each field.
  • Required fields in core spec and input validation via things like regular expression.
  • The core spec defines certain things as required but
  • require locations?
  • Add option to load all Service Definitions in a call to Get Services

Prioritization

The version numbers are just sketched out proposals and have not been fully discussed, this was just an attempt to outline what part of the roadmap certain features or issues might fit into. These have been slightly reordered from the original notes so that the version number groups were in order

2.1

  • Not require location.
  • Core fields requirements, eg first name and last name.
  • Better defined required fields. Refer to mailing list discussion on how to do this in 2.1
  • add page and page_size.

2.x

  • either through appending to existing fields or with additional (ignorable) fields. Implementor can decide which fields to use.
  • Comments or additional information for same request. Parallel for status_note updates.
  • Appending additional information for existing requests. Have a separate method in the API to append information. Append or have more structure to additional information.
  • Open question: how additional datastructure in XML and JSON affect backward compatibility in 2.x

2.x or 3

  • parameters to query for service requests.
  • status, status_notes, updated_datetime, etc
  • Query by lat/long?
  • Exact match vs ranges. eg, dates would allow ranges. lat/long
  • So think about core fields, perhaps not custom fields in service definitions.

Media Handling

  • Andrew: NYC doesn’t want to lean on third party services for media handling. Reasons for data retention, just around business operations, need to have copy on local environment, don’t want to worry about control.
  • Dave: both are not bad options. You could import from external URL. How to specify - some point during service definition it will convey how it supports media.
  • Control media on a service by service.
  • For 2.1 add ability to accept multipart
  • For 3.0 you can chose how to handle media based on service definition. Also indicate MIME types, file sizes.
  • restrictions on file types, file size, etc.

3.x

  • Geocoding as part of the spec?
  • Set field parameters.
  • field constraints, being able to specify length of field and perhaps regular expression testing. Supply the expression to client.
  • variability of regular expressions?
  • Perhaps not regular expressions, but some indication of how the parameters should be provided, eg field lengths.
  • Client “should” warn the user if their input doesn’t match the parameters, but accepts anything and does full blown validation through roundtrip.

3.x or 4

  • Push updates through callback. Subscription.
  • eg PuSH or Websockets, etc. Get away from people polling your system, particularly in batch.
  • In NYC, updates aren’t realtime anyway (syncing between two systems periodically), but helpful to not poll whole system. Clients could register a callback URL.
  • Peter: part of registering API key can factor in callback URLs
  • SCF routes reports to Boston through Open311, then SCF polls the Boston Open311 API for status updates. Connected Bits would prefer if they could just push updates to SCF. Perhaps folks like SCF and CB could work together on a proposal for push.
  • Push approach focused on aggregators rather than individual clients? Allow push notifications to any subscriber to provide faster updates for customer.

Other

  • Schemas?
  • namespacing?
  • NYC take a stab at writing an XML schema
  • Also look at JSON schema.
  • GeoWebDNS - Service Discovery or LoST
  • Bloomington iPhone app generic to be able to point at any endpoint.
  • You can have “favorite” endpoints, for you city, county, state, etc.
  • Better identify the endpoint, color, logo, etc. Something equivalent to HTML background color. To distinguish endpoints in multi-endpoint GUIs
  • At least be able to identify the name and location of the Endpoint, eg NYC 311, New York, NY
  • Bloomington interface has ability to either choose which one Open311 endpoint (gov’t jurisdiction) before hand or choose multiple simultaneously.
  • Aggregate or merge services across overlapping jurisdictions, eg display all service definitions from city and state at same time.
  • There’s an opportunity to expand services through API more so than