[Standards] Rayo feedback.

Ben Langfeld ben at langfeld.me
Mon Aug 17 19:15:20 UTC 2015


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


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


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


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


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


> /K
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.jabber.org/pipermail/standards/attachments/20150817/80784664/attachment.html>


More information about the Standards mailing list