Subject: Re: [dispatch] Deriving URI from MAC-based URN ???

From: "Worley, Dale R (Dale)" <[email-masked]>
Date: Mon, 7 Nov 2011 18:10:50 -0500

> From: Cullen Jennings [[email-masked]]
> 
> agree on that's config but even so, typically you want the BLF
> subscribed to AOR that is the same as the phones registers for. Hard
> to see how a MAC gets involved with BLF unless you have a really
> broken confusion between users and devices.

The critical question is "What do you want the status of?"

In the ordinary case, you want the status for extension 123, that is,
are there any calls active to/from user name 123.  In that case, you
want to (directly or, in practice, as part of a resource list)
subscribe to the dialog events for sip:[email-masked].

But in the boss/assistant setup, that doesn't give the desired effect.
Someone calls 123 (the boss' number), it rings on the assistant's
phone, and the assistant picks it up.  At this point, the assistant
would like to know if the boss is on the phone, looks at the BLF light
for 123, and, yes indeed, 123 is busy.  Unfortunately, it is
guaranteed to be busy because the assistant is holding the call to the
boss right now.

So what you want is to be able to subscribe to the dialog events for a
particular user name *for a particular telephone instrument*.  And
once you frame the problem that way, it's simple enough to define a
special series of user names that map into the contacts for a
particular extension and a particular telephone instrument.  In our
system, for example, you can subscribe to
sip:[email-masked], which is the status of the
appearance of extension 123 on instrument 00041324036c.

Dale

---

From: "Olle E. Johansson" <[email-masked]>
Date: Tue, 8 Nov 2011 08:45:55 +0100

> appearance of extension 123 on instrument 00041324036c.

Am I stupid if I say "GRUU" here?
Isn't that a device identifier and not an account identifier?

/O

---

From: "Worley, Dale R (Dale)" <[email-masked]>
Date: Tue, 8 Nov 2011 10:15:31 -0500

> From: Olle E. Johansson [[email-masked]]
> 

A GRUU would also suffice, if you could predict it when you
provisioned the phone.  Or one could say that this sort of URI is a
type of GRUU.  In reality, the system in question implements and
handles these URIs separately, and we haven't spent the time to think
through whether they can be usefully integrated.

In any of these cases, they are identifiers for pairs "username and
device", not device identifiers.

Dale

---

From: "Worley, Dale R (Dale)" <[email-masked]>
Date: Tue, 8 Nov 2011 15:06:48 -0500

> Am I stupid if I say "GRUU" here?

Now I recall why GRUUs don't work:  Some of the common phones that
were used with the system (not Avaya phones) did not provide a
+sip.instance, so they didn't get GRUUs.

Our cheat was to smuggle the character representation of the phone's
MAC address as part of the "authorization user" in the phone's
configuration.  The registrar would pick the MAC address out of the
Authorization header in the phone's REGISTER request and store that in
the registration entry to enable the ~~in URI.

Dale

---

From: "Worley, Dale R (Dale)" <[email-masked]>
Date: Wed, 9 Nov 2011 17:35:59 -0500

> From: Adam Roach [[email-masked]]
> 
> In the spirit of "send text," I would propose extending the first
> paragraph of the "Security Considerations" section in
> draft-montemurro-gsma-imei-uri by adding:
> 
>      Further, because IMEIs can generally be correlated to a user,
>      they should be treated as any other personally identifiable
>      information. In particular, the IMEI SHOULD NOT be included in
>      messages intended to convey any level of anonymity.
>      Further, because IMEIs can loosely be correlated to a user,
>      they should be treated as any other personally identifiable
>      information. In particular, the IMEI SHOULD NOT be included in
>      messages intended to convey any level of anonymity.

Though this text preserves the illusion that IMEI-based instance-ids
are somehow more privacy-invasive than other types of instance-id.
Whereas an instance-id *must* be correlated to a UA (and thus a user)
to be of any use.  So we should replace "IMEI" with "instance-id" in
the above paragraph.

> The other major outstanding issue is interoperability. The main issue, I
> believe, is whether you will end up with systems that only accept IMEI
> URNs when use of the protocol in a broader context requires the use of
> general URNs or even URIs.
> 
> The "Community considerations" section of draft-montemurro-gsma-imei-uri
> currently deals exclusively with the ability for general-purpose
> Internet implementations to deal with 3GPP-specific identifiers. We need
> text that addresses the complementary issue of 3GPP implementations
> dealing with general-purpose Internet identifiers.
> 
> I would propose adding text to the end of this section, along the lines of:
> 
>      Conversely, Internet implementations will not generally posses
>      IMEI identifiers. The identifiers generated by such implementations
>      will typically be URNs within namespaces other than "gsma," and
>      may, depending on context, even be non-URN URIs. Implementations
>      are advised to correctly process URIs other than "gsma"-namespaced
>      URNs, so as to aid in interoperability.

That makes sense, but I'm curious about the umbrella statement under
which the "community considerations" are written:

   Many of these protocols require the use of URN's as identifiers.

I don't know of *any* end-to-end protocols that require the use of
URN's as identifiers, with the sole exception of SIP registration.
Does anyone have any other examples?

Dale

---

From: Adam Roach <[email-masked]>
Date: Thu, 10 Nov 2011 17:00:04 -0600

On 11/9/11 4:35 PM, Worley, Dale R (Dale) wrote:
>> ...

If you'd like, sure. But there's a reason it's coming up now and didn't 
before.

In the past, I don't think anyone would have ever dreamed of sending an 
instance ID in an INVITE request. They're used for outbound and GRUU, 
and only appear in REGISTER messages.

What happened here is that Ricky Kaura's message of February 2nd, 2011 
made it clear that 3GPP has specified the unprecedented and 
unanticipated inclusion of instance IDs in INVITE. This inclusion has 
some potentially chilling privacy implications, and I haven't seen any 
treatment of them anywhere. (I also think this behavior is a bit of an 
overreach on the part of 3GPP, as it defines new protocol semantics for 
SIP message components, but I'm not going to get too bent out of shape 
over that particular jurisdictional transgression).

This kind of transmission was never supposed to happen. It simply didn't 
make any kind of sense. So it never occurred to anyone to discuss the 
privacy implications of doing so.

Now that it has become clear that such transmission will be inherent in 
some uses of the URNs that these drafts propose, I think it would be 
irresponsible to omit a discussion of the privacy properties of these 
identifiers.

/a