Re: [Standards] Response Stream Namespace Qualification

[Mike Wacker]

On 2/13/2012 7:17 PM, Peter Saint-Andre wrote:
It's not clear to me what you intend the behavior of such clients to 
be. When you say "expect that some clients would assume...", does that 
assumption have behavioral implications (e.g., return an error if the 
streams are not qualified consistently)? 
I wasn't thinking all the way down to error behavior, but if the client 
assumes the streams are qualified consistently, it may ignore the 
response stream header and just assume it's qualified the same way as 
the initial stream header. And then if they are qualified differently, 
but the client assumes they are qualified the same, that mismatch would 
likely cause the client to think it's received not-well-formed XML. I 
wanted a second opinion on how much I should worry about that.


I don't have any strong opinions either way concerning whether the 
client should explicitly check if they are qualified consistently and 
whether it should return an error if they are not.

[Standards] Response Stream Namespace Qualification

[Mike Wacker]

I saw this excerpt in RFC 6120, 4.8.2: An entity MAY declare a "content 
namespace" as the default namespace for data sent over the stream (i.e., 
data other than elements qualified by the stream namespace). If so, (1) 
the content namespace MUST be other than the stream namespace, and (2) 
the content namespace MUST be the same for the initial stream and the 
response stream so that both streams are qualified consistently. The 
content namespace applies to all first-level child elements sent over 
the stream unless explicitly qualified by another namespace (i.e., the 
content namespace is the default namespace).


Reading that section, it suggests that the initial and response stream 
should always be qualified consistently, not just if the initiating 
entity declares a content namespace (e.g.: if the initial stream uses 
the stream namespace as the default namespace, then so should the 
response stream). However, this section on content namespaces is the 
only time the RFC mentions anything about qualifying the two streams 
consistently. If they are supposed to be qualified consistently, SHOULD 
or MUST they be qualified consistently?


More importantly, would it be reasonable to expect that some clients 
would assume the initial and response streams are qualified in the same 
way instead of checking the stream header of the response stream to see 
how the response stream is qualified (in case it's qualified differently 
than the initial stream)?

Re: [Standards] Security Question with

[Mike Wacker]

On 1/24/2012 8:41 PM, Evgeniy Khramtsov wrote:

On 25.01.2012 09:30, Mike Wacker wrote:

I saw this in RFC 6120:

"To reduce the possibility of a denial-of-service attack, (a) the 
receiving entity SHOULD NOT close the stream with a  
stream error until after the confidentiality and integrity of the 
stream have been protected via TLS or an equivalent security layer 
(such as the SASL GSSAPI mechanism), and (b) the receiving entity MAY 
have a policy of following redirects only if it has authenticated the 
receiving entity. In addition, the initiating entity SHOULD abort the 
connection attempt after a certain number of successive redirects 
(e.g., at least 2 but no more than 5)."


Does anyone have any clarification to this section and the specific 
DoS threat if TLS (or authentication) does not happen before 
?




Indeed, what problem could occur with unauthenticated redirections?

I see, then it would be moreso a tampering threat than a DoS threat, no? 
So basically, I want to know that the server I'm connecting to is 
legitimate and that my connection is secure before I trust the contents 
of that redirect from the server.


Also, is there a typo in (b), it sounds like it should read "(b) the 
*initiating* entity MAY have a policy of following redirects only if it 
has authenticated the receiving entity"

[Standards] Security Question with

[Mike Wacker]

I saw this in RFC 6120:

"To reduce the possibility of a denial-of-service attack, (a) the 
receiving entity SHOULD NOT close the stream with a  
stream error until after the confidentiality and integrity of the stream 
have been protected via TLS or an equivalent security layer (such as the 
SASL GSSAPI mechanism), and (b) the receiving entity MAY have a policy 
of following redirects only if it has authenticated the receiving 
entity. In addition, the initiating entity SHOULD abort the connection 
attempt after a certain number of successive redirects (e.g., at least 2 
but no more than 5)."


Does anyone have any clarification to this section and the specific DoS 
threat if TLS (or authentication) does not happen before ?

Re: [Standards] Carbons

[Mike Wacker]

On 1/5/2012 10:30 AM, Dave Cridland wrote:

I think the arguments will be found in the archives.

XEP-0280 version 0.1 was marked as deferred on Jun 27, 2011, and then it 
was updated to version 0.2 on July 10, 2011, which introduced the 
wrapping. Between these two dates, I don't see any discussion about it 
on the standards mailing list, though there was some discussion about 
version 0.2 which led to version 0.3 one day later.


However, RFC 6120 defined what the to and from attributes mean, and an 
extension can't really change this - I think it breaks too many 
assumptions with third-party software such as guards and other Layer-7 
filtering devices. Such things do exist, and are deployed.


This would only apply to outbound messages. RFC 6120 allows inbound 
messages where the bare JID for 'to' matches but the full JID does not 
match.


For outbound messages, nothing explicitly says an extension MUST NOT do 
self fan-out (w/o wrapping the message) in addition to following the 
rules in RFCs 6120/1. But an implementation note in RFC 6120, 8.1.1.1 
seems to imply that the recipient's bare JID must match the bare JID in 
the stanza's 'to' attribute. It may not hurt to more explicitly spell 
this restriction out in somewhere other than an implementation note, 
since self fan-out is a legitimate use case (whereas sending the stanza 
to a random person is probably not a legitimate use case).


