Subject: [stir] Anonymity (was Re: Early Homework (was Re: Moving from BOF to))

From: "Anton Tveretin" <[email-masked]>
Date: Tue, 13 Aug 2013 22:42:48 +0600

I would point out that in addition to anonymous calls, there are "unknown".
Ideally, when a caller or another party (forwarder, answerer, tranferred-to) 
wants to be anonymous (i.e. hide his/her AOR), s/he will be. Otherwise, 
his/her AOR is delivered to other parties. In practice, this may be just 
impossible, as with SS5 links (they still exist), or address space mismatch 
(see my previous post for an example: e-mail-style addresses are not 
supported in SS7). I call them "unknown".
I think both cases (anonymous and unknown) have nothing common with STIR; we 
want to assert identity of those who also want it.
BTW, sip:[email-masked] seems to be de facto standard. What's 
about sip:[email-masked] or whatever?

---

From: Hadriel Kaplan <[email-masked]>
Date: Tue, 13 Aug 2013 15:50:38 -0400

On Aug 13, 2013, at 12:42 PM, Anton Tveretin <[email-masked]> wrote:

> Ideally, when a caller or another party (forwarder, answerer, tranferred-to) wants to be anonymous (i.e. hide his/her AOR), s/he will be. Otherwise, his/her AOR is delivered to other parties. In practice, this may be just impossible, as with SS5 links (they still exist), or address space mismatch (see my previous post for an example: e-mail-style addresses are not supported in SS7). I call them "unknown".
> I think both cases (anonymous and unknown) have nothing common with STIR; we want to assert identity of those who also want it.
> BTW, sip:[email-masked] seems to be de facto standard. What's about sip:[email-masked] or whatever? 

'sip:[email-masked]' is not just a defacto - it's in the original RFC that way.  See here:
http://tools.ietf.org/html/rfc3323#section-4.1.1.3

As you point out, there is a subtle difference between 'anonymous' and 'unknown' - in that there's a difference between user-presented caller-id display saying "blocked" vs. "unknown".  Some devices today do use "sip:[email-masked]", and it's even documented to be used in RFC 6044, ETSI, and 3GPP for History-Info placeholder cases.  But it's never been truly specified anywhere as meaning anything special in a From URI, as far as I know.

-hadriel

---

From: Paul Kyzivat <[email-masked]>
Date: Tue, 13 Aug 2013 23:28:18 +0200

On 8/13/13 9:50 PM, Hadriel Kaplan wrote:

> Some devices today do use "sip:[email-masked]", and it's even documented to be used in RFC 6044, ETSI, and 3GPP for History-Info placeholder cases.  But it's never been truly specified anywhere as meaning anything special in a From URI, as far as I know.

Anything in the "invalid" TLD is "interesting".

AFAIK this is not a valid TLD (duh). But that means it isn't possible to 
register any subdomains of it. So what is the justification for calling 
out a particular subdomain, and user within that subdomain, to have 
particular semantics?

And its vaguely possible (though unlikely) that ICANN would make 
"invalid" a valid TLD.

Perhaps "invalid" and anonymous.invalid need to be properly registered, 
much as example.com and example.org are, so that the assignment and use 
of subdomains can be controlled.

Meanwhile, ISTM that any URL with "invalid" as its TLD should be 
considered to be an indication of intent to provide an unreachable address.

	Thanks,
	Paul

---

From: Hadriel Kaplan <[email-masked]>
Date: Tue, 13 Aug 2013 17:55:39 -0400

On Aug 13, 2013, at 5:28 PM, Paul Kyzivat <[email-masked]> wrote:

> AFAIK this is not a valid TLD (duh). But that means it isn't possible to register any subdomains of it. So what is the justification for calling out a particular subdomain, and user within that subdomain, to have particular semantics?
> 
> And its vaguely possible (though unlikely) that ICANN would make "invalid" a valid TLD.

'invalid' is a reserved domain name by IANA, in both RFC 2606 and 6761, and in IANA's registry here:
http://www.iana.org/assignments/special-use-domain-names

> Perhaps "invalid" and anonymous.invalid need to be properly registered, much as example.com and example.org are, so that the assignment and use of subdomains can be controlled.

Right, that's basically the question.  It seems weird to register subdomains for something that has a semantic of being invalid, but maybe it should be done.

-hadriel

---

From: "Peterson, Jon" <[email-masked]>
Date: Tue, 13 Aug 2013 22:06:57 +0000

