1 / 9

HTTP Enabled Location Delivery (HELD) draft-ietf-geopriv-http-location-delivery-05.txt

GEOPRIV IETF-71 Meeting Philadelphia, March 2008. HTTP Enabled Location Delivery (HELD) draft-ietf-geopriv-http-location-delivery-05.txt Editor: Mary Barnes ( mary.barnes@nortel.com ) Contributors: James Winterbottom ( james.winterbottom@andrew.com )

belva
Télécharger la présentation

HTTP Enabled Location Delivery (HELD) draft-ietf-geopriv-http-location-delivery-05.txt

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. GEOPRIV IETF-71 Meeting Philadelphia, March 2008 HTTP Enabled Location Delivery (HELD) draft-ietf-geopriv-http-location-delivery-05.txt Editor: Mary Barnes (mary.barnes@nortel.com) Contributors: James Winterbottom (james.winterbottom@andrew.com) Martin Thomson (martin.thomson@andrew.com) Barbara Stark (barbara.stark@bellsouth.com)

  2. Contents • Status • Changes since last version (s) • Issues • Way Forward • Comments/Questions

  3. Status • 2 revisions since IETF-70 • -04 completed WGLC on 29 January 2008. • WGLC on -05 ends on 21 March 2008.

  4. HELD: version -04 changes Changes primarily based on IETF-69 Discussion points: • Terminology: • clarified that "attribute" and "element" are used in the strict XML sense and "parameter" is used as a general protocol term • Replaced term "HTTP delivery" with "HTTP transport". Still have two terms "HTTP transport" and "HTTP binding", but those are consistent with general uses of HTTP. • Editorial changes and clarifications (per mailing list feedback from Roger Marshall and Eric Arolick) • Changed normative language for describing expected and recommended LIS behaviors to be non-normative recommendations in cases where the protocol parameters were not the target of the discussion (e.g., we can't prescribe to the LIS how it determines location or what it defines to be an "accurate" location) • Clarified responseTime attribute (section 6.1). Changed type from "decimal" to "nonNegativeInteger" in XML schema (section 7) • Updated Table 1: • Include only top-level parameters. • fixed some errors in that table (i.e., code for locationResponse) • added PIDF-LO to the table. Related note: Added a detailed section describing PIDF-LO (section 6.6), moving some of the normative text in the Protocol Overview to this section. • HELD: URI: Added schema, description and IANA schema registration • Added IANA registry for error codes.

  5. HELD: version -05 changes • Replaced the security section based on a proposal from Richard Barnes, thus no need to reference the location security document. • Error codes: • Fixed error codes in schema to allow extensibility. • Changed the IANA registration to be "specification required". • Cleaned up the HELD: URI description: • Put the definition in a separate section. • Clarified the applicability to also include being a result of the discovery process • Fixed examples.

  6. HELD: version -05 changes • Updated the LocationURI section: • Per HELD-04 Issue 3: locationURI SHOULD NOT contain any information that could be used to identify the Device or Target (changed MUST to SHOULD) • Include the reference to the new HELD:URI section. • Corrected top level parm in the locationResponse to be locationUriSet, which contains any number of locationURI elements and the "expires" parameter: • Table 1 updated • Added a new section for the LocationURISet • Clarified that "expires" applies to "locationURISet" and not per "locationURI". • Editorial nits: • by-value -> by value, by-reference -> by reference, etc.

  7. HELD: Editorial nits • Terminology inconsistencies (to dash or not): • “by-reference” versus “by reference”/ “by-value” versus “by value” • SIP location document and Location By Reference requirements documents use: Location-by-value (LbyV) and Location-by-reference (LbyR) • Location Configuration Protocol Requirements doc uses: location by Value (LbyV) and location by Reference (LbyR) • Proposal: 2 – IF we feel strongly that it should be the same in all documents, send a note and let the RFC Editor ensure there is consistency. • Response Time description: • Clarify that there is either a “time” or a “purpose” (i.e., emergencyRouting or emergencyDispatch) in the “responseTime” attribute

  8. HELD: Issues/discussion • HELD URI • Definition of HELD: URI remains in this document. Concern raised that more detail on the deferencing use of the HELD: URI should be added. • Includes a reference to location-dereference document, as a user of the HELD:URI, per URI schema registration guidelines (RFC 4395). • Proposal: Since the reference is informational, should not cause problems with progression of this document and the details on the dereferencing use of the HELD: URI belongs in the location dereference document. • VPN Device Serving as a LIS: • Is the intent for the VPN device serving as a LIS to be able to provide LI via HELD to other entities that provide location? • If so, need the sentence to ensure that LI is NOT converted into a form that conveys less information. • Or, is the intent to highlight that protocols other than HELD can be used when a VPN device serves as a LIS? • If so, propose that text discussing the use of DHCP and LLDP-MED be removed altogether.

  9. Way Forward – HELD • Update document: • Editorial changes • Issue resolution per discussion. • Any other comments received by 21 March. • Doc (-06) should be ready for progressing for publication

More Related