Re: [Standards] Rayo feedback.
On 3 September 2015 at 20:15, Ben Langfeld wrote: > > > On 2 September 2015 at 12:55, Dave Cridland wrote: > >> (Matthew Miller prodded me that I hadn't replied to this). >> >> On 18 August 2015 at 12:39, Ben Langfeld wrote: >> >>> On 18 August 2015 at 08:13, Dave Cridland wrote: >>> On 17 August 2015 at 20:15, Ben Langfeld wrote: > > > On 17 August 2015 at 13:44, Kevin Smith wrote: > >> On 14 Aug 2015, at 20:11, Ben Langfeld 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. >> > > >> > > Not true. The word I used was "perhaps". This is simply to point >> out that full JIDs must be used to address these entities and no >> relationship between domains may be assumed. >> > >> > I think that at least the table in 5.2 is quite explicit in >> requiring things to be a subdomain - I take it this wasn’t intended. >> > >> > Actually quite the opposite: >> > >> > > where elements in square brackets are optional >> > >> > @[.]/ >> > >> > Quite explicitly optional, I'd say. >> >> Sorry, badly expressed. It is optional that it’s a *sub*domain, yes. >> But if it’s not the service domain, you’re requiring it to be a subdomain >> of the service domain. This is what I was calling out - this is a unique >> requirement in XMPP; there’s usually no formal relationship between >> different domains like this, and it’s not clear to me that one is needed >> here. >> >> I'd like to see the answer to this one. Given a server of shakespeare.lit, do I understand that a call must be within either that domain or a subdomain of it? >>> >>> I guess that's what this implies. I have yet to hear why it's a bad >>> thing though. >>> >> >> Because nothing else relies on this relationship in XMPP. Domain names - >> whether "subdomains" or not - do not have any relationship, implied or >> otherwise. >> >> So in order to mandate this, you really need to come up with an >> overwhelming reason why this specification should require this, unlike >> every other XMPP specification. >> > > Ok. I'll see what I can do to remove that stipulation from the text. AFAIK > it won't make any technical difference, it's just a logical thing. > > >> > > 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. >> > > >> > > See above. >> > >> > I think at least the second part of the question stands - what does >> receiving unavailable mean? >> > >> > Means that the client has gone offline and will not interact with >> the calls under its control any more. The Rayo server may choose to hang >> up >> those calls, wait for the client to come back, or any other >> implementation-specific behaviour. >> >> It seems worth mentioning this, to me. >> >> > > 8) 6.2.1 How does the client discover the available URI schemes >> for to/from? >> > > >> > > No such discovery is specified, and it is assumed that a Rayo >> service would document this. >> > >> > It’s not clear to me what this means for interoperability. Does it >> mean that one can’t implement a Rayo client using this XEP and expect it >> to >> interoperate with an arbitrary Rayo service, because it won’t know what >> the >> available URI schemes are? >> > >> > Even if this were available via Disco, it would make no difference. >> You couldn't build your app to compensate. I think >> per-implementation/service documentation is sufficient here. >> >> Doesn’t that mean that one can’t implement a Rayo client without >> reference to per-server documentation? >> > > One could certainly implement a client library/framework, and we have > done. When one builds / deploys an application, however, one must know > something about the server implementation. I maintain, though, that Disco > as documentation is no better than normal documentation. I'd love to hear > your argument for Disco being useful here, but it sounds like we're just > trying to tick a "haz Disco" checkbox for no reason. > > I'd expect a generically built client to be possible, and I would expect a baseline that ensured it did the basics if at all possible. >>> >>> I think the best we could do right now is "must support sip:". But then >>> someone will come along and say "what about Jingle?". Then we'll have a >>> fight over it where the IVR implementations don
Re: [Standards] Rayo feedback.
On 2 September 2015 at 12:55, Dave Cridland wrote: > (Matthew Miller prodded me that I hadn't replied to this). > > On 18 August 2015 at 12:39, Ben Langfeld wrote: > >> On 18 August 2015 at 08:13, Dave Cridland wrote: >> >>> >>> >>> On 17 August 2015 at 20:15, Ben Langfeld wrote: >>> On 17 August 2015 at 13:44, Kevin Smith wrote: > On 14 Aug 2015, at 20:11, Ben Langfeld 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. > > > > > > Not true. The word I used was "perhaps". This is simply to point > out that full JIDs must be used to address these entities and no > relationship between domains may be assumed. > > > > I think that at least the table in 5.2 is quite explicit in > requiring things to be a subdomain - I take it this wasn’t intended. > > > > Actually quite the opposite: > > > > > where elements in square brackets are optional > > > > @[.]/ > > > > Quite explicitly optional, I'd say. > > Sorry, badly expressed. It is optional that it’s a *sub*domain, yes. > But if it’s not the service domain, you’re requiring it to be a subdomain > of the service domain. This is what I was calling out - this is a unique > requirement in XMPP; there’s usually no formal relationship between > different domains like this, and it’s not clear to me that one is needed > here. > > >>> I'd like to see the answer to this one. Given a server of >>> shakespeare.lit, do I understand that a call must be within either that >>> domain or a subdomain of it? >>> >> >> I guess that's what this implies. I have yet to hear why it's a bad thing >> though. >> > > Because nothing else relies on this relationship in XMPP. Domain names - > whether "subdomains" or not - do not have any relationship, implied or > otherwise. > > So in order to mandate this, you really need to come up with an > overwhelming reason why this specification should require this, unlike > every other XMPP specification. > Ok. I'll see what I can do to remove that stipulation from the text. AFAIK it won't make any technical difference, it's just a logical thing. > > > 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. > > > > > > See above. > > > > I think at least the second part of the question stands - what does > receiving unavailable mean? > > > > Means that the client has gone offline and will not interact with > the calls under its control any more. The Rayo server may choose to hang > up > those calls, wait for the client to come back, or any other > implementation-specific behaviour. > > It seems worth mentioning this, to me. > > > > 8) 6.2.1 How does the client discover the available URI schemes > for to/from? > > > > > > No such discovery is specified, and it is assumed that a Rayo > service would document this. > > > > It’s not clear to me what this means for interoperability. Does it > mean that one can’t implement a Rayo client using this XEP and expect it > to > interoperate with an arbitrary Rayo service, because it won’t know what > the > available URI schemes are? > > > > Even if this were available via Disco, it would make no difference. > You couldn't build your app to compensate. I think > per-implementation/service documentation is sufficient here. > > Doesn’t that mean that one can’t implement a Rayo client without > reference to per-server documentation? > One could certainly implement a client library/framework, and we have done. When one builds / deploys an application, however, one must know something about the server implementation. I maintain, though, that Disco as documentation is no better than normal documentation. I'd love to hear your argument for Disco being useful here, but it sounds like we're just trying to tick a "haz Disco" checkbox for no reason. >>> >>> I'd expect a generically built client to be possible, and I would expect >>> a baseline that ensured it did the basics if at all possible. >>> >> >> I think the best we could do right now is "must support sip:". But then >> someone will come along and say "what about Jingle?". Then we'll have a >> fight over it where the IVR implementations don't give a crap about Jingle >> and the XSF demands support for it and doesn't care about SIP >> and...deadlock. >> >> > > I've no objection to stipulating a baseline of SIP if that's what the > mar
Re: [Standards] NEW: XEP-0363 (HTTP File Upload)
Thu, 27 Aug 2015 16:10:18 + (UTC) XMPP Extensions Editor wrote: > Version 0.1 of XEP-0363 (HTTP File Upload) has been released. > > Abstract: This specification defines a protocol to request > permissions from another entity to upload a file to a specific path > on an HTTP server and at the same time receive a URL from which that > file can later be downloaded again. > > Changelog: Initial published version approved by the XMPP Council. > (XEP Editor (mam)) > > Diff: http://xmpp.org/extensions/diff/api/xep/0363/diff/0.1/vs/0.1 > > URL: http://xmpp.org/extensions/xep-0363.html > It would be great if the protocol supports image thumbnails (optionally). A server could generate thumbnails during upload so a client don't need to convert image locally. This will reduce cpu/battery usage on mobile devices, simplify clients code and will prevent UI from freezing during image transformation). I think there are two ways implementing it: 1) The thumbnail SHOULD be returned with HTTP response, e.g.: HTTP/1.1 200 OK Content-Type: text/xml ... (the element is described in XEP-0264) 2) Another way is introducing new stanza which will be sent by an XMPP server when upload is complete, for example: Also, element could be extended to notify a client about upload status. This thumbnail then can be put into file-transfer offer using either jingle http transport protoXEP or directly into jabber:x:oob message, e.g: https://download.montague.tld/4a771ac1-f0b2-4a4a-9700-f2a26fa2bb67/my_juliet.png https://download.montague.tld/4a771ac1-f0b2-4a4a-9700-f2a26fa2bb67/my_juliet.png file
