60 likes | 189 Views
Draft Updates. Relative Location draft- ietf -geopriv-relative-location HELD Dereference draft- ietf-geopriv-deref-protocol Location Measurements draft- ietf -geopriv-held-measurements HELD Identity draft- ietf -geopriv-held-identity-extensions. Relative Location. No progress to report
E N D
Draft Updates Relative Location draft-ietf-geopriv-relative-location HELD Dereference draft-ietf-geopriv-deref-protocol Location Measurements draft-ietf-geopriv-held-measurements HELD Identity draft-ietf-geopriv-held-identity-extensions
Relative Location • No progress to report • Lots of minor issues • Might be blocked on resolution to civic address extension discussions (Brian) • Binary format lacks usage context (Martin)
HELD Dereference • GET added after Maastrict discussions • Ready for WGLC
Location Measurements • Changed wifi measurements after lots of feedback from Gabor Bajko • Tweaked SSID format to accommodate binary nature of the field • Seeking final reviews
HELD Identity • DISCUSS: identifying required identity • We use qualified names to identify what a server wants (in “requiredIdentifiers”) • Do we want a registry for these? • Proposal: we shouldn’t create a registry if we don’t need a registry. • We can identify without a registry. • Does a registry aid interoperation enough to justify the cost?
HELD Identity • DISCUSS: TCP or UDP Port Number • There are transport protocols other than TCP and UCP, i.e., SCTP and DCCP. • […] Is there really a use case for identifying devices based on what is basically a socket ID? • If yes, then you need to […] support SCTP and DCCP […]