[Standards] Rayo feedback.

Kevin Smith kevin.smith at isode.com
Thu Jul 30 10:59:38 UTC 2015


I’m going through the diff (http://xmpp.org/extensions/diff/api/xep/0327/diff/0.6/vs/0.7) to check it addresses my comments before voting on Draft, and have these comments:


On 16 Jun 2015, at 13:26, Kevin Smith <kevin.smith at isode.com> 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.

This restriction still seems to be in place in 5.2. I don’t think there was a response to my query on why this could be useful

> 3) 5.1.6 Is calling things Components the most useful terminology here, when Components have a well-established meaning in XMPP (and a RAYO server is likely to be such a component).

I don’t think this has been discussed/addressed.

> 4) 6.1’s reliance on a <show>chat</show> seems odd at best - wouldn’t a normal available presence be better here? I’m also not sure that the requirement for it to be directed presence is waranted - why wouldn’t broadcast presence work here?

I don’t think this has been discussed/addressed.

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

I don’t think this has been discussed/addressed.

> 6) 6.2.1 Is how these metadata are handled defined?

Thanks for adding words here. I may be being dense, but I’m not sure if I was implementing this it’s clear how these should be ‘mapped to the underlying signalling protocol’, how a client can discover which are settable, etc.

> 8) 6.2.1 How does the client discover the available URI schemes for to/from?

I don’t think this has been discussed/addressed.

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

I think this has been discussed before, but I’d still like some reassurance why presence is better than messages or pubsub for sending these notifications.

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

I don’t think this has been discussed/addressed.

> 17) 6.3 I think here we’re getting into the territory where presence stanzas are really not inappropriate for this

(10)

> 18) 6.3.4 introduces a direction attribute that I don’t think has been defined anywhere at this point.

I don’t think this has been discussed/addressed.

> 19) 6.4 "a server SHOULD represent a mixer internally using some alternative name scoped to the client's security zone and mapped to the friendly name/URI presented to the client for the emission of events and processing of commands” - I don’t entirely understand this. If it’s an internal representation, why is this important for interop?

I don’t think this has been discussed/addressed.

> 23) Example 44: This introduces ‘active speaker detection’, but doesn’t explain what this is (or reference an explanation), I think.

I don’t think this has been discussed/addressed.

> 24) "Once the last participant unjoins from the mixer, the mixer SHOULD be destroyed.” - in what scenarios would it be appropriate not to? Should this be discussed?

I don’t think this has been discussed/addressed.

> 25) 6.5 "A server SHOULD implement all core components” - what are the implications for clients if the server doesn’t implement some of these?

I don’t think this has been discussed/addressed.

> 30) 6.5.3.2 - I think a quick description of the necessary addressing here would be useful.

I don’t think this has been discussed/addressed.

> 31) Example 69 - I think this doesn’t give the units of time for the seek except in the example title and would be worth calling out.

I don’t think this has been discussed/addressed.

> 33) 6.5.4 - How is discovery of the optional/extensible mechanisms discovered?

I don’t think this has been discussed/addressed.

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

I don’t think this has been discussed/addressed.

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

I don’t think this has been discussed/addressed.

> 38) 6.5.6.1 When there are joins involved, can’t there be multiple callers? If so, how does that affect e.g. "In send mode, only the audio sent by the caller is recorded.”?

I don’t think this has been discussed/addressed.

> 40) are x-skill and x-customer-id defined anywhere? I think the <header…/> stuff is new here (it doesn’t seem consistent with previous use of <header…/>). What are the rules for header here?

These now appear everywhere, but I think (6) still stands.

> 41) 6.6.2 - if the client can’t handle the call, what’re the other options than rejecting it? (MAY)

I don’t think this has been discussed/addressed.

> 42) 6.8.1 - is feature-not-implemented an odd error to use for a protocol violation?

I don’t think this has been discussed/addressed.

/K


More information about the Standards mailing list