I just read through these two documents. For me a specification that extends the existing civic XML elements has to fulfill two requirements:
1) With any new extension there is the chance that the recipient does not understand it. Hence, the added element must be safe to ignored. [We ran into a similar issue with PIDF-LO dynamic and this requirement constraint our solution space.]
2) While the civic location can be copied from one protocol to the other without having the need to understand the semantic of each element in many cases (e.g. from HELD to LoST, from HELD to SIP Location Conveyance) there are cases where this is not true, such as DHCP to LoST. For this case the specification has to provide a description.
draft-ietf-geopriv-prefix-00 focuses on a use case that appears quite narrow but there is obviously the question how to deal with the endless number of civic address extensions. I am missing the introduction of XML elements and how the two requirements above are reflected.
I understand that draft-ietf-geopriv-prefix-00 is already quite far in the process but it nevertheless might we worthwhile to have a discussion about this topic.
Ciao
Hannes
_______________________________________________
Geopriv mailing list
Geopriv@ietf.org
https://www.ietf.org/mailman/listinfo/geopriv
