At 08:02 19-07-2013, Tim Bray wrote:
I'm not sure from reading the draft what the goal of having this URN
namespace is, but if it involves encouraging its use by application
developers, I'm pretty sure it's a bad idea.
I agree that it sounds like a bad idea to encourage application
developers to use this URN namespace. There was a documented
vulnerability which demonstrated how the IMEI could be captured.
In 2006 Leslie Daigle mentioned that the sub-NID namespace does not
belong in the version of the draft which was reviewed.
I'll quote some comments posted by Scott Brim in September 2010 to
Apps Area Review.
'First, this feels like a layering mixup. When would -- or should -- a
communicating peer outside a mobile network need to know the IMEI or
IMEISV of a device inside a mobile network? An IMEI is used for initial
identification on a mobile network or for SIM-less emergency calls.
Under what conditions would an Internet-based peer have an IMEI in hand
and want to use it in a gsma: URN? If as you say an "Internet device"
is "interoperating" with a mobile device, it will do so using IP-based
protocols and will (should) never learn the mobile device's IMEI. I can
see cases where an outsourced management entity might want to speak to a
mobile network's administration regarding records for a particular IMEI,
but it would do so in a very secure way, not using this particular URN.'
If there is an assumption that we are going to start passing around
IMEIs as general identifiers, then I'm concerned that you are
engineering a world in which one must reveal permanent identifiers in
order to communicate.
Please enlighten me as to the intent. Right now it feels to me like it
enables us to do the wrong thing with IMEIs.'
The http://gsmworld.com/newsroom/document%2Dlibrary/ normative
reference is a 404.
It would be easier to have the draft discuss the GSMA URN only. The
alternative is to have the draft discuss the privacy considerations
of using IMEI and IMEISV.
Regards,
S. Moonesamy