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
