[Standards] Rayo feedback.

Dave Cridland dave at cridland.net
Thu Sep 3 22:03:21 UTC 2015


On 3 September 2015 at 20:15, Ben Langfeld <ben at langfeld.me> wrote:

>
>
> On 2 September 2015 at 12:55, Dave Cridland <dave at cridland.net> wrote:
>
>> (Matthew Miller prodded me that I hadn't replied to this).
>>
>> On 18 August 2015 at 12:39, Ben Langfeld <ben at langfeld.me> wrote:
>>
>>> On 18 August 2015 at 08:13, Dave Cridland <dave at cridland.net> wrote:
>>>
>>>>
>>>>
>>>> On 17 August 2015 at 20:15, Ben Langfeld <ben at langfeld.me> wrote:
>>>>
>>>>>
>>>>>
>>>>> 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.
>>>>>>
>>>>>>
>>>> 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.
>>>>
>>>
>>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.jabber.org/pipermail/standards/attachments/20150903/4bc1f3f7/attachment.html>


More information about the Standards mailing list