[Standards] Rayo feedback.

Ben Langfeld ben at langfeld.me
Thu Jul 30 14:11:25 UTC 2015


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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.jabber.org/pipermail/standards/attachments/20150730/00166fb9/attachment.html>


More information about the Standards mailing list