Sunday, March 27, 2011

Re: [Geopriv] draft-marshall-geopriv-location-transform-00

Martin:
I appreciate your comments. Please find my short responses inline.

-roger.

-----Original Message-----
From: Thomson, Martin [mailto:Martin.Thomson@commscope.com]
Sent: Wednesday, March 16, 2011 8:30 PM
To: geopriv@ietf.org;
draft-marshall-geopriv-location-transform@tools.ietf.org
Subject: draft-marshall-geopriv-location-transform-00

This new attempt on the old idea is a good sign that the authors are
intent on getting this right. I like that.

At this stage, there isn't a really enough detail to properly assess the
draft.

I think that the basic model that is hinted at in Section 8 could be
structured differently. The current suggestion has several points of
articulation. Civic has a range of profiles, which is probably only one
layer; but geodetic locations have both CRS and shape. That leads to a
plethora of transformations when all combinations are considered.

When each is combined, both input and output of the transformation need
to be described with a subset of: location type, civic address profile,
civic address language, geographic CRS, geodetic shape, and anything
else that is later added.

[rm - okay, I think this makes sense.]

Rather than specify a whole range of x-to-y transforms, in all the
combinatorial glory that implies, this could be made quite simple. The
service accepts a location and a description of the location that is
desired. The service either produces the desired form, or an error.
The error can indicate that the target form is not supported, or that
the input form is not one of those that are supported for the output
form (or the range of other errors specific to the transformation). In
either case, the service might be able to describe the forms that it
desires.

[rm - agree that simple is good.]

That all assumes that you are using a request-response model for the
protocol, which would seem to be the case, but that detail is absent. I
can think of other models, some of which could have advantages. For
instance, if you could imagine using REST and even HTTP content
negotiation for the transformed object, it might work, particularly when
you are talking about producing civic addresses, which might be
manifested as discrete resources.

[rm - okay, I don't think we're tied down to anything yet.]

--Martin

p.s. I was surprised to see that James is now working for TCS..., or
not.

CONFIDENTIALITY NOTICE: The information contained in this message may be privileged and/or confidential. If you are not the intended recipient, or responsible for delivering this message to the intended recipient, any review, forwarding, dissemination, distribution or copying of this communication or any attachment(s) is strictly prohibited. If you have received this message in error, please notify the sender immediately, and delete it and all attachments from your computer and network.
_______________________________________________
Geopriv mailing list
Geopriv@ietf.org
https://www.ietf.org/mailman/listinfo/geopriv