Subject: RE: [Simple] XCAP List Issue 3: Name and URI indices

From: [email-masked]
Date: Fri, 18 Jun 2004 15:33:54 +0300

I'm fine with that, as long as we can provide enough text to eliminate the possibility of having the same resource twice in a list. Perhaps both a URI comparison and string comparison together need to be performed (or mandate canonicalisation).

I really don't want the same resource to end up on the list more than once causing multiple subscriptions to the same resource.

Thanks,
Hisham

> -----Original Message-----
> From: ext Jonathan Rosenberg [mailto:[email-masked]]
> Sent: 18.June.2004 15:19
> To: Khartabil Hisham (Nokia-TP-MSW/Helsinki)
> Cc: [email-masked]
> Subject: Re: [Simple] XCAP List Issue 3: Name and URI indices
> 
> 
> 
> 
> [email-masked] wrote:
> > Jonathan,
> > 
> > I don't understand why someone would want to have 2 entries with the
> > same URI (by same I mean using the URI comparison rule). Why do you
> > see it as a possible feature?
> 
> I really don't think its important. We could do it, was all I 
> was saying.
> 
> 
> > If you want it as a feature then it is
> > much simpler to use the name attribute as the key and the uri as a
> > child element of <entry>.
> > 
> > I think you have already confused people by pointing out all those
> > comparison rules, and my reaction is that we should try to avoid
> > them.
> 
> Sorry for being confusing.
> 
> The simple point is this - using the URI as an index works, 
> since case 
> sensitive string comparison is OK.
> 
> Let me point out a real world situation that relates to this topic.
> 
> Lets say you and I are both editing the resource list for the SIMPLE 
> participants. We both independently notice that robert is not on the 
> list somehow. So, you go to do an insert, and you insert thusly:
> 
> PUT http://blah-blah/entry[@uri="sip:[email-masked]"]
> 
> then, I do an insertion, but using DYNAMICSOFT.COM:
> 
> PUT http://blah-blah/entry[@uri="sip:[email-masked]"]
> 
> now, in this case, the URI are equal by URI comparison, 
> unequal by case 
> sensitive string compare. So, both get inserted.
> 
> Now, you might argue that I've just proven that we should use a name 
> attribute, since if we had a name attribute that was the same for all 
> equivalent forms of the URI, we wouldn't have this problem. 
> Thats true, 
> but, to compute such an attribute, you'd need to define a 
> function that 
> takes a URI as an input, and canonicalizes it in such a way that all 
> equivalent URI would canonicalize to the same result. For an AOR that 
> doesnt contain URI parameters (which is what we're concerned 
> about), a 
> simple toLower() on the domain part will do the job. Of 
> course, once you 
> do that, you have a way to use a URI as an index that doesnt 
> have this 
> ambiguity problem as above. So, you may as well just use that 
> resulting 
> URI as the index, and you're right back to where we started from.
> 
> *So*, I would suggest that:
> 
> -- we use the "uri" as an index
> -- we recommend canonicalizing the URI before using, per above
> 
> This has the same benefits of a separate "name" index, with the same 
> implementation cost, but with smaller data size and it avoids 
> repeating 
> information.
> 
> -Jonathan R.
> 
> -- 
> Jonathan D. Rosenberg, Ph.D.                600 Lanidex Plaza
> Chief Technology Officer                    Parsippany, NJ 07054-2711
> dynamicsoft
> [email-masked]                     FAX:   (973) 952-5050
> http://www.jdrosen.net                      PHONE: (973) 952-5000
> http://www.dynamicsoft.com
> 

_______________________________________________
Simple mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/simple

---

From: Jonathan Rosenberg <[email-masked]>
Date: Fri, 18 Jun 2004 08:40:32 -0400

[email-masked] wrote:

> I'm fine with that, as long as we can provide enough text to
> eliminate the possibility of having the same resource twice in a
> list. Perhaps both a URI comparison and string comparison together
> need to be performed (or mandate canonicalisation).

I think we should define the canonicalization, and put it at SHOULD 
strength.

> 
> I really don't want the same resource to end up on the list more than
> once causing multiple subscriptions to the same resource.

Generally, it doesnt make sense. But, there may be some reason why its 
desired. Nothing breaks if you do it, I dont think, so the 
canonicalization can be at SHOULD strength, not MUST.

-Jonathan R.

---

From: Paul Kyzivat <[email-masked]>
Date: Fri, 18 Jun 2004 10:15:09 -0400

> canonicalization can be at SHOULD strength, not MUST.

Well, its a great "feature" if the list is being used as a MESSAGE 
exploder. (Which may be a bit off topic here.)

It gives me yet another way to cheaply generate spam and/or DoS attacks, 
by hammering the same recipient many times.

	Paul

---

From: Jonathan Rosenberg <[email-masked]>
Date: Sat, 19 Jun 2004 07:04:31 -0400

inline.

> by hammering the same recipient many times.

Even if the same URI can appear only once, you might be able to hammer 
the same recipient many times by using many different URI at the same host.

If you want to prevent this attack, you need a more systematic way of 
getting authorization for message receipt, as we discussed at the 
interim. As such, I don't think this particular MUST/SHOULD decision 
really hinges at all on the exploder question.

Thanks,
Jonathan R.

---

From: Paul Kyzivat <[email-masked]>
Date: Sun, 20 Jun 2004 22:33:14 -0400

Jonathan Rosenberg wrote:
>> It gives me yet another way to cheaply generate spam and/or DoS 
>> attacks, by hammering the same recipient many times.
> 

