[Standards] Rayo feedback.

Dave Cridland dave at cridland.net
Wed Sep 2 15:55:26 UTC 2015


(Matthew Miller prodded me that I hadn't replied to this).

On 18 August 2015 at 12:39, Ben Langfeld <ben at langfeld.me> wrote:

> On 18 August 2015 at 08:13, Dave Cridland <dave at cridland.net> wrote:
>
>>
>>
>> On 17 August 2015 at 20:15, Ben Langfeld <ben at langfeld.me> wrote:
>>
>>>
>>>
>>> On 17 August 2015 at 13:44, Kevin Smith <kevin.smith at isode.com> wrote:
>>>
>>>> On 14 Aug 2015, at 20:11, Ben Langfeld <ben at langfeld.me> wrote:
>>>> > > 2) 5.1 (Actors) places requirements that these JIDs for
>>>> components/mixers can only be only be under subdomains - why is this?
>>>> AFAIK, this is the only part of XMPP that implies any relationship between
>>>> a domain and a subdomain, and it doesn’t immediately seem like a useful
>>>> restriction.
>>>> > >
>>>> > > Not true. The word I used was "perhaps". This is simply to point
>>>> out that full JIDs must be used to address these entities and no
>>>> relationship between domains may be assumed.
>>>> >
>>>> > I think that at least the table in 5.2 is quite explicit in requiring
>>>> things to be a subdomain - I take it this wasn’t intended.
>>>> >
>>>> > Actually quite the opposite:
>>>> >
>>>> > > where elements in square brackets are optional
>>>> >
>>>> > <call ID>@[<call sub-domain>.]<service domain>/<component ID>
>>>> >
>>>> > Quite explicitly optional, I'd say.
>>>>
>>>> Sorry, badly expressed. It is optional that it’s a *sub*domain, yes.
>>>> But if it’s not the service domain, you’re requiring it to be a subdomain
>>>> of the service domain. This is what I was calling out - this is a unique
>>>> requirement in XMPP; there’s usually no formal relationship between
>>>> different domains like this, and it’s not clear to me that one is needed
>>>> here.
>>>>
>>>>
>> I'd like to see the answer to this one. Given a server of
>> shakespeare.lit, do I understand that a call must be within either that
>> domain or a subdomain of it?
>>
>
> I guess that's what this implies. I have yet to hear why it's a bad thing
> though.
>

Because nothing else relies on this relationship in XMPP. Domain names -
whether "subdomains" or not - do not have any relationship, implied or
otherwise.

So in order to mandate this, you really need to come up with an
overwhelming reason why this specification should require this, unlike
every other XMPP specification.


>
>
>> >  > 5) 6.1 - if you want to rely on presence here, isn’t an unavailable
>>>> presence the best way to signal unavailability? I don’t think it’s covered
>>>> what receiving unavailable would mean here at the moment.
>>>> > >
>>>> > > See above.
>>>> >
>>>> > I think at least the second part of the question stands - what does
>>>> receiving unavailable mean?
>>>> >
>>>> > Means that the client has gone offline and will not interact with the
>>>> calls under its control any more. The Rayo server may choose to hang up
>>>> those calls, wait for the client to come back, or any other
>>>> implementation-specific behaviour.
>>>>
>>>> It seems worth mentioning this, to me.
>>>>
>>>> > > 8) 6.2.1 How does the client discover the available URI schemes for
>>>> to/from?
>>>> > >
>>>> > > No such discovery is specified, and it is assumed that a Rayo
>>>> service would document this.
>>>> >
>>>> > It’s not clear to me what this means for interoperability. Does it
>>>> mean that one can’t implement a Rayo client using this XEP and expect it to
>>>> interoperate with an arbitrary Rayo service, because it won’t know what the
>>>> available URI schemes are?
>>>> >
>>>> > Even if this were available via Disco, it would make no difference.
>>>> You couldn't build your app to compensate. I think
>>>> per-implementation/service documentation is sufficient here.
>>>>
>>>> Doesn’t that mean that one can’t implement a Rayo client without
>>>> reference to per-server documentation?
>>>>
>>>
>>> One could certainly implement a client library/framework, and we have
>>> done. When one builds / deploys an application, however, one must know
>>> something about the server implementation. I maintain, though, that Disco
>>> as documentation is no better than normal documentation. I'd love to hear
>>> your argument for Disco being useful here, but it sounds like we're just
>>> trying to tick a "haz Disco" checkbox for no reason.
>>>
>>>
>>
>> I'd expect a generically built client to be possible, and I would expect
>> a baseline that ensured it did the basics if at all possible.
>>
>
> I think the best we could do right now is "must support sip:". But then
> someone will come along and say "what about Jingle?". Then we'll have a
> fight over it where the IVR implementations don't give a crap about Jingle
> and the XSF demands support for it and doesn't care about SIP
> and...deadlock.
>
>

