I addressed every single one of your comments and provided feedback in this thread. Perhaps you could take a look at those comments and individual changes? I most certainly did not ignore the vast majority of your comments as this appears to claim.
On 30 July 2015 at 07:59, Kevin Smith <[email protected]> wrote: > 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
