On 17 August 2015 at 20:15, Ben Langfeld <b...@langfeld.me> wrote: > > > On 17 August 2015 at 13:44, Kevin Smith <kevin.sm...@isode.com> wrote: > >> On 14 Aug 2015, at 20:11, Ben Langfeld <b...@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?
> > > 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. 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. > > > 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? > > > 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." > > >> > > 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? Does the text above Example 84 refer to the call already being accepted by this client, or another? > > >> > > 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. 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.