---

This also leads back to why I don't think we need to take a dependency 
on message forwarding. Forwarding is more "complex" because the 
forwarded recipient can be anyone, and the message can be forwarded at 
any time. Whereas with carbons, the only use case is for fan-out to 
other resources of the sender (or recipient if we wrap those carbons, 
too), and the carbons are delivered at the same time as the original 
message. The only use case for carbons, sender(/recipient) fan-out, is 
different than the expected use case for forwarding, forwarding to a 3rd 
party other than the sender or recipient. The business rules for message 
forwarding suggest that chat state notifications may be omitted, whereas 
the business rules for carbons intentionally keep them.


Thus, for carbons, it may make sense to use a more targeted, simpler 
solution. Not only would the UI experience be different for 3rd-party 
forwarding compared to fanout, but it would be unfortunate if carbons 
were stuck as an experimental XEP simply because the forwarding XEP was 
still experimental due to points of contention or use cases which are 
inapplicable to carbons.


As a client developer, of sorts, on occasion, I'd hate to have logic 
that tried to guess whether this was a message for me, or a message 
I'd sent to something else. I'd really hate it, actually.


I likely will concede the original point on a 'to' not matching your 
bare JID anyway, but strictly for carbons this wouldn't be an issue. 
Your filter would simply check both 'to' and 'from' for a matching bare 
JID instead of just the 'to'.

Re: [Standards] Carbons

[Mike Wacker]

On 1/5/2012 8:08 AM, Matthew Miller wrote:

On Jan 5, 2012, at 09:03, Mike Wacker wrote:


On 1/5/2012 7:43 AM, Matthew Miller wrote:

On Jan 5, 2012, at 08:41, Mike Wacker wrote:


On 1/5/2012 7:31 AM, Matthew Miller wrote:

On Jan 5, 2012, at 08:24, Mike Wacker wrote:



Let me suggest a bolder idea. Why do we need to wrap the carbons using Message 
Forwarding at all instead of just delivering the message stanzas as is? You 
will only receive these additional message carbons if your client supports 
carbons and enables carbons. Thus, if a client has carbons enabled, if it 
receives a message not sent to its bare JID or full JID (either a message from 
one of its other resources to a buddy or from a buddy to one of its other 
resources), it can reasonably infer that the message is a carbon.

The standard use cases for message carbons is to ensure that a given device 
will receive both sides of all conversations, and that use case is covered 
regardless of whether we wrap carbons or not. I can't think of any use case for 
the special wrapping logic, though.

This would greatly simplify the XEP (as well as eliminate a dependency on an 
experimental XEP more complex than message carbons itself), as servers would 
only have to route the messages and not modify them, and clients won't need 
special parsing logic for carbons.


The original version of XEP-0280 did just that.  However, while it appears to 
simplify the XEP, it complicated implementations.  It required routing 
ato a client that did not match the 'to', which raised a number 
of concerns among client and server implementers.

And I disagree that XEP-0297 is more complex than carbons.


- m&m
<http://goo.gl/LK55L>


Could you elaborate on those concerns? A client would only receive a message 
that did not match the 'to' if it had message carbons enabled. Thus, it would 
be reasonable that these clients would have special logic to handle such 
messages if it supported carbons and if it had them enabled. Clients not 
supporting message carbons do not need to make any changes.

The problem is not just with the clients; it's also with servers.  The server 
must route that message, and not every server implementation is readily 
prepared to deal with that radical of a departure for standard XMPP routing 
rules.


- m&m
<http://goo.gl/LK55L>


Perhaps an actual case could help elaborate, in theory, all you need to do is 
alter the routing logic and perhaps also alter some checks/assertions for 
messages which don't match the 'to' field. Neither seems prohibitively 
expensive. It doesn't seem that complex on the client either.

I'm just looking for a better rationale for it. If there's a client use case or 
user experience which requires the wrapping, then we definitely need it. If 
it's a task that can be offloaded from the server to the client, that is also a 
valid reason. But I'm not a huge fan of altering the message just to simplify 
server implementation details for a task that belongs to the server [routing].

Unless there's a really compelling cost or scalability reason, I prefer that we 
build the protocol around client use cases and user experiences instead of 
building it around the server implementation.

I appreciate your feedback, but completely disagree with your assessment.  I 
know there are others that disagree, because I made the change based on their 
feedback on this list.


- m&m
<http://goo.gl/LK55L>


Matthew,

I understand that you disagree, but I want to get a better understanding 
of your disagreement, in particular the server concerns. (Would I be 
right in assuming this decision is more server-driven than client-driven?)


First, I hope that we can agree that in the "ideal" world (though I 
acknowledge no world is ideal and that things like scalability don't 
grow on trees), the protocol should be designed around user experiences 
and client use cases, not server implementation details.


But it seems like we have two types of server implementations: those 
which can easily handle the change and those which cannot. For clients 
or servers which can easily handle the change, this message wrapping 
logic serves no useful purpose and is extra overhead. For servers which 
cannot easily handle the change, this change will have a significant 
effect in terms of reducing the implementation cost, but at a (smaller) 
cost expense to client and servers which can easily handle the change.


