[Standards] Rayo feedback.

Kevin Smith kevin.smith at isode.com
Mon Aug 17 16:44:51 UTC 2015


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?

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

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

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

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

/K




More information about the Standards mailing list