RE: I18N-ISSUE-65: find() method case sensitivity [Contacts API]

Philip wrote:
> I'm puzzled -- the contents of the filter field seems undefined
> (syntactically), with the only example being 'Bob'.

> There is a note that
> indicates that this field is to be interpreted by the contact list
> provider, but this seems sufficiently vague as to be useless.


> It isn't clear that I (as a web application author) can find out which
> implementation of a contact list provider is present.

Would it be helpful for us to make it explicit that you *cannot* find out which contact list providers are present?

I'd support adding a statement to that effect.

> Without this information, I'm not going to be able to produce the
> correct form of the search filter string.

If there are 20 providers and you provide a search filter string, you are not going to be able to provide a filter string which works for all of them if you assume that you can specially craft it for one of them. Just provide a basic filter of the things you'd like to get.

Again, I'd be glad to propose text to spell this out to consumers.

> [Compare this with browser implementations where they identify
> themselves carefully so that I can build/use (admittedly ugly) cross
> browser libraries.

No, we do not want people writing:
If (IE) { do_ie_stuff() }
Else if (Safari) { do_safari_stuff() }
Else if (Firefox) { do_firefox_stuff() }

That leads to all other user agents breaking because the code doesn't write to the unexpected case of some other provider/agent.

> I realize that the goal of this work is to eliminate (in theory) the
> requirement for cross browser libraries, but that is why it is
> important to be clear on the syntax and semantics of external APIs]

The requirements are:
* the consumer can ask for things which match some filter
* the provider can provide anything it likes, but is encouraged to provide things which match

Note that if you search for "Joshua" and I don't have any cards for "Joshua", but my user wants to send a card for "Josh", then I, as a user agent will gladly send the card for "Josh", because that's in fact that card that my user wants to send, and clearly you want to accept it because you're supposed to be acting on behalf of my user too.

Again, if you'd like us to spell out this example, I'll be glad to provide text to that effect.

> In particular, would you expect "bob jones" as a filter to match "Bobby
> J Jones" (split into individual fields as appropriate)?

I think it's likely that it would, but we're not going to guarantee that it will.

> How about "Jones's Greek Kabob House"?

If there are no matches for Bobby Jones, and the user knows that Bobby Jones owns "Jones's Greek Kabob House" and in fact wants to give that card to your application, then yes, I think it's reasonable to accept that if the user picks that contact card, it will be given to you.

But no, it isn't likely to be given to you automatically.

> If you can't say, then I think that the specification has failed as
> every web author will have to implement their own filtering

If you ask for "*", you will probably get a pissed user and 10 contacts.

My phone has 1000 contacts, and there's no way that I'm going to tolerate 100 requests for contacts or be able to select 100 consecutive runs of 10 contacts.

Note that "10" is merely an arbitrary limit that isn't in any specification, a client could give you all 1000, but it's free to suggest to the user that on average they're being attacked by a phishing thief and should only give out some select handful of contacts which make sense.

For other cases, it's definitely possible for a UA to be unable to provide all possible contacts due to resource constraints (100,000 employees would kill your average mobile device), note that such constraints are an implied part of any API and are not to my understanding generally documented.

> -- and it isn't clear that a web application can retrieve the entire
> contacts list anyway due to underlying provider constraints.

Indeed, there is no guarantee that an application or the user agent can retrieve such a list. We can certainly add a note reminding consumers of this.

If a user works for a company with 100,000 employees (Cisco seems to have 70k), then it's possible that a UA can't possibly get that full list, and it's in fact likely that the user will not ever want to give it to an application.

OTOH, it's probably part of an LDAP service to which I have access, so if an application on behalf of the user (you) asks for "Phil", the user (you) might be willing to give it your own contact card.

> Think about LDAP based address books (or are these out of
> scope?)

No, they're well within scope. The API allows for a filter, and it allows for the user to provide any contacts the user chooses, whether or not they match the filter. Whether any API implementers are nice enough to do this remains to be seen, but I'm hopeful.

Ideally the effective result of a search will be best effort. So if you over-specify a name, since if there are no matches and the user sees what you're trying to search for, the user is likely to be able to make a correction until the result that you are seeking on behalf of the user is met and thus returned.

---------------------------------------------------------------------
This transmission (including any attachments) may contain confidential information, privileged material (including material protected by the solicitor-client or other applicable privileges), or constitute non-public information. Any use of this information by anyone other than the intended recipient is prohibited. If you have received this transmission in error, please immediately reply to the sender and delete this information from your system. Use, dissemination, distribution, or reproduction of this transmission by unintended recipients is not authorized and may be unlawful.

Received on Tuesday, 5 July 2011 19:34:44 UTC