[Bug 26866] add support for requesting handles for a vCard field or URI

[bugzilla-daemon at freedesktop.org]

https://bugs.freedesktop.org/show_bug.cgi?id=26866

--- Comment #46 from Eitan Isaacson <eitan.isaacson at collabora.co.uk> 2010-09-03 13:38:36 PDT ---
Pushed to:
http://git.collabora.co.uk/?p=user/eitan/telepathy-spec.git;a=shortlog;h=refs/heads/vcard-field-requests

Uploaded HTML to:
http://people.freedesktop.org/~eitani/telepathy-spec-vcard_field_requests/spec/

(In reply to comment #42)
> This branch adds stable (i.e. guaranteed) API, so it can't easily be merged as
> a draft. I think it'd be worth moving TargetURI, TargetURIScheme,
> TargetVCardField and TargetVCardAddress to a new Chan.I.Addressing which can be
> merged as a draft (we can consider flattening them into Channel in Telepathy
> 1.0), and moving the Protocol stuff to a Protocol.I.Addressing (ditto).
> 

I guess they could be separate interfaces. My concern is that CMs need to be
consistent about implementing Chan.I.Addressing for every channel that has a
target contact, or it will get confusing (for example, the iface would appear
in channels requested through TargetURI, but not when through TargetID).

> Alternatively, if you feel strongly that the new stuff should be a core part of
> Telepathy as soon as it's undrafted, put it on Channel.FUTURE and
> Protocol.FUTURE pseudo-interfaces.
> 

I don't feel too strongly about that. Just slightly concerned above. I'll defer
to your judgement, and make them distinct interfaces.

Done in 90795fb and 5a417c4

> TargetURIScheme exactly duplicates part of TargetURI, so it deserves a
> <tp:rationale> explaining that yes, it really is duplicate information, and it
> exists to be available in requestable channel classes. TargetURI and
> TargetURIScheme should probably reference each other (or perhaps only in one
> direction) to say that TargetURI MUST start with TargetURIScheme + ":".
> 

b06967c

> Protocol.NormalizeVCardAddress should document what happens if the VCard_Field
> is not in AddressableVCardFields, and what happens if the VCard_Address is not
> a syntactically valid instance of that vCard field.
> 
> (My opinion: InvalidArgument or NotImplemented for the former, InvalidHandle
> (stretching its meaning rather) or InvalidArgument for the latter.)
> 
> Likewise for NormalizeURI.
> 

5cc1f2b

> NormalizeURI seems to have incorrect argument names/types, referring to vCard
> addresses.

b016407

> 
> > +          The URI to normalize. The URI's scheme must appear in
> 
> It might be worth repeating "scheme (i.e. the part before the first colon)"
> here?
> 

5cc1f2b

> The copyright notice in Chan.I.Addressing needs stretching to include 2010.
> 

ba56944


> > +          The URI addresses to get contact handles for. The URI
> > +          schemes need to be supported by the connection, this could
> > +          be determined by inspecting the TargetURIScheme
> > +          fixed-property on
> > +          [...]Requests.RequestableChannelClasses</tp:dbus-ref>.
> 
> No, I think this should be from the Protocol: the requestable channel classes
> are unnecessarily strict. A telepathy-sofiasip instance whose server lacks a
> PSTN gateway can still discuss, and allocate handles for, tel: URIs, even if it
> can't actually call them.

dab41e3

> 
> /requested-address and /requested-uri need well-defined semantics (I propose
> "MUST be omitted from the mapping") when not requested via the relevant method.
> 

e21a532

> > If the <code>URL</code> vCard
> > +          field is addressable, a colon, followed by the supported URI
> > +          schemes will be concatenated.</p>
> > +
> > +          <p>For example: <code>["tel", "x-sip", "url:tel", [...]
> 
> I thought we agreed this was a bad idea? If so, please eradicate this mention
> of "url:"-prefixed pseudo-fields, 

db93862

> and replace it with something like:
> 
>     The <code>url</code> vCard field MUST NOT appear here; see
>     _AddressableURISchemes_ instead.
> 
>     | In practice, protocols have a limited set of URI schemes that make
>     | sense to resolve as a contact.
> 
> GetContactsByVCardAddress and TargetVCardField should probably gain a similar
> note, pointing users to the appropriate URI-based alternative.
> 

52a4101

> > Do you think using a url: prefix is a bad idea everywhere we expect a vcard
> > field? Or just that we should use uri: instead?
> 
> For the record: if we'd gone this way, "uri" would be bad, since the vCard
> field name is "URL" with an L.

-- 
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the QA contact for the bug.