Honestly, it is *very* late for comments and changes to the document. It
has passed working group last call a *long* time ago, was last called
IETF-wide months ago, and has passed IESG evaluation a month ago.
Which means that any changes that we instruct the RFC editors to do now
on the documents should be editorial ones, rather than affecting the
content.
I'm very open to suggestions of what could be improved, but i would also
rather not want to reopen the whole thing..
Alex
> -----Original Message-----
> From: geopriv-bounces@ietf.org
> [mailto:geopriv-bounces@ietf.org] On Behalf Of Carl Reed
> Sent: Monday, May 03, 2010 5:52 PM
> To: Ivan Shmakov; geopriv@ietf.org
> Subject: Re: [Geopriv] a few tweaks to draft-ietf-geopriv-geo-uri-07
>
> And I have a number of comments and suggestions from the OGC
> Membership that
> I need to consolidate and submit. Some have to do with
> clarification of the
> CRS value definition and usage. This is important as some
> countries, such
> as China, have legal policies regarding CRS definitions for use in
> applications deployed in China. Nothing arbitrary at all.
>
> And Ivan, I have a hard time following your suggested edits
> and comments.
> Perhaps my email scrambled things.
>
> Regards
>
> Carl
>
> ----- Original Message -----
> From: "Ivan Shmakov" <ivan@main.uusia.org>
> To: <geopriv@ietf.org>
> Sent: Monday, May 03, 2010 9:44 AM
> Subject: [Geopriv] a few tweaks to draft-ietf-geopriv-geo-uri-07
>
>
> Glad to see that the specification have progressed further. I
> wonder, wouldn't it be too late to suggest a few more tweaks?
>
> --
> FSF associate member #7257
>
>
>
> --------------------------------------------------------------
> ------------------
>
>
> --- www.ietf.org/id/draft-ietf-geopriv-geo-uri-07.xml 2010-04-14
> 23:31:04.000000000 +0700
> +++ draft-ietf-geopriv-geo-uri-07-1272900834.xml 2010-05-03
> 22:33:54.000000000 +0700
> @@ -99,7 +99,7 @@
> (WGS-84)</xref>. The scheme provides the textual
> representation of
> the location's spatial coordinates in either two or three dimensions
> (latitude, longitude, and optionally altitude for the default
> - CRS of WGS-84). An example of such an 'geo' URI follows:</t>
> + CRS of WGS-84). An example of such a 'geo' URI follows:</t>
> <vspace blankLines='1'/>
> <list style='hanging'>
> <t>geo:13.4125,103.8667</t>
> @@ -123,7 +123,7 @@
> intended to cope with the case of another CRS
> replacing WGS-84
> as the predominantly used one, rather than allowing
> the arbitrary
> use of thousands of CRSes for the URI (which would
> clearly affect
> - interopability). The definition of 'crs' values
> + interoperability). The definition of 'crs' values
> beyond the default of "wgs84" is therefore out of scope of
> this document.
> </t>
> @@ -203,11 +203,11 @@
> </artwork>
>
> <t>Parameter names are case insensitive, use of
> the lowercase
> - representation is PREFERRED. Case sensitivity of
> non-numeric
> + representation is preferred. Case sensitivity of
> non-numeric
> parameter
> values MUST be described in the specification of the
> respective parameter. For the 'crs' parameter, values are
> - case insensitive, and lowercase is PREFERRED.
> + case insensitive, and lowercase is preferred.
> </t>
> <t>Both 'crs' and 'u' parameters MUST NOT appear more than
> once each.
> @@ -370,7 +370,7 @@
> and their values are bitwise identical after
> percent-decoding.
> </t>
> <t>Otherwise, the comparison operation for the
> respective
> URIs
> - is undefined (since the legacy implementation is not
> + is undefined (since the legacy implementation would not
> be aware of the comparison rules for those parameters).
> </t>
> </list>
> @@ -382,7 +382,7 @@
> MUST NOT be considered equal to a URI containing a
> <coord-c>,
> even if the remaining <coord-a>, <coord-b>,
> - and their 'u' values are equivalent.
> + and 'u' values are equivalent.
> </t>
> <t>For the default CRS of WGS-84, the following
> comparison
> rules apply additionally:
> @@ -440,7 +440,7 @@
> <xref target='examples'/>.
> </t>
> </section>
> - <section anchor='uriinterop' title='Interopability Considerations'>
> + <section anchor='uriinterop' title='Interoperability
> Considerations'>
> <t>Like other new URI schemes, the 'geo' URI requires
> support in client applications. Users of
> applications which are
> not aware of the 'geo' scheme are likely not able
> to make direct
> use
> @@ -467,7 +467,7 @@
> locations.
> </t>
> <t>The number of digits in the <coordinates>
> values MUST
> NOT
> - be interpreted as an indication to a certain level of
> + be interpreted as an indication of a certain level of
> accuracy or uncertainty.
> </t>
> </section>
> @@ -495,7 +495,7 @@
> <t>This specification creates a new IANA Registry
> named "'geo' URI
> Parameters Registry" for the <parameter>
> component of the
> URI. Parameters for the 'geo' URI and values
> for these parameters MUST be registered with IANA to prevent
> - namespace collisions, and provide interopability.</t>
> + namespace collisions, and provide interoperability.</t>
> <t>Some parameters accept values that are
> constrained by a syntax
> definition only, while others accept values from a
> predefined set
> only. Some parameters might not accept any values at
> all ("flag"
> @@ -504,7 +504,7 @@
> that accept values from a predefined set.</t>
> <t>The specification of a parameter MUST fully
> explain the syntax,
> intended usage and semantics of the parameter. This ensures
> - interopability between independent implementations.</t>
> + interoperability between independent implementations.</t>
> <t>For parameters that are neither restricted to a set of
> predefined
> values nor of the "flag" type described above, the syntax of
> allowed values MUST be described in the specification, for example
> @@ -522,11 +522,11 @@
> <t>"No value": The parameter does not accept any
> values, and
> is to be used as a "flag" only.</t>
> <t>"Predefined": The parameter does accept values from a
> - predefined set only, as specified in a RFC or
> other permanent
> + predefined set only, as specified in an RFC or
> other permanent
> and readily available public specification.</t>
> <t>"Constrained": The parameter accepts arbitrary values
> that are only constrained by a syntax as specified in
> - a RFC or other permanent and readily available public
> + an RFC or other permanent and readily available public
> specification.</t>
> </list>
> </t>
> @@ -555,7 +555,7 @@
> </t>
> </list>
> </t>
> - <t>Note that the examples and use cases aboves
> as well as in
> + <t>Note that the examples and use cases above
> as well as in
> the next section are non-normative, and provided for
> information
> only.</t>
> </section> <!-- end of URI Operations section -->
> @@ -595,11 +595,11 @@
> <t>Resolution of the URI returns the following
> information:</t>
> <vspace blankLines='1'/>
> <list style='symbols'>
> - <t>The 'crs' is given in the URI, and
> sets the CRS used
> in the URI to WGS-84 explicitely.</t>
> + <t>The 'crs' is given in the URI, and
> sets the CRS used
> in the URI to WGS-84 explicitly.</t>
> <t>The URI does omit <coord-c>, is hence
> 2-dimensional, and therefore uses
> 'urn:ogc:def:crs:EPSG::4326' as the WGS-84
> CRS identifier.</t>
> <t>The <coord-a> value (latitude
> in WGS-84) is
> set to '48.198634' decimal degrees.</t>
> <t>The <coord-b> value (longitude
> in WGS-84) is
> set to '16.371648' decimal degrees.</t>
> - <t>The <coord-c> (altitude) value
> is undefined,
> hence the client MAY assume the identified location to be on Earth's
> physical surface.</t>
> + <t>The <coord-c> (altitude) value
> is undefined,
> hence the client MAY assume the identified location to be on
> the Earth's
> physical surface.</t>
> <t>The 'u' parameter is included in the
> URI, setting
> uncertainty to 40 meters.</t>
> </list>
> @@ -870,7 +870,7 @@
> URIs with such values, and SHOULD warn the user when such
> URIs are encountered.
> </t>
> - <t>An example of such an URI referring to an invalid location
> + <t>An example of such a URI referring to an invalid location
> would be <geo:94,0> (latitude "beyond" north pole).
> </t>
> </section>
>
>
>
> --------------------------------------------------------------
> ------------------
>
>
> > _______________________________________________
> > Geopriv mailing list
> > Geopriv@ietf.org
> > https://www.ietf.org/mailman/listinfo/geopriv
> >
>
> _______________________________________________
> Geopriv mailing list
> Geopriv@ietf.org
> https://www.ietf.org/mailman/listinfo/geopriv
>
>
>
_______________________________________________
Geopriv mailing list
Geopriv@ietf.org
https://www.ietf.org/mailman/listinfo/geopriv
