Re: [Standards] LAST CALL: XEP-0363 (HTTP File Upload)
On 29 Nov 2017, at 19:16, Jonas Wielicki (XSF Editor) wrote: > This message constitutes notice of a Last Call for comments on > XEP-0363. > > Title: HTTP File Upload > 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. > > URL: https://xmpp.org/extensions/xep-0363.html > > This Last Call begins today and shall end at the close of business on > 2017-12-12. > > Please consider the following questions during this Last Call and send > your feedback to the standards@xmpp.org discussion list: > > 1. Is this specification needed to fill gaps in the XMPP protocol > stack or to clarify an existing protocol? Kinda. We do have file transfer mechanisms already. This tries to to address a use case that these have traditionally handled badly, although it’s not clear if an entirely new mechanism like this is required, or if it can be adequately addressed inside existing frameworks. > 2. Does the specification solve the problem stated in the introduction > and requirements? Yes. > > 3. Do you plan to implement this specification in your code? If not, > why not? > > 4. Do you have any security concerns related to this specification? Should probably mention that you’re going to be handing out your IP to whichever upload service you use. > > 5. Is the specification accurate and clearly written? "The service SHOULD NOT impose sanctions on an entity for retrying earlier than the specified time.” Seems a bit odd - what’s the point in specifying a limit if clients are allowed to ignore it, and the server has to process the request normally anyway? "It is RECOMMENDED that the service stores the files for as long as possible which is of course limited by storage capacity.” Seems like an odd place to put normative language to me, surely limits are a local policy choice? " • Server operators SHOULD consider the responsibility that comes with storing user data and MAY consider appropriate measures such as full disk encryption.” And I’m not sure that a XEP can do much normatively about full disk encryption. Not related to the writing of the XEP, but the approach: this doesn’t cross security boundaries well. While jingle will fall back to IBB (and servers can enforce that fallback), keeping the flow under their control, and allowing data to cross network boundaries, 363 falls apart in the face of non-Internet (and even some Internet) use cases. This is going to become quite relevant to MIX, where you’re going to want to upload files to the MIX, but may well not be able to route to it and would need your server to do pass-through. I *think* (but have not tried to write it) that one could spec a relatively simple pass-through mechanism for this. /K ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
Re: [Standards] LAST CALL: XEP-0234 (Jingle File Transfer)
On 29 Nov 2017, at 19:16, Jonas Wielicki (XSF Editor) wrote: > > This message constitutes notice of a Last Call for comments on > XEP-0234. > > Title: Jingle File Transfer > Abstract: > This specification defines a Jingle application type for transferring > a file from one entity to another. The protocol provides a modular > framework that enables the exchange of information about the file to > be transferred as well as the negotiation of parameters such as the > transport to be used. > > URL: https://xmpp.org/extensions/xep-0234.html > > This Last Call begins today and shall end at the close of business on > 2017-12-12. > > Please consider the following questions during this Last Call and send > your feedback to the standards@xmpp.org discussion list: > > 1. Is this specification needed to fill gaps in the XMPP protocol > stack or to clarify an existing protocol? Yes. > 2. Does the specification solve the problem stated in the introduction > and requirements? Yes. > 3. Do you plan to implement this specification in your code? If not, > why not? Yes > 4. Do you have any security concerns related to this specification? Other than the escaping nit below, no. > 5. Is the specification accurate and clearly written? "Alternatively to a element, the initiator can also include a element. This avoids the need to read the file twice to calculate the hash.” We should probably mention that hash-used is also 300. For the ‘name’ attribute of the description, it seems that we might be requiring escaping of things that the other entity gives special handling, but that we don’t. How would we tell? Currently we have ICE-TCP as a SHOULD. Is that sensible? Does it reflect reality? /K ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
Re: [Standards] LAST CALL: XEP-0387 (XMPP Compliance Suites 2017)
On 11 Dec 2017, at 17:23, Holger Weiß wrote: > > * Kevin Smith [2017-12-11 17:16]: >> On 11 Dec 2017, at 16:44, Holger Weiß wrote: >>> * Kevin Smith [2017-12-11 15:34]: 84 allows you to publish multiple versions of an avatar, each of which goes to its own item within the node, which would require multiple items. >>> >>> It says the user "publishes avatar data for 'image/png' content-type to >>> data node and optionally publishes other content-types to HTTP URLs." I >>> was assuming this was done precisely to avoid multiple items. >> >> I think Example 10 is in conflict with that reading. > > In example 10, a single 'metadata' item holding multiple > elements is published. One of them references a 'data' item, the others > reference HTTP URLs. You’re entirely right. /K ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
Re: [Standards] LAST CALL: XEP-0387 (XMPP Compliance Suites 2017)
* Kevin Smith [2017-12-11 17:16]: > On 11 Dec 2017, at 16:44, Holger Weiß wrote: > > * Kevin Smith [2017-12-11 15:34]: > >> 84 allows you to publish multiple versions of an avatar, each of which > >> goes to its own item within the node, which would require multiple > >> items. > > > > It says the user "publishes avatar data for 'image/png' content-type to > > data node and optionally publishes other content-types to HTTP URLs." I > > was assuming this was done precisely to avoid multiple items. > > I think Example 10 is in conflict with that reading. In example 10, a single 'metadata' item holding multiple elements is published. One of them references a 'data' item, the others reference HTTP URLs. Holger ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
Re: [Standards] LAST CALL: XEP-0387 (XMPP Compliance Suites 2017)
On 11 Dec 2017, at 16:44, Holger Weiß wrote: > > * Kevin Smith [2017-12-11 15:34]: >> 84 allows you to publish multiple versions of an avatar, each of which >> goes to its own item within the node, which would require multiple >> items. > > It says the user "publishes avatar data for 'image/png' content-type to > data node and optionally publishes other content-types to HTTP URLs." I > was assuming this was done precisely to avoid multiple items. I think Example 10 is in conflict with that reading. /K ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
Re: [Standards] LAST CALL: XEP-0352 (Client State Indication)
On 7 Dec 2017, at 17:35, Jonas Wielicki (XSF Editor) wrote: > > This message constitutes notice of a Last Call for comments on > XEP-0352. > > Title: Client State Indication > Abstract: > This document defines a way for the client to indicate its > active/inactive state. > > URL: https://xmpp.org/extensions/xep-0352.html > > This Last Call begins today and shall end at the close of business on > 2017-12-21. > > Please consider the following questions during this Last Call and send > your feedback to the standards@xmpp.org discussion list: > > 1. Is this specification needed to fill gaps in the XMPP protocol > stack or to clarify an existing protocol? It was, it’s less clear that it still is. Once upon a time, clients on mobile would continue to run in the background in a useful way, at least on Android (it’s never really been the case for iOS unless you abused APIs), but these days even Android is moving away from this towards other mechanisms that might be more appropriate for us (e.g. Push). > 2. Does the specification solve the problem stated in the introduction > and requirements? The requirement is basically to implement CSI, so yes :) > 3. Do you plan to implement this specification in your code? If not, > why not? Not currently - I don’t think it solves the issues for mobile that it once did, at least in the mid-future, so I’ll be inclined to concentrate on Push and other needed parts (like fast reconnects). > 4. Do you have any security concerns related to this specification? I have a feeling that the current prose that semi-recommends bypassing 6120/6121 rules and silently dropping stanzas from the middle of a stream might introduce security issues in subtle ways, although I haven’t yet thought of any. > 5. Is the specification accurate and clearly written? I think the suggested-but-not-normative server behaviours either need more fleshing out, or probably shouldn’t be included. " • Suppress presence updates until the client becomes active again. On becoming active, push the latest presence from each contact.” For example can go wrong in interesting ways, depending how you interpret it, and break PEP, MUC, or presence subscribing. "Regardless of what optimisations a server implements, it SHOULD provide a way for administrators to configure them” I think this text is trying to avoid a server doing RFC-breaking things without allowing an admin to opt-out. If that’s the case, I suggest that it would instead be better to say that a server MUST NOT introduce any RFC-breaking optimisations by default. If that’s not the case, I think mandating what’s configurable is probably not appropriate. "If the server supports CSI, it advertises it in the stream features after the client has authenticated:” I feel like we’ve probably discussed this is the distant past, but it seems (uniquely?) inconsistent to advertise stream features that are only used after the stream is set up and the user could disco instead. "For example: A client sends a CSI active nonza” I don’t think using the ‘nonza’ term (and inconsistently at that) is aiding the reading of the XEP here. We can say “element” (as we do elsewhere in the spec) and be at least as clear as nonza, without inventing new, confusing nomenclature. "That is, stream resumption does not affect the current CSI state, which always defaults to 'active' for new and resumed streams” I think this intends to say the opposite of what it says, doesn’t it? Stream resumption *does* affect the current CSI state, which it resets to ‘active’. "To protect the privacy of users, servers MUST NOT reveal the clients active/inactive state to other entities on the network.” I’d have thought exposing this to admins of the user’s server is probably fine (plus obvious grammar slip), although maybe that doesn’t need this sentence changed. /K ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
Re: [Standards] LAST CALL: XEP-0387 (XMPP Compliance Suites 2017)
* Kevin Smith [2017-12-11 15:34]: > 84 allows you to publish multiple versions of an avatar, each of which > goes to its own item within the node, which would require multiple > items. It says the user "publishes avatar data for 'image/png' content-type to data node and optionally publishes other content-types to HTTP URLs." I was assuming this was done precisely to avoid multiple items. Holger ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
Re: [Standards] LAST CALL: XEP-0186 (Invisible Command)
On 7 Dec 2017, at 17:35, Jonas Wielicki (XSF Editor) wrote: > > This message constitutes notice of a Last Call for comments on > XEP-0186. > > Title: Invisible Command > Abstract: > This document specifies an XMPP protocol extension for user > invisibility. > > URL: https://xmpp.org/extensions/xep-0186.html > > This Last Call begins today and shall end at the close of business on > 2017-12-21. > > Please consider the following questions during this Last Call and send > your feedback to the standards@xmpp.org discussion list: > > 1. Is this specification needed to fill gaps in the XMPP protocol > stack or to clarify an existing protocol? Probably. > 2. Does the specification solve the problem stated in the introduction > and requirements? Probably. Comments later. > 3. Do you plan to implement this specification in your code? If not, > why not? Not currently, I don’t think we need the feature in our code. > 4. Do you have any security concerns related to this specification? I think the Security Considerations should list the most obvious leaks that still occur when this is implemented (it says they exist, but doesn’t suggest what any are). > 5. Is the specification accurate and clearly written? It’s not clear to me why we need to both mandate a default for probe, and that it’s always included. I think it would be worth explaining *why* you might want to send invisible without a probe, which seems at first glance like it’s the same as not sending presence at all (I know it’s not!). "SHOULD deliver inbound stanzas whose 'to' address is the bare JID of the user (subject to standard XMPP stanza handling rules from RFC 6120 and RFC 6121).” I think this needs tightening to instead of ‘subject to…’ say something like ‘if it would otherwise receive…’. Else one could read it as saying that a negative priority invisible resource gets messages. " • If the server responds to a presence probe, the last available presence MUST indicate that the user is unavailable, and if a time is indicated it MUST be the time when the client went invisible.” I don’t think this is right, e.g. two resources, 1 goes invisible, then 2 goes offline - the time should be when 2 went offline, not 1 went invisible. " • If the server responds to a Last Activity (XEP-0012) [5] request, the last activity time MUST be the time when the client went invisible.” Same. "If the user wishes to then send presence to all contacts in the roster,” I think this means those with a presence sub, not just being in the roster (this is correctly stated later) "(the server MAY also send that notification to any entities to which the client sent directed presence while invisible, whether or not they are in the user's roster)” This seems weird, as its the only time this would happen; I don’t see a reason for the inconsistency with normal directed presence handling. /K ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
Re: [Standards] XEP-0313: Treatment of type=groupchat in user archive with or without hint
* Kevin Smith [2017-12-11 15:50]: > On 23 Nov 2017, at 17:11, Daniel Gultsch wrote: > > For me it doesn't ever make sense to store type=groupchat messages in > > the user archive. That archive will be incomplete, thus forcing me to > > query the MUC servers archive upon join anyway. > > I've become unconvinced by this - surely the archive will be complete > for its intention, which is to archive those messages the user received. > It won't contain messages that the user wasn't in the MUC for, but that > seems like the correct behaviour. So the contents of the user archive will depend on the user's presence? I would've thought the main feature of MAM is quite the opposite, i.e. to also make those messages retrievable the user *didn't* receive anyway. > I think this is another example of the 'two types of MAM'. Some people > want to use MAM for 'complete sync', whereby the download all the > messages the user has seen, and maintain a full local archive. For this, > ISTM you're going to want gc in your archive. Wouldn't both types of people want their client to catch up with the MUC history after network hiccups? So the client will have to query the MUC MAM archive either way, no? So the groupchat messages stored in the user archive would end up being only a subset of the messages the user has seen, no? Holger ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
Re: [Standards] UPDATED: XEP-0359 (Unique and Stable Stanza IDs)
On 22 Sep 2017, at 16:48, Georg Lukas wrote: > the vast number of different IDs can make a developer dizzy. Can we > please specify in 0359 that an entity adding an MUST (or at > least SHOULD) set the message-id value of the message to the same ID as > the ? I can’t immediately think of a reason *not* to do this, at least. /K ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
Re: [Standards] XEP-0313: Treatment of type=groupchat in user archive with or without hint
Sorry, I’m going to revisit this… On 23 Nov 2017, at 17:11, Daniel Gultsch wrote: > For me it doesn't ever make sense to store type=groupchat messages in > the user archive. That archive will be incomplete, thus forcing me to > query the MUC servers archive upon join anyway. I’ve become unconvinced by this - surely the archive will be complete for its intention, which is to archive those messages the user received. It won’t contain messages that the user wasn’t in the MUC for, but that seems like the correct behaviour. So if a user wants an archive of the messages they’ve seen, it seems to me that MUC messages are a significant part of this, so we would want them to be stored, and want them to be returned by a client. I think this is another example of the ‘two types of MAM’. Some people want to use MAM for ‘complete sync’, whereby the download all the messages the user has seen, and maintain a full local archive. For this, ISTM you’re going to want gc in your archive. Other people want to only do ‘catch up’ and receive recent relevant messages (e.g. ‘only unread’) - gc is only sometimes going to be useful for this (but there are examples where it is). I’m increasingly coming back to the idea that we should add a filter to allow not fetching type=gc for clients that want to ignore it, but leave core behaviour as-is. /K ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
Re: [Standards] LAST CALL: XEP-0387 (XMPP Compliance Suites 2017)
On 7 Dec 2017, at 08:31, Jonas Wielicki wrote: 84 is listed as N/A for server, but I think it’s possible for a server satisfying its requirements to not meet the requirements of 84 (someone tell me if I’m wrong). >>> >>> What requirements? That definitely sounds like a problem if so. >> >> It needs multiple items per node, doesn’t it? Maybe I misremember, but we >> should check. > > No, that’s not true. I think that’s something some folks (including me) > wanted > to go for, but it’s a slow progress of updating specs (see the most-recent > XEP-0060 update) and implementations (particularly the PubSub side of things). I’m not sure you’re right :) 84 allows you to publish multiple versions of an avatar, each of which goes to its own item within the node, which would require multiple items. At least, that’s my reading of it. I’m not sure about listing resumption as needed for IM - as discussed earlier in the MUC I don’t think it’s the real solution to that problem, but it’s not a hill for me to die on. >>> >>> I disagree; this is essential for a good mobile experience. >> >> I was noting about the IM table, not the Mobile table (I think the same is >> true for mobile that it’s not the /right/ solution, but I think it’s the >> best we’ve currently got). > > I’m pretty sure that resumption isn’t going to go away, even in the long > term. > I wouldn’t want to have a storm of inbound presence and PEP > (on_sub_and_presence) notifications on each failover on mobile. (The > discussion in the MUC, if we’re thinking about the same, mostly concerned > messages.) > > But this is probably a discussion for another time, and not for this LC. Yes. /K ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
Re: [Standards] XEP-0060: Register publish options 'persist-items'
On 11 Dec 2017, at 12:42, Daniel Gultsch wrote: > > 2017-12-11 13:30 GMT+01:00 Kevin Smith : >> From a ‘not breaking xep60’ point of view, could one reasonably argue that >> the latter is equivalent in effect to registering a whole load of publish >> options, which implementations must be happy with already? > > Yes. It doesn't break anything it just spares us from having to > register all required publish options by hand. I think that implies there isn’t much reason to make the shortcut, doesn’t it? Although I’m probably not giving this the bandwidth it deserves today. /K ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
Re: [Standards] XEP-0060: Register publish options 'persist-items'
2017-12-11 13:30 GMT+01:00 Kevin Smith : > From a ‘not breaking xep60’ point of view, could one reasonably argue that > the latter is equivalent in effect to registering a whole load of publish > options, which implementations must be happy with already? Yes. It doesn't break anything it just spares us from having to register all required publish options by hand. ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
Re: [Standards] XEP-0060: Register publish options 'persist-items'
On 8 Dec 2017, at 13:20, Daniel Gultsch wrote: > > Hi, > > XEP-0048, XEP-0223 and possibly others are referencing a > publish-option called 'persist-item'. XEP-0060 says that any > publish-options MUST be registered. This hasn't happened yet. > > Here is a pull request that does: https://github.com/xsf/xeps/pull/555 > (editors will still have to pull this into the registry) > > as an alternative approach we could agree that every registered > node-configuration double acts as a publish-options PRECONDITION with > the same name. > > Here is a pull request that adds such wording to XEP-0060. > > https://github.com/xsf/xeps/pull/556 > > This pull request also removes the possibility of registering > publish-options as OVERRIDE (They would probably have to share the > same name as the node-configuration publish-options and confuse > people. > > These two PR are mutually exclusive. > Pick your poison. PR#555 is a pretty simple and required for 0223 (or > else the XEP wont work). PR#556 is a more fundamental change but > arguably the 'saner' choice. From a ‘not breaking xep60’ point of view, could one reasonably argue that the latter is equivalent in effect to registering a whole load of publish options, which implementations must be happy with already? /K ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