Mike

Re: [Standards] Carbons

[Mike Wacker]

On 1/5/2012 7:43 AM, Matthew Miller wrote:

On Jan 5, 2012, at 08:41, Mike Wacker wrote:


On 1/5/2012 7:31 AM, Matthew Miller wrote:

On Jan 5, 2012, at 08:24, Mike Wacker wrote:



Let me suggest a bolder idea. Why do we need to wrap the carbons using Message 
Forwarding at all instead of just delivering the message stanzas as is? You 
will only receive these additional message carbons if your client supports 
carbons and enables carbons. Thus, if a client has carbons enabled, if it 
receives a message not sent to its bare JID or full JID (either a message from 
one of its other resources to a buddy or from a buddy to one of its other 
resources), it can reasonably infer that the message is a carbon.

The standard use cases for message carbons is to ensure that a given device 
will receive both sides of all conversations, and that use case is covered 
regardless of whether we wrap carbons or not. I can't think of any use case for 
the special wrapping logic, though.

This would greatly simplify the XEP (as well as eliminate a dependency on an 
experimental XEP more complex than message carbons itself), as servers would 
only have to route the messages and not modify them, and clients won't need 
special parsing logic for carbons.


The original version of XEP-0280 did just that.  However, while it appears to 
simplify the XEP, it complicated implementations.  It required routing 
a   to a client that did not match the 'to', which raised a number of 
concerns among client and server implementers.

And I disagree that XEP-0297 is more complex than carbons.


- m&m
<http://goo.gl/LK55L>


Could you elaborate on those concerns? A client would only receive a message 
that did not match the 'to' if it had message carbons enabled. Thus, it would 
be reasonable that these clients would have special logic to handle such 
messages if it supported carbons and if it had them enabled. Clients not 
supporting message carbons do not need to make any changes.

The problem is not just with the clients; it's also with servers.  The server 
must route that message, and not every server implementation is readily 
prepared to deal with that radical of a departure for standard XMPP routing 
rules.


- m&m
<http://goo.gl/LK55L>

Perhaps an actual case could help elaborate, in theory, all you need to 
do is alter the routing logic and perhaps also alter some 
checks/assertions for messages which don't match the 'to' field. Neither 
seems prohibitively expensive. It doesn't seem that complex on the 
client either.


I'm just looking for a better rationale for it. If there's a client use 
case or user experience which requires the wrapping, then we definitely 
need it. If it's a task that can be offloaded from the server to the 
client, that is also a valid reason. But I'm not a huge fan of altering 
the message just to simplify server implementation details for a task 
that belongs to the server [routing].


Unless there's a really compelling cost or scalability reason, I prefer 
that we build the protocol around client use cases and user experiences 
instead of building it around the server implementation.

Re: [Standards] Carbons

[Mike Wacker]

On 1/5/2012 7:31 AM, Matthew Miller wrote:

On Jan 5, 2012, at 08:24, Mike Wacker wrote:



Let me suggest a bolder idea. Why do we need to wrap the carbons using Message 
Forwarding at all instead of just delivering the message stanzas as is? You 
will only receive these additional message carbons if your client supports 
carbons and enables carbons. Thus, if a client has carbons enabled, if it 
receives a message not sent to its bare JID or full JID (either a message from 
one of its other resources to a buddy or from a buddy to one of its other 
resources), it can reasonably infer that the message is a carbon.

The standard use cases for message carbons is to ensure that a given device 
will receive both sides of all conversations, and that use case is covered 
regardless of whether we wrap carbons or not. I can't think of any use case for 
the special wrapping logic, though.

This would greatly simplify the XEP (as well as eliminate a dependency on an 
experimental XEP more complex than message carbons itself), as servers would 
only have to route the messages and not modify them, and clients won't need 
special parsing logic for carbons.


The original version of XEP-0280 did just that.  However, while it appears to 
simplify the XEP, it complicated implementations.  It required routing 
a  to a client that did not match the 'to', which raised a number of 
concerns among client and server implementers.

And I disagree that XEP-0297 is more complex than carbons.


- m&m
<http://goo.gl/LK55L>

Could you elaborate on those concerns? A client would only receive a 
message that did not match the 'to' if it had message carbons enabled. 
Thus, it would be reasonable that these clients would have special logic 
to handle such messages if it supported carbons and if it had them 
enabled. Clients not supporting message carbons do not need to make any 
changes.

Re: [Standards] Carbons

[Mike Wacker]

On 1/4/2012 6:27 AM, Matthew Miller wrote:

On Jan 4, 2012, at 03:57, Kevin Smith wrote:


I've just been reading through the current version of
http://xmpp.org/extensions/xep-0280.html and have a couple of
comments:

In example 14, we have:

  

...
  


I think it makes more sense to have the forwarded payload inside the
received payload, instead of the reverse. I think this because the
forwarded message is a feature of the carbon, rather than the reverse
(Carbons depends on Forwarding, Forwarding doesn't depend on Carbons).


See my comment in the other thread.


Second is regarding
"Upon receiving an inbound or outbound gone chat state (as a carbon
copy) for a given conversation, that conversation SHOULD be removed
from user display"