I guess you are right, that it would be possible to get around the 
uniqueness issue by spinning variants on the same address, perhaps by 
adding a url parameter.

I wasn't intending to be entirely serious here.

	Paul

---

From: Robert Sparks <[email-masked]>
Date: Mon, 21 Jun 2004 09:27:19 -0500

We're not expecting these URIs to have parameters normally, but
is there anything that prevents them from being provided?

RjS

---

From: Paul Kyzivat <[email-masked]>
Date: Mon, 21 Jun 2004 15:17:31 -0400

> is there anything that prevents them from being provided?

Not that I can see. Some parameters may be required. And in general 
unknown parameters must be ignored. That makes bogus use of them to get 
around uniqueness hard to avoid:

	sip:[email-masked]
	sip:[email-masked];user=dialstring
	sip:[email-masked];foobar=1
	sip:[email-masked];foobar=2
	...
	sip:[email-masked];foobar=999999999

Paul

---

From: Robert Sparks <[email-masked]>
Date: Mon, 21 Jun 2004 14:53:16 -0500

Then is it sufficient to only specify the (tolower) canonicalization
on hostport as Jonathan proposed? Parameter re-ordering leads to
URI equivalence that is not bit-wise equivalence.
(sip:a@b;p1=1;p2=2 == sip:a@b;p2=2;p1=1)

Or is it sufficient to say that if you put URIs with parameters
into one of these lists, then you should expect to deal with
potential "duplicates"?

RjS

---

From: Paul Kyzivat <[email-masked]>
Date: Mon, 21 Jun 2004 18:22:59 -0400

I think I would just declare this a user problem to deal with rather 
than complicating things unnecessarily.

	Paul

---

From: Paul Kyzivat <[email-masked]>
Date: Tue, 22 Jun 2004 14:09:37 -0400

Jonathan,

I'm not understanding you. I guess you are just saying that URI 
cannonicalization is *defined* as part of registration.

And then you are suggesting it *should* be used in xcap list manip???

Maybe SHOULD is ok. But then the SHOULD will have to be ignored if the 
canonicalization removes parameters that are important (such as user=phone.)

(The cannonicalization could be a problem with REGISTER, but probably 
not in practice, since it only applies to AORs, and its hard to think of 
a case where two AORs only differ by a URI parameter.)

	Paul

Jonathan Rosenberg wrote:
> We already do URI canonicalization. Its defined in section on register 
> processing in RFC 3261:
> 
>  5. The registrar extracts the address-of-record from the To header
>          field of the request.  If the address-of-record is not valid
>          for the domain in the Request-URI, the registrar MUST send a
>          404 (Not Found) response and skip the remaining steps.  The URI
>          MUST then be converted to a canonical form.  To do that, all
>          URI parameters MUST be removed (including the user-param), and
>          any escaped characters MUST be converted to their unescaped
>          form.  The result serves as an index into the list of bindings.
> 
> 
> I still think we should say that you SHOULD basically follow this 
> canonicalization, followed by tolower() on the domain part, which would 
> then allow for case-sensitive string compare to work. This 
> canonicalization would be done by the clients.
> 
> -Jonathan R.
> 
> 
> 
> Paul Kyzivat wrote:
> 
>>>> unknown parameters must be ignored. That makes bogus use of them to 
>>>> get around uniqueness hard to avoid:
>>>>
>>>>     sip:[email-masked]
>>>>>>>> Well, its a great "feature" if the list is being used as a 
>>>>>>>> MESSAGE exploder. (Which may be a bit off topic here.)
>>>>>>>>
>>>>>>> Even if the same URI can appear only once, you might be able to 
>>>>>>> hammer the same recipient many times by using many different URI 
>>>>>>> at the same host.
>>>>>>>
>>>>>>> If you want to prevent this attack, you need a more systematic 
>>>>>>> way of getting authorization for message receipt, as we discussed 
>>>>>>> at the interim. As such, I don't think this particular 
>>>>>>> MUST/SHOULD decision really hinges at all on the exploder question.
>>>>>>
>>>>>>
>>>>>>
>>>>>> uniqueness issue by spinning variants on the same address, perhaps 
>>>>>> by adding a url parameter.
>>>>>>

---

From: Jonathan Rosenberg <[email-masked]>
Date: Tue, 22 Jun 2004 13:09:56 -0400

-Jonathan R.

Paul Kyzivat wrote:

>>>>>> If you want to prevent this attack, you need a more systematic way 
>>>>>> of getting authorization for message receipt, as we discussed at 
>>>>>> the interim. As such, I don't think this particular MUST/SHOULD 
>>>>>> decision really hinges at all on the exploder question.
>>>>>
>>>>>

---

From: Jonathan Rosenberg <[email-masked]>
Date: Wed, 23 Jun 2004 11:16:23 -0400

> cannonicalization is *defined* as part of registration.

All I was saying is that we have already defined URI canonicalization as 
part of registration, and that I was suggesting that a client SHOULD 
follow those procedures, along with a tolower() on the domain, when it 
constructs a new entry to be added to a list stored on the server.

> And then you are suggesting it *should* be used in xcap list manip???

Yes.

> canonicalization removes parameters that are important (such as 

I suppose, see below.

> a case where two AORs only differ by a URI parameter.)

Right, and my assumption was that the URI that goes into each entry in 
the list would also be an aor, and thus I'm not sure when the inclusion 
of a user=phone would be important to the server processing the request 
for that AOR.

-Jonathan R.