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

From: [email-masked]
Date: Fri, 18 Jun 2004 11:23:40 +0300

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? 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.

/Hisham

> -----Original Message-----
> From: [email-masked] 
> [mailto:[email-masked]]On Behalf
> Of ext Jonathan Rosenberg
> Sent: 17.June.2004 13:18
> To: Jonathan Rosenberg
> Cc: Simple WG
> Subject: Re: [Simple] XCAP List Issue 3: Name and URI indices
> 
> 
> No comments on this?
> 
> -Jonathan R.
> 
> Jonathan Rosenberg wrote:
> 
> > Currently, the resource list format has two attributes for 
> each <entry>. 
> > The are the optional name, and mandatory URI parameter. The 
> name exists 
> > solely as an alternative index useful for XCAP selection of 
> entries. 
> > However, do we really need TWO indices?
> > 
> > The main concern around using the URI as an index is that URI 
> > comparisons are more compelx than just string match, and if 
> we use the 
> > URI as an index for XCAP selection, the element would be 
> selected based 
> > on string equality (case sensitive, I believe). However, 
> its possible 
> > for two URI to be unequal by case sensitive string 
> comparison, and equal 
> > by URI equality. More interestingly, I think it is the case 
> that if two 
> > URI are equal by case sensitive string compare, then they 
> will also be 
> > equal by URI comparison rules. The implication is that I 
> will always be 
> > able to select the entry I want (i.e., there won't be 
> ambiguity), but 
> > the XCAP rules may allow me to have two entries that have 
> the same URI 
> > by URi equality rules, just because they differ by case 
> sensitive string 
> > comparison.
> > 
> > I don't think thats a particularly bad limitation (indeed, 
> one might 
> > even argue that its a feature). As such, I'd propose to 
> drop the name 
> > attribute entirely.
> > 
> > Note that the specification does need to also clarify that 
> each <entry> 
> > has to have a unique uri attribute amongst its siblings. It 
> doesnt say 
> > that now. This means that the server will reject, with a 
> 409, a request 
> > to add an <entry> if its uri attribute is not unique.
> > 
> > -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
> 

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

---

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

[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.