I think we should be avoiding mandating (at least non-security
critical) UI features - I think this is a simple tweak from normative
'SHOULD' to 'is suggested' or similar.

/K

That's a fair suggestion.


- m&m


Let me suggest a bolder idea. Why do we need to wrap the carbons using 
Message Forwarding at all instead of just delivering the message stanzas 
as is? You will only receive these additional message carbons if your 
client supports carbons and enables carbons. Thus, if a client has 
carbons enabled, if it receives a message not sent to its bare JID or 
full JID (either a message from one of its other resources to a buddy or 
from a buddy to one of its other resources), it can reasonably infer 
that the message is a carbon.


The standard use cases for message carbons is to ensure that a given 
device will receive both sides of all conversations, and that use case 
is covered regardless of whether we wrap carbons or not. I can't think 
of any use case for the special wrapping logic, though.


This would greatly simplify the XEP (as well as eliminate a dependency 
on an experimental XEP more complex than message carbons itself), as 
servers would only have to route the messages and not modify them, and 
clients won't need special parsing logic for carbons.


Mike

Re: [Standards] Chat continuation on different device

[Mike Wacker]

On 12/30/2011 9:58 AM, Kevin Smith wrote:

On Wed, Dec 28, 2011 at 7:20 PM, Artur Hefczyc  wrote:

On Dec 24, 2011, at 10:32 AM, Kim Alvefur wrote:


On Fri, 2011-12-23 at 20:01 -0800, Artur Hefczyc wrote:

Hi,

I frequently switch IM client running on different devices (mobile, laptop, 
) and I would
love to have a feature to continue last chat with some recent chat messages 
displayed
on a new device. I have an idea how to implement it in the Tigase server and 
our mobile
client (described below) and I was wondering if there is any XEP which could 
aid in this
task from the protocol side.

XEP-0280: Message Carbons is also meant for this use case.


The idea is following:

1. User chats with a friend on one device
2. Server records and remembers somehow last chats (by thread id for example)
3. User switched devices and opens chat window with a friend in the second 
client
4. The client requests from the server last chat with this friend (we could add 
some
parameters here, like last chat not older than 10 minutes for example)
5. If there is no chat history the server returns an empty list, otherwise the 
server
returns a list of chat messages
6. The client displays messages received from the server and allows the user to
continue conversation.

The difference being that with Carbons you opt in to receiving all
messages as they are sent.

This does not solve the problem really. It causes a few problems:
1. First, when I talk on a desktop client I do not really want my battery 
drained on mobile
with constant messages sent to my mobile client.
2. It does not solve a problem in case when my mobile/desktop client is not 
running during
the chat and then I want to switch device and start a new client.

I think a simple XEP specifying: send me my chat history for the last thread 
would be good enough
and would solve both above cases.

Right, I started idly working on a spec for this, just to tie together
the various bits we already have (or almost have).

I wouldn't recommend using 136 for this, but MattJ's 136 replacement
is a reasonable way to do the bit you describe here - just say "Get me
the last hour's conversation" or whatever. I should clean this up and
submit it once the new archiving XEP's ready.

Carbons also has a place in the overall solution, I think - but mostly
on the desktop side so your desktop has a complete record of what's
going on.

/K

/K
Ultimately, I agree that message archiving will be the best way to 
accomplish this moving forward, whether it is accomplished via XEP-0136 
or some future replacement XEP. Even if we had a magic oracle that could 
always send your message to the correct available resource, that still 
does not solve the problem where you have just logged in the device you 
switched to, since that resource was unavailable when all prior messages 
were sent.


Any message archiving solutions will target two main scenarios:
1. Get me my recent chat history for all users for when I log in.
2. When I want to start chatting with a specific user, get me the last 
few chat message for a single user (potentially even if those messages 
happened long ago).


Message carbons are a useful fallback, though, and they can be a bit 
optimal since you don't need to make a round trip to fetch the archive 
from an external source.

Re: [Standards] Schemas in XEPs

[Mike Wacker]

On 12/9/2011 9:49 AM, Dave Cridland wrote:

On Fri Dec  9 17:35:47 2011, Hannes Tschofenig wrote:
Over the time I have gotten the impression that an XML schema is 
really a waste of time. It creates the illusion that there is 
something that provides help (to implementers and to those who read 
the specification) but in reality it doesn't.


Working on different specifications I later thought that the problem 
is with the readability and extensibility of the XML schema and then 
we switched to Relax NG in some IETF working groups. That turned to 
be a mistake as well. When it comes to extensibility a Relax NG 
schema is equally bad.


The extensibility mechanism of XML would prevent you from getting any 
meaningful validation anyway. So, validation isn't useful because 
more or less everything validates (after you add the extension points 
everywhere).


So, I believe we are doing fine without XML schema but with lots of 
examples. Implementers just look at examples.


Maybe you could therefore recommend not to use XML schemas (or Relax 
NG schemas).


Or at least move them out of the XEP itself, perhaps?

I think we vaguely require them, at present. I'd be happy with hosting 
them out of the XEP itself, which'd make them more obviously informative.


The XSF Board chair and the XMPP Council chair have been trying to 
figure out how we go about such a decision, and decided the best thing 
to do was seek consensus on the lists as a first step.


