Re: [Standards] Dynamic Forms
I remembered that I promised to give this a more thorough review on list after voting for moving this to Experimental, since the Council had some concerns that will need to be addressed before this would be approved to advance to Draft (See http://logs.xmpp.org/council/131127/) 1) The primary concern is with how results are served. Currently, results always come back in an IQ of type 'result' and look like (details omitted for brevity): … … ... The problem is that this bypasses and duplicates the existing result/error functionality provided by IQs. At the same time, it also is introducing *Response elements for results, which isn't the pattern used by current XEPs. (My understanding is that this new pattern has been introduced in the recent IoT experimental XEPs in order to squeeze some extra bytes out of EXI compression.) The above examples could then look like: ... … 2) The secondary issue is the XDD session. Using sessionVariable feels very awkward and requires the introduction of a new form cancelation mechanism. One possible alternative would be something like: ... along with: ... ... There would then be no need for the new action, and canceling a form would be done via the existing form canceling behaviour: (It would have been nice if Data Forms had included an id for forms, but alas.) It may also be useful to mention that the relevant dynamic form sessions should also be ended when canceling a wrapping adhoc command session. 3) There was concern from Tobias regarding how dynamic form processing interferes with UI, as noted in section 3.2. He will need to respond with his concerns; it seems OK enough to me. // Switching to non-Draft blocking review Regarding the element names, I think we could drop 'form' from the names, since the namespace already states that we're dealing with xdata forms. I'd go with a set of elements like: submit (as replacement for formPostBack, since postBack already exists with different semantics) updated postBack readOnly notSame error All of that said, I think this XEP has a lot of good potential, and I have some use cases in mind that could make good use of it. — Lance signature.asc Description: Message signed with OpenPGP using GPGMail
Re: [Standards] BOSH patches
On 11-12-13 16:47, Christian Schudt wrote: Hi, > If both attributes have (now) fix values, why have them around anyway? First of all: it is a SHOULD, if you have good reasons to do something else, you can divert from it. Secondly the "(now)" is important: We can not make changes to BOSH that break current implementations. Winfried
Re: [Standards] BOSH patches
On Dec 11, 2013, at 9:41 AM, Christian Schudt wrote: >> In theory, more connections means less latency. In practice, anything more >> than 1 held connection (so a maximum of 2 requests) starts to violate the >> in-order delivery rules from RFC 6120. > > So, another argument, to completely remove "hold" and "requests", as they are > always 1 and 2 in practice? (See my other mail for the other arguments). If XEP-0124 were Experimental and not Draft, I would agree with you. But Draft raises a significant bar on breaking backwards compatibility. Removing these, while correct from an architectural purity perspective, would make existing implementations (of which there are many) non-conformant and therefore non-interoperable, with (at least in my opinion) little real benefit. In other words, I think the boat for that level of change has already sailed into the West beyond the realm of Men. - m&m Matthew A. Miller < http://goo.gl/LK55L > signature.asc Description: Message signed with OpenPGP using GPGMail
Re: [Standards] BOSH patches
> In theory, more connections means less latency. In practice, anything more > than 1 held connection (so a maximum of 2 requests) starts to violate the > in-order delivery rules from RFC 6120. So, another argument, to completely remove "hold" and "requests", as they are always 1 and 2 in practice? (See my other mail for the other arguments).
Re: [Standards] BOSH patches
On Dec 11, 2013, at 12:21 AM, Christian Schudt wrote:
> Hi,
>
> yes, "to" should be "from" in 7.2.
>
> Concerning the xs:positiveInteger:
> http://www.w3schools.com/schema/schema_dtypes_numeric.asp
> I am not really sure if a positiveInteger is unbound and an unsignedInt is
> limited to 32bit. I don't really understand the difference anyway.
> Still, unsignedLong feels more appropriate, no?
>
The official definition is at <
http://www.w3.org/TR/xmlschema-2/#positiveInteger >. It states that
positiveInteger is the infinite set {1, 2, 3, ...}.
To be pedantically correct, we'd have to define our own simpleType, derived
from positiveInteger, and upper bounded to (2^53)-1. Otherwise, since the
value can't be less than 1, positiveInteger is the most appropriate.
> Concerning the diagram:
> Thanks, it became more clear, but definitively should have more
> labels/legends. I thought the left side is the client and the right side is
> the connection manager.
>
I'll endeavor to construct that legend, but would not mind any assistance (-:
> Why can there be more than two concurrent connections ("requests") anyway?
> Or, what's the benefit, if you use, say 5. You said "you only ever need two
> connections".
> This is something I wondered, too, while implementing it.
>
In theory, more connections means less latency. In practice, anything more
than 1 held connection (so a maximum of 2 requests) starts to violate the
in-order delivery rules from RFC 6120.
- m&m
Matthew A. Miller
< http://goo.gl/LK55L >
signature.asc
Description: Message signed with OpenPGP using GPGMail
Re: [Standards] BOSH patches
Well, at least in Java I found it easier, if you could just setup a threed pool
with 2 fix threads instead of a variable thread pool, because then you have to
manage the number of concurrent connections/threads manually depending on the
"requests" attribute.
So, the number two makes more sense in theory, since it's enough to make BOSH
work. I can't think in theory how requests="3" would improve anything.
And it's easier in practice to implement (in my opinion).
So, effectively I see no point in allowing the requests attribute to take
arbitrary values > 2.
Similarily, the hold attribute.
1.10 says:
"If the client is not able to use HTTP Pipelining then this SHOULD be set to
"1"."
Since HTTP Pipelining has been removed now from 1.11, the value is always 1,
right?
And the requests attribute should always be one more than the hold attribute,
so it is always 2.
If both attributes have (now) fix values, why have them around anyway?
Christian
Am 11.12.2013 um 12:46 schrieb Winfried Tilanus:
> On 11-12-13 08:21, Christian Schudt wrote:
>
> Hi,
>
>> Why can there be more than two concurrent connections ("requests")
>> anyway? Or, what's the benefit, if you use, say 5. You said "you only
>> ever need two connections". This is something I wondered, too, while
>> implementing it.
>
> The only argument I have heard in favour of more than 2 connections is
> that it might be easier to implement in some cases. And in theory it
> opens the road to more concurrency. In practice more than 2 connections
> tend to break things in the situations where you really want to deploy BOSH.
>
> Winfried
Re: [Standards] Fwd: Minutes 2013-11-20
On Wed, Dec 11, 2013 at 3:07 PM, Ben Langfeld wrote: > It's now three weeks since this meeting. I havn't seen a vote from Tobias on > rayo-fax, or either of rayo-fax and rayo-cpa being published. > > Is there anything blocking these that I can help resolve? Tobias okayed these on 27th November. /K
Re: [Standards] Fwd: Minutes 2013-11-20
It's now three weeks since this meeting. I havn't seen a vote from Tobias on rayo-fax, or either of rayo-fax and rayo-cpa being published. Is there anything blocking these that I can help resolve? On 20 November 2013 12:39, Kevin Smith wrote: > FYI > > -- Forwarded message -- > From: Kevin Smith > Date: Wed, Nov 20, 2013 at 5:39 PM > Subject: Minutes 2013-11-20 > To: XMPP Council > > > Room logs: http://logs.xmpp.org/council/131120/ > > 1) Roll call > Matt, Tobias, Kev, Lance, Fippo present (Tobias leaves partway through) > > 2) - http://xmpp.org/extensions/inbox/rayo-cpa.html > Accept as experimental? > > Various misgivings, particularly around the use of presence, but everyone > okay with publishing. > > 3) - http://xmpp.org/extensions/inbox/rayo-fax.html > Accept as experimental? > > Similar misgivings to rayo-cpa. Lance, Fippo, Kev, Matt okay with > publishing. Tobias to vote onlist within a fortnight. > > (Tobias leaves here) > > 4) XEP-0071 (XHTML-IM) > Discussion on whether Council feels they'd accept modifications to add > table support, or if they'd accept an auxiliary XEP. General agreement that > a new XEP with discovery is desirable. > > 5) http://xmpp.org/extensions/inbox/eventlogging.html > > Discussion delayed until they latest version is available. > > 6) XEP-0134 (Design Guidelines) > Discussion about some of these being slightly dated. Peter volunteers to > update them. > > 7) Date of next meeting > 2013-11-27 16:10 UTC. > > 8) Any other business > BOSH updates to go on the agenda for next meeting. > Dynamic forms to go on the agenda for next meeting. > > Fini. > >
Re: [Standards] draft-nottingham-http-problem
On 09-12-13 12:29, Dave Cridland wrote: Hi, > http://tools.ietf.org/html/draft-nottingham-http-problem-05 Interesting. > this morning, and I wondered about its applicability to BOSH for fatal > errors at the XEP-0124 level. > > I don't think XEP-0124 really goes into much detail about error > responses - I confess to not having looked at the new version, though. When talking about BOSH, I think it is good to distinguish the HTTP request level, the BOSH-session level and the XMPP stream level. (The BOSH session glues the HTTP requests to a XMPP stream, but you know that already). XEP-0124 moved away from error responses on HTTP-level. When the client encounters an error on HTTP level, it can respond to it how it wants to it, but usually it means a misconfiguration and usually it is fatal. On the level of the BOSH session, there are BOSH error conditions and how to respond to them defined. The XMPP stream has of course its own stream errors and its own mechanisms to handle those. I hope I understand this draft and your remark correctly, but I see only very limited use of this draft in BOSH: On the HTTP level this draft may provide some useful information, mainly for debugging purposes. But I don't think it would be in the scope of XEP-0124 to deal with error conditions on the HTTP level. Of course connection managers, proxies etc, are free to respond in case of an errors on the HTTP-level as they seem fit. On the BOSH level the idea of machine readable error conditions may provide additional information about errors, but I don't know how useful it is: I never needed it. And IMHO it is best to respond to errors on the BOSH level on the BOSH level, not on the HTTP level. So if we feel the need to, we may incorporate it in XEP-0124 for handling BOSH errors. Winfried
Re: [Standards] BOSH patches
On 11-12-13 08:21, Christian Schudt wrote:
Hi,
> Why can there be more than two concurrent connections ("requests")
> anyway? Or, what's the benefit, if you use, say 5. You said "you only
> ever need two connections". This is something I wondered, too, while
> implementing it.
The only argument I have heard in favour of more than 2 connections is
that it might be easier to implement in some cases. And in theory it
opens the road to more concurrency. In practice more than 2 connections
tend to break things in the situations where you really want to deploy BOSH.
Winfried
Re: [Standards] BOSH patches
On 10-12-13 22:12, Peter Saint-Andre wrote: Hi, > Lance has sent me an updated patch, which I have applied. The diff > between 124rc1 and 124rc2 is here: > > http://xmpp.org/extensions/diff/api/xep/0124/diff/1.11rc1/vs/1.11rc2 In section 7.2 now the 'hold' attribute is both defined in the list of attributes that MUST be present and the list of attributes that SHOULD be present. What attributes should be on which list was discussed on summit #13, see also (for a very short summary): http://wiki.xmpp.org/web/BoshIssues#Session_Creation_Attributes_Too_Optional Proposed fix: Remove the 'hold' that is on the MUST-list and move 'requests' from the SHOULD-list to the MUST-list. (This also fixes the still open issue: "Session Creation Attributes Too Optional") Then for the overview the issues that were discussed at summit #13 and that are still open in 1.11rc2: (see: http://wiki.xmpp.org/web/BoshIssues ) XEP-124: Session Termination and Sending BOSH Errors (Winfried) Open Better explanation for "1 sometimes 2 HTTP sockets open" mechanism (M&M) patch incorporated Diagram needs a bit more labelling (M&M) Session Creation Attributes Too Optional Open (see above) Unclear Terminology (Winfried) Open XEP-206: 'secure' attribute (Bear) patch incorporated in XEP-0124 Note: the 'secure' attribute is still present in the examples of XEP-0206 HTTP-layer authentication and XMPP-layer authentication (Winfried / M&M) Open Unclear Terminology (Winfried) Open Winfried
Re: [Standards] BOSH patches
On 10-12-13 23:48, Matt Miller wrote: Hi, >> - The from attribute. I think it should be: "it MUST forward the >> identity to the client by including a 'from' attribute in a >> response" (instead of MAY), because the core spec says: >>> "For response stream headers in both client-to-server and >>> server-to-server communication, the receiving entity MUST >>> include the 'from' attribute" >>> (http://xmpp.org/rfcs/rfc6120.html#streams-attr-from) … just >>> to be conform. > > That seems like a reasonable request to me, but we might need more > feedback from implementers before changing that MAY to a MUST (or > even just a SHOULD). For a real BOSH connection manager, it ought > to be known immediately; for a BOSH-as-proxy, though ... maybe the > horribly implemented ones need the MAY. Also see the last lines of section 3 of XEP-0206: the connection manager is responsible for opening a stream to the server that is conform the rfc's. In the communication between the connection manager and the BOSH client, it states about 'from' and 'to': " or can use them for session management purposes specific to the connection manager implementation." So changing this also implements that a big change to XEP-0206 is needed. So I think it would be better to leave it as it is. Winfried
Re: [Standards] BOSH patches
On 10-12-13 23:46, Justin Karneges wrote: Hi Justin, > I'm curious, what's the rationale for the flip-flopping design? It seems > to me that we could have just used a long-polling loop for receiving > data, and then a normal request/response whenever we need to send data. > Not suggesting a change or anything, just wondering why the protocol > works the way it does. I was never part of the decision for flip-flopping, so I don't know what the original designer had in mind. But I can share my experience with long-polling versus BOSH. When I jumped into the HelpIM project, it was implemented with long-polling, like you described. We had lots of problems with the long living connection being terminated without the browser noticing it. Sometimes this was caused by exotic network, router and routing issues, sometimes by 'just' an unstable connection. Though the long-polling design can be made resilient against such problems, the implementation becomes easier once you move to a flip-flopping design. Almost al safeguards are already in the flip-flopping. So you don't need an extra layer for error detection and correction. Right now we are using BOSH tuned such that the waiting time of the client before opening a new (empty) connection to the server is slightly shorter then the BOSH time out of the server. Like that we could very easily make the system far more resilient against connection problems then we ever managed while using long polling. Winfried
Re: [Standards] BOSH patches
On 10-12-13 22:12, Peter Saint-Andre wrote: Hi, > Lance has sent me an updated patch, which I have applied. The diff > between 124rc1 and 124rc2 is here: > > http://xmpp.org/extensions/diff/api/xep/0124/diff/1.11rc1/vs/1.11rc2 Thank you, Lance & Peter Winfried
Re: [Standards] eventlogging xeps
Yes, it is better now. -Teemu 2013/12/10 Peter Waher : > Hello Teemu > > Thanks for the feedback. The description in §7.3.2 was perhaps a bit > minimalistic. I extended it as follows: > > Event messages could be published using Publish-Subscribe. Unless there's > absolute control of who can subscribe to the information published in this > manner, the information should be considered open and freely available. In > such cases extra care should be taken to not publish information of a > sensitive nature, or information that can be mined for information, behavior > patterns, trends, etc., that can be viewed as being of a sensitive nature. If > there's a risk that either absolute control cannot be achieved and > information is of a sensitive nature, this pattern should be avoided. > > Ok? > > Best regards, > Peter Waher > > > -Original Message- > From: Teemu Väisänen [mailto:uol...@gmail.com] > Sent: den 10 december 2013 14:37 > To: XMPP Standards; Peter Waher > Subject: Re: [Standards] eventlogging xeps > > Hi Peter. > > Section 7.3.2 Publish/Subscribe describes: "Event messages could be published > using Publish-Subscribe. But, even more care should be taken to log only > information that can be published openly. If there's risk for sensitive > information to be logged, the publish/subscribe pattern should be avoided." > > If information is sensitive, the information should not be logged, as said in > 7.2. Do you mean that if sensitive information is still sent using pubsub, > there are more actors (pubsub server, subscribers) that might log and/or leak > the sensitive information and because of that the pubsub pattern should be > avoided? > > Would it be wise to move the second line "But, even more care should be taken > to log only information that can be published openly.", e.g., to section 7.2. > because it relates also to other cases than pubsub? > > Could the last sentence be something more like: "If there's risk for > sensitive information to be logged, the publish/subscribe pattern should be > avoided in systems that contain any not trusted or any uncontrolled actors." > That is because we could have a setup where we have a trusted pubsub server > and we log (also) sensitive information in several trusted > subscribers/loggers. > > BR, Teemu > > - > No virus found in this message. > Checked by AVG - www.avg.com > Version: 2014.0.4259 / Virus Database: 3658/6904 - Release Date: 12/09/13
