[Standards] Rayo feedback.

Kevin Smith kevin.smith at isode.com
Thu Jul 30 20:07:25 UTC 2015


Apologies Ben. I commented in the council room while I was going through that  
it felt like I'd not received a mail, but I checked my archives before  
reviewing and the only mail I had was saying you were going to address my  
comments. I've now been through the mailing list archives on XMPP.org and  
found http://mail.jabber.org/pipermail/standards/2015-June/029933.html, so  
I'll read that and adjust my feedback once I'm back from vacation the week  
after next. Ignore the below feedback for the moment.

/K
On Thu, 30 Jul 2015 15:11:25 +0100, Ben Langfeld wrote:
>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 <kevin.smith at isode.com> 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 <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