On 18 August 2015 at 08:13, Dave Cridland <[email protected]> wrote: > > > On 17 August 2015 at 20:15, Ben Langfeld <[email protected]> wrote: > >> >> >> On 17 August 2015 at 13:44, Kevin Smith <[email protected]> wrote: >> >>> On 14 Aug 2015, at 20:11, Ben Langfeld <[email protected]> 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. >
