On 3 September 2015 at 20:15, Ben Langfeld <[email protected]> wrote: > > > On 2 September 2015 at 12:55, Dave Cridland <[email protected]> wrote: > >> (Matthew Miller prodded me that I hadn't replied to this). >> >> On 18 August 2015 at 12:39, Ben Langfeld <[email protected]> wrote: >> >>> 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. >>> >> >> Because nothing else relies on this relationship in XMPP. Domain names - >> whether "subdomains" or not - do not have any relationship, implied or >> otherwise. >> >> So in order to mandate this, you really need to come up with an >> overwhelming reason why this specification should require this, unlike >> every other XMPP specification. >> > > Ok. I'll see what I can do to remove that stipulation from the text. AFAIK > it won't make any technical difference, it's just a logical thing. > > >> > > 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. >>> >>> >> >> I've no objection to stipulating a baseline of SIP if that's what the >> market needs. >> > > Then I'll do that and pray that your position is representative of the XSF > Council. If it's not, then I'd love to hear so soon because that is a fight > no-one will win and it'd be better for me to just retract the spec. >
I, personally, prefer realistic baselines to nothing at all - but I'd prefer an absence of a baseline to an unrealistic one. I do have a huge preference toward being able to determine a server's support via protocol, though, whichever - see below for some discussion on this. > > >> 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? >>> >> >> Since otherwise it's not clear when you get a client that it'll work (or >> not) with your server. >> > > I still cannot imagine what I, as someone who has built Rayo applications > for the last 3 years, would use this for. I'd appreciate someone > contributing this part to the spec if they have a use for it. > > >> > > 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? >>> >> >> We could just pretend that I have a general dislike of things which >> *could* be discoverable but aren't. >> >> But in practical terms, you seem to be insisting that a client is >> something written specifically for a particular server. >> >> In which case what good is it doing to put this specification through the >> XSF? >> > > Any client library or framework (see Adhearsion/Punchblock for precedent) > would not benefit in and of itself from any such discovery, much the same > way a generic XMPP library would not. An application based on those > libraries would use certain features of the specifications which impact the > choice of server implementations they have. > > If a specific group chat application was looking for an XMPP server, it > would have to (components aside) choose one which implements the > server-side parts of MUC) for example. If a MUC-specific client application > was used against a server which does not implement MUC, then the best it > could hope to do is fail to launch saying "get a better server". > > Is your point about failing fast vs attempting to process a call and > failing mid-way, in a case where one deploys against an insufficient > server? Either way, one would get a usable error. > That's one way to put it. Another is that in general, having generic, well-known paths for discovery seems to have promoted interoperability *despite* heavy optional behaviour; in fact it's tended to encourage implementation of particular options due to their immediate visibility. On the other hand, a suck-it-and-see strategy of rejecting functionality only when it's attempted has tended to mean developers have shied away from the functionality entirely. The way you're writing - your choice of words etc - suggests that Rayo clients are all bespoke, and if not designed for a specific deployment, then certainly a particular implementation. I know of certain cases where XMPP applications are tied to a server implementation, but they're all management tools; whereas any MUC-specific client should, in principle, work with any server implementing MUC. I don't understand why it is neither possible nor desirable to write a Rayo client that is expected to work against any server implementation. > > >> > > 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. >>> >>> >> >> OK, so in that case I think you need an explanation in the text, since >> that term of art seems to be used in multiple ways in the industry, and >> isn't, as you suggested, "universal". >> > > I will add a brief explanation for disambiguation. > > >> > > 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? >>> >> >> "If a message is directed to the call's JID with a type other than >> 'normal' then the server MUST return a <feature-not-implemented/> error" >> >> That's not optional. >> > > The discussion here is wether sending messages of any type at all is > required. It is not required for a Rayo server to implement any message > stanza to a call. It is possible to implement messages of type 'normal'. > I'm not sure how I can make this any clearer; it makes perfect sense to me > and I'm failing to understand why it's not making sense to other people. > > Sending messages of type normal through to calls is clearly optional - a server rejecting a message of type normal is therefore not implementing an optional feature - <feature-not-implemented/> is fine for *this* case. Sending messages of type chat (for example) is explicitly forbidden by the specification; therefore that's not a case of a server not implementing an optional feature, but a client sending bad protocol - hence <bad-request/>. > I'm really sorry, but I think we're at an impasse. I'm convinced that what > is written is correct and that the comments against it are a > misunderstanding, but I cannot think of a way to say it that removes the > misunderstanding. > > >> >>> >>>> 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. >>>> >>> >>> >> >