Dave.


Since I seemed to have re-opened this rather large can of worms, I'll 
offer my own thoughts. I have actually found the schemas to be useful, 
even though I understand their limitations. You just need to put their 
value in the proper context.


And even though they are not normative, there is still some sort of 
normative constraint for the XML, and to some extent the schemas do 
capture that. Here's an example from XEP-0045, 6.4 Discovering Room Items:


"These  elements are qualified by the disco#items namespace, not 
the muc namespace; this means that they cannot possess 'affiliation' or 
'role' attributes, for example."


One direction we could go with the schemas is to build schemas that will 
not capture every normative constraint, but will catch most violations. 
Not all invalid XML would be rejected by the schema, but valid XML would 
never be rejected by the schema.


This would assign some normative value to the schemas and help us from 
both a standards and interopability perspective. However, there will 
always be some rules that schemas cannot cleanly capture, and for those 
people will still need to read the RFCs and XEPs. (However, the one 
major obstacle to that approach would be extension attributes [see RFC 
6120, 8.4. Extended Content], though I don't know if there are any XEPs 
which actually use those.)

Re: [Standards] disco#info Results Ordering

[Mike Wacker]

On 12/8/2011 10:47 AM, Ralph Meijer wrote:

On 2011-08-12 10:37 , Mike Wacker wrote:
In all the examples I've seen in XEPs, disco#info results have been 
ordered like this:


[..]
The schema in XEP-0030 would at least imply an order for identities 
and features, but it has always been the case that those schema are 
descriptive, not normative.


I believe this is a mistake in the schema. It should probably use 
xs:all instead. In general we try to prevent dependence on order if at 
all possible.


--
ralphm


So the main takeaway, if I understand this correctly, would be that if 
even the schema implies an order, I shouldn't assume any particular 
order unless the RFC or XEP explicitly calls it out.


As another example, for RFC 6120, the client namespace in A.5 implies 
that while the "normal" content (, , and ) can 
come in any order for presence stanzas, all extended content must come 
after all "normal" content. But unless RFC 6120 specifically calls out 
that ordering constraint (and it doesn't as far as I can tell), the 
server should be able to handle, for example:


xaxmlns='http://jabber.org/protocol/caps'...>Vacation!


Mike

[Standards] disco#info Results Ordering

[Mike Wacker]

In all the examples I've seen in XEPs, disco#info results have been 
ordered like this:


1. identities
2. features
3. extensions

However, is that specific order required, or should I expect the info to 
come in any order? Here's an example disco#info result I've seen from an 
ejabbered server, where the extensions are instead between the 
identities and features:


category='pubsub' type='pep'/>name='ejabberd'/>type='result'>...[extensions]...var='http://jabber.org/protocol/commands'/>var='http://jabber.org/protocol/disco#info'/>...[more features]...


The schema in XEP-0030 would at least imply an order for identities and 
features, but it has always been the case that those schema are 
descriptive, not normative.

[Standards] XEP-0115 Feedback

[Mike Wacker]

(1) In 5.4. Processing Method, step 3.3 states, "If the response 
includes more than one service discovery identity with the same 
category/type/lang/name, consider the entire response to be ill-formed." 
Should that actually be category/type/lang instead? XEP-0030 states, 
"the  element MUST NOT include multiple  elements 
with the same category+type+xml:lang but with different 'name' values." 
Thus, the only change here would be that XEP-0115 disallows results 
which are already disallowed by XEP-0030.


(2) We may want to put a cautionary note in XEP-0128 about what should 
or should not be included as an extension. For example, if a client 
included a public encryption key in a disco#info response via service 
discovery extensions, and this key was different for each user (or 
resource), then every user would publish a different verification 
string, meaning that entity capabilities would perform no better than 
disco flooding for that given client.


If all users of a client would coalesce around a small subset of all 
possible values for any extensions added, then entity capabilities would 
still work as designed. However, I would argue IMHO that clients SHOULD 
NOT (or maybe even MUST NOT) introduce new information via service 
discovery extensions that would likely be different for each user or 
resource.


I'll save a longer rant about the tendency for developers to say, "Let's 
make XYZ extensible!" without considering, for example, the performance 
and/or security implications of such extensibility. This isn't the first 
context where I've seen extensibility potentially cause such issues, nor 
am I the first person to have such complaints :)

Re: [Standards] RFC 6121, Sec 3.1, 3.2, and 4.3.2

[Mike Wacker]

On 11/15/2011 10:22 AM, Dave Richards wrote:
Am I missing something or is there a bit of a hole in these sections 
regarding denying a subscription?


In 3.1.2 (subscription request outbound), the user's server pushes a 
roster entry containing "the potential contact with a subscription 
state of "none" and with notation that the subscription is pending".


In 3.2.3 (subscription cancellation inbound), the user's server is 
supposed to ignore the subscription cancellation unless "the contact 
is in the user's roster with subscription='to' or subscription='both'" 
 And a few lines later:  "Otherwise ... if the contact is in the 
user's roster with a subscription state other than those described in 
the foregoing check -- then the user's server MUST silently ignore the 
unsubscribed notification by not delivering it to the user, not 
modifying the user's roster, and not generating a roster push to the 
user's interested resources".


