[Bug 13351] Forwarding spec

[bugzilla-daemon at freedesktop.org]

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

--- Comment #18 from Simon McVittie <simon.mcvittie at collabora.co.uk> 2010-05-10 05:33:08 PDT ---
Editorial changes, none of which are merge blockers:

I'd like blank lines between <p> in future.

> +      <p>In other cases, the CM will handling the forwarding itself.  When an

"will handle the"

> +        forwarding entries in the list).</p> 

Trailing whitespace

> +            <tp:type>Connection_Presence_Type</tp:type>?).</p>

I'd omit the question mark here.

> +          The contact to forward an incoming channel to.  If the handle
> +          is invalid, the entry SHOULD be skipped.

Invalid handles are always considered to be programmer error (the client should
be holding the handle), so I think instead of this wording, SetForwardingHandle
should be allowed to raise InvalidHandle.

As an implementation detail, the Connection must hold a reference to each
handle mentioned in the current forwarding details.

It would be OK to have similar wording saying that entries with a handle that
is valid, but turns out not to point to anything (e.g. a phone number that
doesn't exist), are skipped.

> +            behavior), the CM MUST raise multiple <tp:member-ref>ForwardingRuleChanged</tp:member-ref>

"MUST emit multiple". Exceptions are raised, but signals are emitted.

> +            been changed (ie, Unconditional automatically modifies

"e.g. if Unconditional..."

> +          <p>Each forwarding condition will occur exactly once or less in

"occur no more than once"

> +          <tp:docstring>
> +            A Handle that has been supplied is invalid.

This doesn't necessarily mean handle 0; it could mean handle 31337 where the CM
has only allocated handles from 1 up to 666, for instance.

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