Re: Should (some of the) ContactField objects use URLs rather than free-form strings?

On Jun 6, 2011, at 09:46 , Dominique Hazael-Massieux wrote:
> Le mercredi 01 juin 2011 à 23:27 +0200, Robin Berjon a écrit :
>> I know that adding a |uri| attribute that is only present when the URI
>> could be correctly inferred addresses that part. But it's still a
>> problem. It means that we need to specify the heuristics — for they
>> will be heuristics in some cases — that map from possibly arbitrary
>> values to URIs.
> 
> I guess you're right we would have to define those; I think the work is
> minimalistic for photos and urls, and probably for emails. The algorithm
> would be:
> * parse the URL as defined in HTML5
> http://dev.w3.org/html5/spec/urls.html#parsing-urls
> * if the parsing fails, abort
> * otherwise, stick the value in the uri attribute

I could live with that, provided someone is willing to do the work promptly. We have been planning to go to LC and I'd rather not derail the schedule by too much — especially if we are to process LC feedback during our f2f (which would be nice). Hence my pushing back on what seems largely a non-blocker.

If we proceed with this, I'd also like it to be flagged as at-risk.

>> I'm not saying it's necessarily huge work, but it's extra stuff. And
>> we also need to require that implementations validate those URIs. In
>> some cases, that's more of a burden than meets the eye.
> 
> Do you have anything specific in mind?

I was thinking of the tel: scheme, which is more complex than one would guess without having read the RFC, as well as of mailto: for which the "to" component is pretty much as complex as the huge amount of cruft that can appear in an email's To: header. Slapping a mailto: in front of whatever the user entered in the email field may yield something that parses correctly as per HTML5's URI parsing, but really isn't what was intended.

>>> It seems to me that these concerns don't apply to emails, photos, and
>>> urls (!).
>> 
>> For photos I think it's an easy win. The current draft has Base64 or
>> URI. We could just have URI, indicating that if it's Base64 it can be
>> a data: URI (and it could also be a blob: URI).
> 
> Photos are clearly my #1 request; having a field that can have both URLs
> and binary-encoded-data-but-not-a-data-URL seems like non-sense.

For photos I certainly agree that it's a bug in the spec to have the two variants that we currently have.

>> With email, what's the value of getting mailto:foo@bar.com over
>> foo@bar.com? The extra processing required to ensure that the former
>> is valid in the face of user error seems a high price to pay to me.
> 
> Well, it seems to me that this price has to be paid sooner or later if
> these fields are going to be used; the number of usage of email
> addresses that doesn't include linking (or sending a message via our
> beautiful Messaging API) seems limited.

As indicated above I can live with adding this for emails, but I have misgivings that this is a last-minute addition for a non-blocking feature. I'd feel a lot more comfortable having this in v1.1. Or deciding that we're delaying our LC schedule enough to think about the problems this could raise (which I'd rather not do).

>> All in all, given that it can be handled in script with minimal
>> trouble, I think that we should change photos and keep the rest as is.
> 
> I can live with that solution as long as photos is fixed. I guess we
> could always add the URL processing to a later version if needed; I'm
> hoping we're not under-delivering, though.

I don't think that we are — it's the first that I hear this use case, and I'm pretty sure that if we take on this issue with the cool it requires we can find a way of handling tel: correctly and perhaps even IM. Outside photo, I get the feeling that this is a rushed change.

-- 
Robin Berjon - http://berjon.com/ - @robinberjon

Received on Wednesday, 8 June 2011 12:27:30 UTC