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.
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.
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.
--Martin
p.s. I was surprised to see that James is now working for TCS..., or not.
_______________________________________________
Geopriv mailing list
Geopriv@ietf.org
https://www.ietf.org/mailman/listinfo/geopriv
