[Standards] Rayo feedback.

Ben Langfeld ben at langfeld.me
Tue Aug 18 11:39:51 UTC 2015


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.


> >  > 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.


> 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?


> > > 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?


> > > 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.


>
>>
>>> > > 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?


> 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/20150818/9af647eb/attachment.html>


More information about the Standards mailing list