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