I've no objection to stipulating a baseline of SIP if that's what the
market needs.


> If this isn't possible, I'd like to know why not - I've only seen this
>> with Jingle video calling in the past due to the intersection of deployment
>> and patents.
>>
>> I would have thought that some mechanism for discovering what URI schemes
>> were possible would be both possible and useful.
>>
>
> Possible, sure. Useful...for what?
>

Since otherwise it's not clear when you get a client that it'll work (or
not) with your server.


>
>
>> > > 10) 6.2.1.1 Use of presence for sending of notifications like this
>>>> seems off. I realise this boat may have sailed, but it doesn’t seem right
>>>> to me.
>>>> > >
>>>> > > We had this discussion during the Last Call, and the only
>>>> alternative that was presented was a dependency on PubSub, against which I
>>>> believe I presented a solid argument previously.
>>>> >
>>>> > I’m not exactly ignoring this comment, but I don’t have a sensible
>>>> reply either.
>>>> >
>>>> > > 16) 6.3 The identifier for calls here is always a JID, isn’t it? If
>>>> that’s the case, it’d make more sense to be using JIDs here, instead of
>>>> adding the layer of indirection of a URI with a fixed scheme.
>>>> > >
>>>> > > A call URI will not necessarily always be a JID. It has been the
>>>> intention since the start of this spec to leave open the option of other
>>>> transports for Rayo, such as HTTP.
>>>> >
>>>> > In such a case, how will an entity know about the available schemes,
>>>> and connect to them? If the implication is that there will need to be
>>>> changes later to express how to interoperate with future systems, it
>>>> suggests it wouldn’t be appropriate to push to Draft now with those changes
>>>> pending.
>>>> >
>>>> > Any such behaviour is very much a future concern; no-one has given it
>>>> any solid thought yet. Simply remaining generic in using URIs rather than
>>>> protocol-specific addresses seems harmless to me, though.
>>>>
>>>> Possibly harmless, but it’s what it implies that might be troublesome.
>>>> Pushing to Draft now with the expectation that new URI schemes that require
>>>> changes to the spec will be produced later wouldn’t be appropriate.
>>>>
>>>
>>> So we just stay Experimental until someone explicitly declares they will
>>> never pursue any changes come what may?
>>>
>>>
>>
>> No, but Draft status implies that at least specific changes are not
>> anticipated, and that any changes are going to be avoided, backwards
>> compatible if at all possible, and are certainly gated through Council
>> approval.
>>
>> So I'd expect here that even if new schemes were able to be added,
>> there'd be a baseline and ideally a discovery mechanism.
>>
>>
>>> > > 17) 6.3 I think here we’re getting into the territory where presence
>>>> stanzas are really not inappropriate for this
>>>> > >
>>>> > > Do you have an alternative suggestion, or a concrete argument
>>>> against?
>>>> >
>>>> > I’d have thought that (for this case) just sending the message
>>>> (probably as headline?) would be more appropriate? This seems to be trying
>>>> to send what is logically a ‘joined’ message to the client, rather than an
>>>> update of presence. Presence is generally the current state of an entity.
>>>> If you use presence for ‘joined’ and you first joined A and then joined B,
>>>> and so the most recent presence you received had ‘joined B’ in it, it
>>>> implies under the usual XMPP semantics that your new presence has replaced
>>>> the old one, and thus you’re no longer joined to A.
>>>> >
>>>> > That's the first practical argument against the use of presence here
>>>> that I've heard so-far; thank you. I'll give it more consideration and
>>>> either propose a modification to the spec or produce a counter-argument.
>>>> >
>>>> > > 23) Example 44: This introduces ‘active speaker detection’, but
>>>> doesn’t explain what this is (or reference an explanation), I think.
>>>> > >
>>>> > > It is what it says on the can, and is a common feature of media
>>>> servers.
>>>> >
>>>> > Alright. I feel a bit uncomfortable introducing terms that I wouldn’t
>>>> expect a typical XEP implementor to understand, but maybe it’s alright in
>>>> this case.
>>>> >
>>>> > I highly doubt a "typical XEP implementor" would be interested in
>>>> implementing a fully compliant Rayo server unless they were also a member
>>>> of the set of people who had heard that term before. See later points for
>>>> more.
>>>>
>>>> Well, rather the point of publishing as XEPs is that other people /can/
>>>> come along and implement it. Will comment more on later points when I get
>>>> to them, I expect.
>>>>
>>>>
>>
>> FWIW, I agree with Ben here. If Active Speaker Detection is a term of art
>> within the field, it seems like prerequisite knowledge. A reference would
>> be nice, but aside from knowing it means detecting which entity on the call
>> is currently speaking, I'm not sure what it would provide.
>>
>>
>>> > > 33) 6.5.4 - How is discovery of the optional/extensible mechanisms
>>>> discovered?
>>>> > >
>>>> > > It's not. Server documentation only.
>>>> >
>>>> > If it’s not discoverable, how would a client written without
>>>> reference to a particular server’s documentation interoperate with it?
>>>> >
>>>> > It would not, and it could not reasonably hope to. I see no benefit
>>>> to discovery here; it wouldn't change the situation any.
>>>>
>>>> I’d like to be sure I understand this, because it seems somewhat
>>>> important. Do you mean that following XEP-0327 is not sufficient to
>>>> implement a Rayo Client (or server)?
>>>>
>>>
>>> Please explain how Disco would make any difference.
>>>
>>>
>>
>> It's not specifically disco, any discovery mechanism would do.
>>
>> If I have implemented a Rayo client, how does it know whether the server
>> it's using will support its required and/or supported mechanisms?
>>
>
> And my counter-point: once it discovered such information, what would the
> client do with it?
>

