(I'll not re-open the debate on whether this is right or not.)
Your definitions for coord-* cannot be constrained as they were. This should suffice for all:
coord = ["-"] 1*DIGIT [ "." *DIGIT ]
coords = coord *("," coord)
You need IANA registries for the crs parameter and parameters in general.
When you say:
Clients MUST NOT attempt to dereference URIs given in an CRS that is
unknown to the client, because doing so would produce entirely bogus
results
You leave unsaid what it actually means to derefence a URI, so I cannot conclude whether this statement is sensible or not. I can imagine systems that are able to at least render the contents of an unknown CRS.
If you intend for the query component (?x=y) to be ignored, then make it part of the URI syntax. Otherwise, forbid it outright. Of course, query components only make sense when the target is known and this URI scheme doesn't identify a target, so I'd actually argue that you are possibly right in omitting it.
Minor nits:
The srsDimension attribute in your examples isn't useful (rather, it's harmful because it can disagree with the CRS). The '6.6' in the srsName should be removed.
> -----Original Message-----
> From: geopriv-bounces@ietf.org [mailto:geopriv-bounces@ietf.org] On
> Behalf Of Alexander Mayrhofer
> Sent: Friday, 3 July 2009 10:43 PM
> To: geopriv@ietf.org
> Subject: [Geopriv] Update to the 'geo' URI scheme
>
>
> All,
>
> I've just posted an update to the "geo" URI scheme draft:
>
> http://tools.ietf.org/id/ietf-geporiv-geo-uri
>
> I went through the discussion we had on the list recently, and applied
> the following changes to the document (mainly along what Ted Hardie has
> proposed in his mail to the list):
>
> - The document does not preclude anymore the use of other coordinate
> reference systems besides WGS-84
> - WGS-84 is still used as the default CRS
> - The definition of other CRSes is up to other documents
>
> To allow for this, i have applied the following changes:
>
> - Extended the ABNF to allow URI parameters
> - Define one (optional!) parameter named "crs"
> - Generalize text where needed and sensible, so that it applies to
> other
> CRSes as well
> - Indicate which text parts are specific to WGS-84
> - Clarified that clients MUST NOT try to interpret URIs with unknown
> CRS
> values.
>
> I think this is the best way forward, since it has only minimal
> implications on the Scheme itself (the optional URI parameter - still
> very simple for the majority of cases), but provides a great deal of
> flexibility - if there's a need to define the use of an additional CRS
> for the URI scheme, anybody can come up with a draft to define a new
> value for the "crs" parameter.
>
> Comments appreciated. From my point of view, next steps would be to
> have
> the document formally reviewed on the "URI-review" list, address
> potential privacy issues (if they apply), and reach final consensus.
>
> Thanks,
>
> Alex
> _______________________________________________
> Geopriv mailing list
> Geopriv@ietf.org
> https://www.ietf.org/mailman/listinfo/geopriv
------------------------------------------------------------------------------------------------
This message is for the designated recipient only and may
contain privileged, proprietary, or otherwise private information.
If you have received it in error, please notify the sender
immediately and delete the original. Any unauthorized use of
this email is prohibited.
------------------------------------------------------------------------------------------------
[mf2]
_______________________________________________
Geopriv mailing list
Geopriv@ietf.org
https://www.ietf.org/mailman/listinfo/geopriv
