----------------------------------------+-----------------------------------
Reporter: alexander.mayrhofer@… | Owner: alexander.mayrhofer@…
Type: task | Status: closed
Priority: major | Milestone:
Component: geo-uri | Version:
Severity: - | Resolution: fixed
Keywords: |
----------------------------------------+-----------------------------------
Changes (by alexander.mayrhofer@…):
* status: new => closed
* resolution: => fixed
Comment:
Cleaning up tickets: An agreement with the AD was reached in October 2009.
Message from Cullen Jennings to the draft authors follows (crs registry
has meanwhile been defined in the draft):
>
>> Please add an IANA registry for the crs values. Initially it would
>> only have wgs84. The registry needs a pointer to the spec
>> that defines
>> wgs84. There should be advice about how adding new values reduces
>> interoperability and should not be done lightly. I suspect the right
>> registration procedure is specification required plus IESG approval.
>
> I have thought about doing that. However, the idea was that given that
> there will hopefully only few "crs" values in the near future (ball
> park
> assumption: 3 in the next 5 years?) i wasn't entirely convinced that
> there would be the need for a seperate registration, burdening IANA.
agree there will be very few. The nice part of an IANA registry is it
makes it clear how new ones get defined and it is easy for IANA to do
this stuff.
>
> The idea now is to have the various specifications that define values
> for the parameter to list in the URI parameter registry itself, for
> example
>
> Parameter Name Value Restriction Reference(s)
> ---------------------------------------------------------------------
> Crs Predefined [RFCXXXX] [RFCYYYY] [RFCZZZ]
>
> Given that RFCxxxx is the "base" geo URI definition, and RFCYYYY /
> RFCZZZZ define additional values for the crs parameter.
Well the questions come like can theses RFC be informational even
thought they at some level "update" this RFC.
>
> Would that be an option for this problem, given that there should be
> limited numbers of crs values registered? If there are more than a
> bunch
> registered, one could still define a seperate registry.
>
> I understand that this approach is not documented as clearly as it
> should be, but i was looking at the SIP URI parameters registry
> (RFC3969), which seems to take a similar approach (no seperate
> registry
> for actual values of parameters - Section 4.1) - see the "user" URI
> parameter on http://www.iana.org/assignments/sip-parameters
>
> I can certainly add a registry for the crs values itself if that is
> really needed - or shall i rather clarify the idea described above?
I think we need to clarify how new values are created one way or
another. My guess is that an IANA registry is probably the simplest
way to do this but I'm open to doing it anyway as long as it is clear
how to do it and is clear that appropriate folks will get enough
notification to object because this is a case where we don't want too
many coordinate systems in use.
>
> Advice appreciated ...
>
>> I'd like to talk in this email thread about having an optional
>> vertical uncertainly that is different than the horizontal
>> uncertainty. In many cases, you have huge vertical uncertainty and
>> very little horizontal. I don't know if the WG talked about this but
>> if so, can you point me at the thread.
>
> The whole uncertainty discussion started here:
>
> http://www.ietf.org/mail-archive/web/geopriv/current/msg07622.html
>
> The initial proposal by a "non-regular" WG participant was to include
> +/- degrees (given essentially a "box", that even worse depends on the
> crs). The discussion then evolved into using meters - There was then a
> discussion that a too complex uncertainty could threaten the intended
> simplicity of the URI.
>
> The same person then brought up the issue of "per-axis" uncertainty
> here:
>
> http://www.ietf.org/mail-archive/web/geopriv/current/msg07649.html
>
> And Martin Thomson described that for RFC3825 that it was probably a
> bad
> choice, and if there's the need for more complex scenarios than the
> geo
> URI can provide, there's always PIDF-LO:
>
> http://www.ietf.org/mail-archive/web/geopriv/current/msg07656.html
>
> <cite>
>> I'd rather opt for a set of per-axis parameters.
>
> RFC 3825 did that. It only increases the complexity. Part of the
> advantage of this geo: URI is its simplicity. If you want rich
> expressions of regions of uncertainty, then use an http[s]: URI that
> resolves to a PIDF-LO (c.f. RFC 5491). We can do per-axis uncertainty
> there.
> </cite>
>
> We also discussed that in face-to-face discussions, and agreed that it
> would be better to have less complexity, and use PIDF-LO for the more
> complex scenarios. Uncertainty itself is already more complicated than
> most "casual" users of coordinates will ever venture ..
>
> Based on those discussions, i included *one* uncertainty parameter for
> the scheme. If you like, we can re-open the discussion on the mailing
> list - but i fear that this would be re-opening a can of worms....
I'm sold, leave it as is. Anything but opening up an old
conversation :-) Thanks for pointing me at the previous emails. That
makes it easy for me to go with this.
--
Ticket URL: <https://wiki.tools.ietf.org/wg/geopriv/trac/ticket/25#comment:1>
geopriv <http://tools.ietf.org/geopriv/>
_______________________________________________
Geopriv mailing list
Geopriv@ietf.org
https://www.ietf.org/mailman/listinfo/geopriv