We could just pretend that I have a general dislike of things which *could*
be discoverable but aren't.

But in practical terms, you seem to be insisting that a client is something
written specifically for a particular server.

In which case what good is it doing to put this specification through the
XSF?


>
>
>> > > 35) 6.5.4.4 - When would the nomatch expect to be triggered?
>>>> Presumably it’s not firing off e.g. whenever anyone says anything that
>>>> isn’t a DMTF when a DMTF input is configured? Can it trigger multiple
>>>> times, or is it removed after a match?
>>>> > >
>>>> > > A nomatch event would trigger in such circumstances that input is
>>>> received which does not match a grammar. Input for a particular modality
>>>> (eg speech or DTMF) is not received by a recognizer unless a grammar is
>>>> specified for that modality. A nomatch is not a standalone Rayo event, but
>>>> delivered as a completion event reason, and as such can only be fired once
>>>> for a given component.
>>>> > >
>>>> > > These semantics are standard for speech recognizers and do not
>>>> warrant specification in Rayo beyond what is already written.
>>>> >
>>>> > I’m not (yet) convinced that that’s true - one should really be able
>>>> to implement a XEP without needing implicit knowledge of how it should be
>>>> implemented. I think I could write a compliant implementation as things
>>>> stand that is very much not what you expect, so tightening this up seems
>>>> sensible to me. Others may disagree.
>>>> >
>>>> > I disagree that one could expect this XEP to contain a recipe for an
>>>> implementation. If it were to attempt to it would run to many volumes. This
>>>> specification is not a typical small add-on to an IM scenario.
>>>> >
>>>> > > 36) 6.5.5 - I think the rules for what happens to the output when
>>>> input begins aren’t defined. Although it’s implied that the output stops,
>>>> does it continue again after input?
>>>> > >
>>>> > > No, this is specified as barge in behaviour, which is well
>>>> understood in the field of IVR, and as such does not warrant
>>>> re-specification in Rayo.
>>>> >
>>>> > I think the same holds true here as does for the previous point.
>>>> >
>>>> > The point about "active speaker detection" holds here. If one is not
>>>> familiar with the term "barge in" and what happens in such a scenario as is
>>>> widely understood in the field, then one would not be successful in
>>>> building a useful implementation of a Rayo server.
>>>> >
>>>> > At some point the specification of the protocol has to give way to
>>>> what is considered prevailing knowledge, much like MAM does not contain
>>>> details of how to implement a database.
>>>>
>>>> Well, MAM doesn’t detail how to implement a database (and one need not
>>>> use a database to implement MAM), but if there are points where one would
>>>> need to understand how to implement a database in order to implement MAM,
>>>> that seems like a shortcoming in MAM (Although saying that, I think one
>>>> might reasonably argue that ‘a database’ is pretty much universal as a
>>>> concept amongst devs (or, indeed, the general populace), while barge-in in
>>>> this sense is not).
>>>>
>>>
>>> It is universal among people who have an interest in this specification.
>>>
>>
>> Unfortunately it's also a really hard term to find via Google.
>>
>> Maybe a sentence of explanation might help:
>>
>> "Prompt is a convenience component to wrap input and output components,
>> combine their lifecycles, and allow input to barge-in on an output
>> component in the standard sense - that is, it allows additional callers to
>> join an active call uninvited using a special authorization."
>>
>
> Ok, so I see there's some mis-understanding. Barge-in is, in a prompt
> situation, where one interrupts the output by providing early input. Think
> calling Fedex and not wanting to wait to hear the menu before mashing 0 to
> get a human. You just "barged" the output part of the prompt, which
> terminated as soon as you began providing input.
>
>

