In the end, it's about interopability - that's what the IETF is
concerned when new protocols are developed. And as it can be seen from
the multiple efforts to develop encrypted variants of RTP, too many
choices for a particular problem can clearly hamper interopability, and
in the end, deployment.
Why? Because both sides have to go significant efforts to support all
the variants that are possible - if they don't, chances are very high
that communication fails. For example, i thing there were 12 variants of
encrypted RTP. If any client can support only 2 of those 12 ways,
chances that communication could actually take place between random
clients would be very low... Clearly, nobody ever implemented all 12 in
a single client.
And it's the same with the thousands of CRSes out there. Yes, i know
that there is software like PROJ that can handle *most* of those CRSes -
but i wouldn't expect that every tiny mobile device out there would
include a PROJ just for the eventual case that they *might* encounter
data in one of those thousands CRSes. In my opinion, requiring every
client to support all those CRSes would hinder deployment significantly.
A nice metaphor just came to my mind:
My native language is German, while your's is probably Russian (wild
guess!). Still, we are using English to converse with each other -
because it gives us interopability, and in the end allows us to
communicate with each other. The other option would be than everybody
learns all the 200 (wild guess again!) languages that are spoken in the
world - just in case we *might* need one of those one day. That would be
a lot of effort if everybody would learn every possible language "just
for the case".
However, if one day a different language might become the predominant
one used in international business, we both might have to learn it. But
then, both of us spent the effort of just learning 2 languages, rather
than 200.
Plus, if you really want to convey spatial information in whatever CRS
you like, then there's always GML - and for most applications among
professionals, that would probably be the way to go.
Alex
_______________________________________________
Geopriv mailing list
Geopriv@ietf.org
https://www.ietf.org/mailman/listinfo/geopriv