Our understanding at the time we did RFC3323 was that there was no need to
register sudomains under the .invalid TLD. We supplied a subdomain to be
generous to simple SIP URI parsers and avoid ambiguity (as the recent IAB
statement on TLDs-as-domain-names affirms). Probably we could just as
easily have chosen sip:invalid, but when a UI rendered the URI to the
recipient we wanted it be clear that anonymity had been explicitly
asserted. 

For .com and .org, it was necessary to reserve the second level name
"example" because otherwise it could be assigned; there is no similar risk
for anything under .invalid, as nothing under the TLD can be assigned or
resolved.

Jon Peterson
Neustar, Inc.

On 8/13/13 2:55 PM, "Hadriel Kaplan" <[email-masked]> wrote:

>>> Some devices today do use "sip:[email-masked]", and it's even
>>>documented to be used in RFC 6044, ETSI, and 3GPP for History-Info
>>>placeholder cases.  But it's never been truly specified anywhere as
>>>meaning anything special in a From URI, as far as I know.
>> 
>> AFAIK this is not a valid TLD (duh). But that means it isn't possible
>>to register any subdomains of it. So what is the justification for
>>calling out a particular subdomain, and user within that subdomain, to
>>have particular semantics?
>> 
>Right, that's basically the question.  It seems weird to register
>subdomains for something that has a semantic of being invalid, but maybe
>it should be done.
>
>-hadriel
>
>_______________________________________________
>stir mailing list
>[email-masked]
>https://www.ietf.org/mailman/listinfo/stir

---

From: Hadriel Kaplan <[email-masked]>
Date: Tue, 13 Aug 2013 18:23:31 -0400

Oh I'm not claiming we *have* to register it, because clearly we don't - just sayin' we might *want* to.
:)

I.e., if we ever want to make a distinction between 'anonymous' and 'unknown', for display purposes for example.

-hadriel

---

From: Paul Kyzivat <[email-masked]>
Date: Wed, 14 Aug 2013 00:43:04 +0200

I didn't know about 6761 and its discussion of "invalid". Live and 
learn. That at least will prevent ICANN from assigning it to somebody.

> I.e., if we ever want to make a distinction between 'anonymous' and 'unknown', for display purposes for example.

If we want to ascribe specific meaning to a particular derivative of 
"invalid" then there ought to be some place to stake a claim to that, so 
it isn't used for something different.

Ideally one could use whois to identify the owner. That works for 
example.com and example.org - it shows up as owned by IANA. But 6761 
prevents registrars from accepting "normal" registrations under "invalid".

But this is all a nit.

	Thanks,
	Paul

---

From: "Peterson, Jon" <[email-masked]>
Date: Tue, 13 Aug 2013 23:36:25 +0000

I'm not sure I see any real risk of code point collision or something in
using anonymous.invalid as a domain name such that we need a registry or
IANA procedure.

I do however agree that the anonymous URI defined in RFC3323 applies to a
case where the caller intends to be anonymous, not to a case where the
caller's identity is simply unknown by the system, perhaps because the
call came from a gateway where the protocol on the other side supplied no
identity. Certainly an RFC3323 anonymous URI would not be appropriate for
that case. But what is? Maybe the "unknown" From that Hadriel pointed to.

Jon Peterson
Neustar, Inc.

On 8/13/13 3:43 PM, "Paul Kyzivat" <[email-masked]> wrote:

>> I.e., if we ever want to make a distinction between 'anonymous' and
>>'unknown', for display purposes for example.
>
>>>> 'invalid' is a reserved domain name by IANA, in both RFC 2606 and
>>>>6761,
>>>> and in IANA's registry here:

---

From: Paul Kyzivat <[email-masked]>
Date: Wed, 14 Aug 2013 02:02:53 +0200

> using anonymous.invalid as a domain name such that we need a registry or

I'm wearing my obsessive-compulsive hat here.
I realize there isn't a big risk of this being used for something 
conflicting.

But the more special significance we assign to this the more we should 
be concerned that people encountering this usage can *discover* what it 
means. (As hard as it may be for people here to understand, not 
everybody doing sip has read every sip-related RFC. I've read most of 
them, but I didn't know about 6761.)

I have never been too concerned about the usage in 3261. (Though if i 
were doing it over I would probably try to fix it.) But there is is 
really sufficient that the address not be resolvable. Any address that 
was guaranteed not to be resolvable would have been sufficient.

Maybe that is true here too. But if we want to say users should get one 
sort of callerid for sip:[email-masked], and a different 
sort of callerid for other unresolvable From addresses, and yet a 
different sort of callerid for tel URIs that aren't signed, then it gets 
more important.

	Thanks,
	Paul