OK, so in that case I think you need an explanation in the text, since that
term of art seems to be used in multiple ways in the industry, and isn't,
as you suggested, "universal".


>
>>>
>>>> > > 41) 6.6.2 - if the client can’t handle the call, what’re the other
>>>> options than rejecting it? (MAY)
>>>> > >
>>>> > > It may simply ignore the offer and allow it to be accepted by
>>>> another PCP.
>>>> >
>>>> > Does that mean that this is effectively “MUST either reject the call,
>>>> or ignore the offer to allow it to be accepted by another PCP”?
>>>> >
>>>> > Sure, but it seems odd to me that we would specify that a client MUST
>>>> not take any action on a received stanza. Is that really
>>>> necessary/desirable?
>>>>
>>>> “MAY reject it, or MAY ignore it” would work fine for me too, without a
>>>> MUST.
>>>>
>>>>
>> I'd personally be more interested in knowing what the semantics of
>> rejection are.
>>
>> Does rejection mean the call request is terminated, whereas ignoring it
>> means the call request continues?
>>
>
> Yes. I'll make a note to flesh this out.
>
>
>> Does the text above Example 84 refer to the call already being accepted
>> by this client, or another?
>>
>
> Examples 83 and 84 are alternative responses to example 82.
>
>
>> >
>>>> > > 42) 6.8.1 - is feature-not-implemented an odd error to use for a
>>>> protocol violation?
>>>> > >
>>>> > > What would be the appropriate error to use here?
>>>> >
>>>> > bad-request is probably closer:
>>>> >
>>>> > "The sender has sent a stanza containing XML that does not conform to
>>>> >    the appropriate schema or that cannot be processed (e.g., an IQ
>>>> >    stanza that includes an unrecognized value of the 'type' attribute,
>>>> >    or an element that is qualified by a recognized namespace but that
>>>> >    violates the defined syntax for the element); the associated error
>>>> >    type SHOULD be "modify”.”
>>>> >
>>>> > whereas feature-not-implemented would be:
>>>> > " The feature represented in the XML stanza is not implemented by the
>>>> >    intended recipient or an intermediate server and therefore the
>>>> stanza
>>>> >    cannot be processed (e.g., the entity understands the namespace but
>>>> >    does not recognize the element name); the associated error type
>>>> >    SHOULD be "cancel" or "modify”.”
>>>> >
>>>> > This distinction is exactly why I chose feature-not-implemented. An
>>>> "unrecognized value of the type attribute" or other such bad-request would
>>>> look like this:
>>>> >
>>>> > <message type="dog"/>
>>>> >
>>>> > The protocol violation here would be of 6121, which this example
>>>> (6.8.1) does not violate.
>>>>
>>>> 327 says that anything other than ‘normal’ is illegal, doesn’t it? It’s
>>>> that rule that would be violated, making me suggest bad-format.
>>>>
>>>> > Further precedent at
>>>> http://xmpp.org/extensions/xep-0045.html#reservednick and likely
>>>> elsewhere.
>>>>
>>>> I don’t think that’s a similar situation - that’s showing what a server
>>>> that chooses not to implement an optional feature returns if a client tries
>>>> to use it. The case in point here is how the server responds to a client
>>>> sending something that it cannot possibly understand, because the protocol
>>>> isn’t allowed?
>>>>
>>>
>>> No. This is exactly the same situation. This is an optional feature of
>>> the Rayo spec.
>>>
>>>
>>
>> Well, XEP-0327 as written says servers MUST reject the traffic, so
>> clients cannot possibly expect this to succeed.
>>
>
> I don't follow. Where does it say that?
>

"If a message is directed to the call's JID with a type other than 'normal'
then the server MUST return a <feature-not-implemented/> error"

That's not optional.


>
>
>> There's no optional behaviour here. As such, this isn't an unimplemented
>> feature, but a bad request.
>>
>> This isn't a hill for me to die on, though.
>>
>> Dave.
>>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.jabber.org/pipermail/standards/attachments/20150902/8a456d0d/attachment.html>


More information about the Standards mailing list