Seems like a subscription denial/rejection would never get processed 
on the user side.


3.1.6 (subscription approval inbound) talks about subscription 
none/from with pending out, which seems should also be considered in 
3.2.3.



In an unrelated issue, 4.3.2, #1 says to send "unsubscribed" if "the 
contact account does not exist or the user's bare JID is in the 
contact's roster with a subscription state other than "From", "From + 
Pending Out", or "Both"".  Seems like this should also be the case if 
the contact account exists but is not in the user's roster at all. 
 All other roster states are covered by available/unavailable, so it 
seems lack of a response would indicate that the account at least 
exists, which might be considered leaking information, as well as 
leaving the user with apparently a dead "to" subscription to the contact.



After a brief look I did not find any previous discussion of these, so 
if there is can someone please point me there?  If not, what do you think?



Thanks,

Dave Richards


You do seem to have a point there. From my understanding, there would be 
no unsubscribed presence stanza since the user never had an outbound 
subscription, only a pending request for an outbound subscription. 
However, there would have to be a roster push to all interested 
resources, since the roster state would change - specifically the 
ask='subscribe' attribute would be removed, although the subscription 
attribute would be 'none' both before and after the roster push.


Mike

Re: [Standards] I18N and disco#items

[Mike Wacker]

On 11/10/2011 1:38 PM, Matthew A. Miller wrote:

On Nov 10, 2011, at 12:51, Mike Wacker wrote:


On 11/9/2011 3:35 PM, Peter Saint-Andre wrote:

On 11/9/11 4:32 PM, Mike Wacker wrote:

Since an item node for a disco#items query has a name attribute for a
natural-language name, does that mean that item nodes should also have a
corresponding xml:lang attribute?

For disco#info queries, the potential need for an xml:lang attribute is
called out in XEP-0030, section 3.1 [Basic Protocol for disco#info]
(although it's never reference in the schema). But there's no mention of
xml:lang at all in section 4.1 [Basic Protocol for disco#items].
However, it wouldn't be too hard to find a context where the results of
a disco#items query would be displayed to the user, which would seem to
suggest internationalization is necessary here.

XMPP is an XML technology, thus xml:lang is allowed on any element. Naturally, 
we could add an example of that to XEP-0030.

Peter


4.4, Relationship Between an Entity and its Items, says that for one possible 
relationship, "Upon querying an entity (JID1) for items, one receives a list of 
items that cannot be addressed as JIDs; each associated item has its own JID+node, where 
each JID equals JID1 and each NodeID is unique."

But if we account for xml:lang, then we would potentially need multiple items 
with the same NodeID but different languages, meaning NodeID will not be unique 
if we want to localize the item. This is similar to disco#info where (category, 
type, xml:lang) is the uniqueness key for an identity.

That would be a rather significant change to a draft specification.  I know quite a few 
implementations that would break in there were a  and.

Unfortunately, I think we'll have to live with the inclusion of an xml:lang 
identifies the localization of that 'name' attribute value, but not extend it in the 
same way as.


- m&m
<http://goo.gl/LK55L>

Makes sense, a part of me though that may be the ultimate outcome, 
especially since XEP-0030 is already listed as Final. If there is a 
really compelling need to localize the item name into several languages, 
we would probably have to settle for an additional XEP to solve that 
problem. But until that day comes we can just let it be for now.


Still, it would be useful to keep this in mind should for future XEPs 
with natural-language text.


Mike

Re: [Standards] I18N and disco#items

[Mike Wacker]

On 11/9/2011 3:35 PM, Peter Saint-Andre wrote:

On 11/9/11 4:32 PM, Mike Wacker wrote:

Since an item node for a disco#items query has a name attribute for a
natural-language name, does that mean that item nodes should also have a
corresponding xml:lang attribute?

For disco#info queries, the potential need for an xml:lang attribute is
called out in XEP-0030, section 3.1 [Basic Protocol for disco#info]
(although it's never reference in the schema). But there's no mention of
xml:lang at all in section 4.1 [Basic Protocol for disco#items].
However, it wouldn't be too hard to find a context where the results of
a disco#items query would be displayed to the user, which would seem to
suggest internationalization is necessary here.


XMPP is an XML technology, thus xml:lang is allowed on any element. 
Naturally, we could add an example of that to XEP-0030.


Peter

4.4, Relationship Between an Entity and its Items, says that for one 
possible relationship, "Upon querying an entity (JID1) for items, one 
receives a list of items that cannot be addressed as JIDs; each 
associated item has its own JID+node, where each JID equals JID1 and 
each NodeID is unique."


But if we account for xml:lang, then we would potentially need multiple 
items with the same NodeID but different languages, meaning NodeID will 
not be unique if we want to localize the item. This is similar to 
disco#info where (category, type, xml:lang) is the uniqueness key for an 
identity.

[Standards] I18N and disco#items

[Mike Wacker]

Since an item node for a disco#items query has a name attribute for a 
natural-language name, does that mean that item nodes should also have a 
corresponding xml:lang attribute?


For disco#info queries, the potential need for an xml:lang attribute is 
called out in XEP-0030, section 3.1 [Basic Protocol for disco#info] 
(although it's never reference in the schema). But there's no mention of 
xml:lang at all in section 4.1 [Basic Protocol for disco#items]. 
However, it wouldn't be too hard to find a context where the results of 
a disco#items query would be displayed to the user, which would seem to 
suggest internationalization is necessary here.


Mike

Re: [Standards] XEP-0045 1.25rc7

[Mike Wacker]

On 10/3/2011 8:05 PM, Mike Wacker wrote:

I've checked a new provisional version of XEP-0045 into git...

Latest diff:

http://xmpp.org/extensions/diff/api/xep/0045/diff/1.25rc6/vs/1.25rc7

Diff from 1.24:

http://xmpp.org/extensions/diff/api/xep/0045/diff/1.24/vs/1.25rc7

Rendered version:

http://xmpp.org/extensions/tmp/xep-0045-1.25.html

Continued feedback would be appreciated.

/psa




It may help to include the full end-to-end flow for discovering 
component support for MUC. Unlike other features, MUC often must live on 
a separate domainpart (chat.shakespeare.lit) than the one an entity 
negotiates a stream with (shakespeare.lit); otherwise it would be 
impossible to tell if ha...@shakespeare.lit/pda is a full jid or a room 
jid.


In 6.1, the ha...@shakespeare.lit/pda send a disco#info request to 
chat.shakespeare.lit, but it never says how hag66 determined that 
chat.shakespeare.lit exists in the first place.


Doing some digging around in XEP-0030, it appears that the answer would 
be this:
1. ha...@shakespeare.lit/pda issues a disco#items request to 
shakespeare.lit. One of the items returned is chat.shakespeare.lit.
2. ha...@shakespeare.lit issues a disco#info request to each item 
returned in (1). The disco request to chat.shakespeare.lit returns the 
muc feature.


It might be helpful to list out those steps as well. In addition, I 
would assume that shakespeare.lit MUST NOT return the muc feature in a 
disco#info request, since it itself does not support the muc feature 
even though it has an item which supports the muc feature.


Mike

Re: [Standards] Time to look at anti-spam XEPs? [Fwd: Re: [Operators] Strange users]

[Mike Wacker]

On 10/12/2011 8:29 AM, Matthew Wild wrote:

On 12 October 2011 15:44, Kim Alvefur  wrote:

 Forwarded Message 

From: Mathias Ertl
Reply-to: XMPP Operators Group
To: operat...@xmpp.org
Subject: Re: [Operators] Strange users
Date: Wed, 12 Oct 2011 15:51:23 +0200


[...]

To make a long story short: I think we have a significant spamming problem on
jabber.

So, is it time to bring up the various anti-spam/abuse related XEPs?

No, it's not. XEPs are words, not action. The best way to properly
revive the XEPs and ensure they'll stay revived is to implement them.

I have some code for reporting already - if you're interested in
working on it then I can find it for you...

Regards,
Matthew
Agreed, I haven't looked at the XEPs for anti-spam, but if you determine 
that a user is a spammer, then just reject their login. If you determine 
that a message stanza is SPIM, just block it. I don't think we can cut a 
deal with the spammers to stop what they're doing until the community 
can converge on an anti-spam XEP.


With spim, spam, and abuse, a lot of times the difficult part is to 
identify the bad user or the bad stanza without accidentally denying 
service to legitimate users. An XEP is more useful for telling you what 
the standard procedure is for dealing with spam than telling you how to 
identify spam.


Mike

Re: [Standards] XEP-0045: Reserved Nicks and GC Compatibility

[Mike Wacker]

On 10/4/2011 10:14 AM, Peter Saint-Andre wrote:

On 10/3/11 5:11 PM, Mike Wacker wrote:

Hello,

One of the tenets of XEP-0045 is backwards-compatibility with groupchat
1.0.

Additional features do not necessarily introduce incompatibility. The
old "Groupchat 1.0" protocol had very few features.
Yes, a feature, for example, to request a unique nick would not create 
an incompatibility since old clients wouldn't use the feature. If you 
still let the client use any nick, it's backwards-compatible.


But if you locked down nicks and required the client to use the nick 
returned by the feature, you would impact a pre-existing scenario, 
entering a room.

I was wondering if reserved nicks break this tenet. XEP-0045 says
clients SHOULD first try to discover a reserved nick, if any, before
entering a room. However, the server MAY lock down nicks and return an
error if the reserved nick is not used. If it does lock down nicks, then
the client actually MUST (not SHOULD) check for a reserved nick before
entering the room, since using any other nick would cause an error.

Rooms with nick lockdown are typically deployed in very controlled
environments (e.g., military systems where each person must be
identified exactly as they are registered or authenticated).
Or an easy way to avoid dealing with nick conflicts. If you locked down 
nicks, you could also have a predetermined 1:1 mapping between nicks and 
bare jids that can be calculated either way with O(1) space. While there 
always expected use cases, I find it's generally not good to assume a 
feature would only be used in a certain way :)


But since the server can rewrite nicks, is it safe to say the client 
MUST gracefully handle this scenario? The one area where that causes 
concern for me is existing groupchat 1.0 clients, I obviously do not 
know how they would handle a nick rewrite.



I used the Wayback Machine to look at the old page about the groupchat
1.0 protocol and early versions of JEP-0045, and none of them indicate
support for discovering reserved nicks, meaning the client has to set
the nick instead.

Correct.


Thus, it seems like older clients, including
groupchat, would actually break if the server locked down nicks and
returned an error if the reserved nick was not used to enter a room.

So you couldn't join the room. Again, such rooms will be deployed in
very controlled environments.


(Though I don't know the history of groupchat other than what old docs
said, so someone can correct me if there's some missing piece here not
mentioned in the docs.)

RC7 for XEP-0045 1.25 allows servers to rewrite nicks. If a nick rewrite
does not break old groupchat clients, perhaps we should say the server
MUST rewrite the nick instead of returning an error if the nicks are
locked down and a nick other than the reserved one is used to enter the
room.

I do think that such an approach is more consistent with Postel's Law,
so I'll adjust the text accordingly.

Peter

Re: [Standards] XEP-0045 1.25rc7

[Mike Wacker]

On 10/4/2011 11:15 AM, Alexander Holler wrote:

If the server never times out a room that is created but not configured
and unlocked, then an easy DOS vector is to flood the server with room
creation requests but never configure any of the rooms. Since these
unconfigured rooms never time out, these creation requests will
eventually starve the server of resources. Throttling won't work here,
as it will slow but not stop the eventual starvation.

Two mitigations would be to either time-out unconfigured rooms or put a
cap on the number of unconfigured rooms a single user can create. You
could also have a max cap of total rooms for all users, but that also
has DOS implications because even if malicious users can't DOS the
server, they can DOS other users trying to create rooms if they can hit
the server cap.


Whats the difference between unconfigured and configured rooms?

It's as easy to DOS a server with configured rooms as with 
unconfigured rooms and it will cost a malicious client almost nothing 
to configure a room along with the creation.


Regards,

Alexander
Good call, Alexander, my initial line of inquiry began with the question 
of what if a malicious client intentionally did not configure the room, 
but configuring the room does not make the problem go away.


In fact, configured rooms present additional complications. If a user 
sends an occasional message to each room after its unlocked, this would 
also with little cost to the hacker would prevent the server from timing 
out and destroying the room due to inactivity.


Mike

Re: [Standards] XEP-0045 1.25rc7

[Mike Wacker]

On 10/3/2011 8:05 PM, Mike Wacker wrote:

I've checked a new provisional version of XEP-0045 into git...

Latest diff:

http://xmpp.org/extensions/diff/api/xep/0045/diff/1.25rc6/vs/1.25rc7

Diff from 1.24:

http://xmpp.org/extensions/diff/api/xep/0045/diff/1.24/vs/1.25rc7

Rendered version:

http://xmpp.org/extensions/tmp/xep-0045-1.25.html

Continued feedback would be appreciated.

/psa


Under 13.6, Denial of Service, we should also mention room creation. 
We've listed a lot of bad things that can be done in a room, but we've 
left out the room creation process itself.


For example, just like one could register a lot of nicks to deny use of 
them to others, one could also do the same with rooms if they send the 
initial presence stanza presence to create the room but don't configure 
it afterwards. We also say an implementation MAY set a timeout for 
initial configuration of a room once its created, but from a security 
point of view not setting a timeout could lead to resource starvation.


If the server never times out a room that is created but not configured 
and unlocked, then an easy DOS vector is to flood the server with room 
creation requests but never configure any of the rooms. Since these 
unconfigured rooms never time out, these creation requests will 
eventually starve the server of resources. Throttling won't work here, 
as it will slow but not stop the eventual starvation.


Two mitigations would be to either time-out unconfigured rooms or put a 
cap on the number of unconfigured rooms a single user can create. You 
could also have a max cap of total rooms for all users, but that also 
has DOS implications because even if malicious users can't DOS the 
server, they can DOS other users trying to create rooms if they can hit 
the server cap.


Mike

[Standards] XEP-0045: Reserved Nicks and GC Compatibility

[Mike Wacker]

Hello,

One of the tenets of XEP-0045 is backwards-compatibility with groupchat 
1.0. I was wondering if reserved nicks break this tenet. XEP-0045 says 
clients SHOULD first try to discover a reserved nick, if any, before 
entering a room. However, the server MAY lock down nicks and return an 
error if the reserved nick is not used. If it does lock down nicks, then 
the client actually MUST (not SHOULD) check for a reserved nick before 
entering the room, since using any other nick would cause an error.


I used the Wayback Machine to look at the old page about the groupchat 
1.0 protocol and early versions of JEP-0045, and none of them indicate 
support for discovering reserved nicks, meaning the client has to set 
the nick instead. Thus, it seems like older clients, including 
groupchat, would actually break if the server locked down nicks and 
returned an error if the reserved nick was not used to enter a room. 
(Though I don't know the history of groupchat other than what old docs 
said, so someone can correct me if there's some missing piece here not 
mentioned in the docs.)


RC7 for XEP-0045 1.25 allows servers to rewrite nicks. If a nick rewrite 
does not break old groupchat clients, perhaps we should say the server 
MUST rewrite the nick instead of returning an error if the nicks are 
locked down and a nick other than the reserved one is used to enter the 
room.


Mike