from:"Mridul Muralidharan"


Mridul Muralidharan wrote:

Rachel Blackman wrote:

I don't think it's a modification, just a clarification.


As Rachel Blackman mentioned, this is a change of behavior between the
rfc's, and any client depending on this behavior will not be able to
work properly with existing servers - unless it adds the special case
(which is required currently).


As far as we know, no clients depends on this behavior.


The issue is that the bis clarified something not really covered in 
the RFC, and did so in a way which breaks functionality that some 
client users wanted (i.e., the ability to have themselves in their own 
roster and see themselves as online).  Thus, the functionality was no 
longer available on any server which read the bis and tried to 
implement ahead, OR on any server which just guessed and acted that 
way for the undefined case in the original RFC.


To get around this, clients have to special-case presence-handling 
code, or else risk Many Fine Bug Reports when users submit tickets of 
'I log in but I still show as offline in my own contact list!'  Please 
note that I have numerous Bugzilla tickets -- submitted in the course 
of a week, no less, and several with 'me too' additions from other 
testers -- all on that topic from when I pulled that special-case code 
from Astra to rework the presence/roster engine.


So, while I think putting yourself in your own roster is confusing and 
perhaps silly, we should recognize that at least some users desire 
this behavior.


Given this, I suggest that the implementation ideal is that the client 
should not have to special-case things.  No client that I know of 
reacts to an incoming presence packet from themselves in a harmful 
way, so at worst sending the packets is a tiny bit of extraneous 
data.  At best, it simply picks right up and just plain works if you 
are in your own roster.


The XMPP ideal is supposed to be simple clients, complex servers.  A 
noble goal, but one we increasingly slip away from.  In many cases -- 
Jingle, hash-based caps, etc. -- the added complexity is for a very 
good reason; in /this/ case, however, the added complexity is because 
the behavior is ill-defined (where defined at all) at present, and so 
in order to get the desired behavior you need special-case code to 
allow for different server implementations.


That is an easily fixed situation.  So, let's fix it! :)



bis spec made addition of own jid to roster an error, presence broadcast 
was already covered in 3921.


3921.Section 5.1.1 - "In addition, the user's server MUST broadcast 
initial presence from the user's new available resource to any of the 
user's existing available resources (if any)."
I think this is pretty clear in stating that presence is to be sent to 
existing resources 'if any' (and not the 'new available resource').


So this proposed change is a modification of the MUST clause.

If a) presence broadcast can result in an error being returned back to 
client (like 'too frequent updates', etc) when the presence broadcast 
'fails', b) there is a transformation of the presence stanza.
Both of which leads to a state mismatch between publisher and 
subscribers (so caps does not count :) ) : there is no usecase for 
ack'ing the presence to the publisher imo.


to be read as :
"... subscribers (so caps does not count :) ) : since this is not the 
case currently, there is no usecase for  ack'ing the presence to the 
publisher imo."


Apologies.

- Mridul




If we do have any usecases, then there can be a case made for this 
change imo.



The main concern I have with this proposal is essentially that : we will 
have bis compliant clients expecting this push, and thereby exhibiting 
some loss of functionality while interoperating with pre-bis servers.






when they talk to older servers (assuming they do something with this
presence status).


As far as I know, they don't.


If they dont, then why should we do this change ? :-)


It's not a change, it's a clarification!


More to the point, it is a /definition/.  Right now, there is no real 
definition.  The bis is proposed changes for the next version of the 
RFC; those in this discussion are proposing (at least, I know I am!) 
that the behavior should be defined as A (receive self-presence), 
rather than B (do not receive self-presence).





It looks pretty well defined in 3921 !
Maybe the language might be clarified better - but the flow is pretty 
clearly spelled out.



- Mridul

Re: [Standards] rfc3921bis: self-presence


Rachel Blackman wrote:

I don't think it's a modification, just a clarification.


As Rachel Blackman mentioned, this is a change of behavior between the
rfc's, and any client depending on this behavior will not be able to
work properly with existing servers - unless it adds the special case
(which is required currently).


As far as we know, no clients depends on this behavior.


The issue is that the bis clarified something not really covered in the 
RFC, and did so in a way which breaks functionality that some client 
users wanted (i.e., the ability to have themselves in their own roster 
and see themselves as online).  Thus, the functionality was no longer 
available on any server which read the bis and tried to implement ahead, 
OR on any server which just guessed and acted that way for the undefined 
case in the original RFC.


To get around this, clients have to special-case presence-handling code, 
or else risk Many Fine Bug Reports when users submit tickets of 'I log 
in but I still show as offline in my own contact list!'  Please note 
that I have numerous Bugzilla tickets -- submitted in the course of a 
week, no less, and several with 'me too' additions from other testers -- 
all on that topic from when I pulled that special-case code from Astra 
to rework the presence/roster engine.


So, while I think putting yourself in your own roster is confusing and 
perhaps silly, we should recognize that at least some users desire this 
behavior.


Given this, I suggest that the implementation ideal is that the client 
should not have to special-case things.  No client that I know of reacts 
to an incoming presence packet from themselves in a harmful way, so at 
worst sending the packets is a tiny bit of extraneous data.  At best, it 
simply picks right up and just plain works if you are in your own roster.


The XMPP ideal is supposed to be simple clients, complex servers.  A 
noble goal, but one we increasingly slip away from.  In many cases -- 
Jingle, hash-based caps, etc. -- the added complexity is for a very good 
reason; in /this/ case, however, the added complexity is because the 
behavior is ill-defined (where defined at all) at present, and so in 
order to get the desired behavior you need special-case code to allow 
for different server implementations.


That is an easily fixed situation.  So, let's fix it! :)



bis spec made addition of own jid to roster an error, presence broadcast 
was already covered in 3921.


3921.Section 5.1.1 - "In addition, the user's server MUST broadcast 
initial presence from the user's new available resource to any of the 
user's existing available resources (if any)."
I think this is pretty clear in stating that presence is to be sent to 
existing resources 'if any' (and not the 'new available resource').


So this proposed change is a modification of the MUST clause.

If a) presence broadcast can result in an error being returned back to 
client (like 'too frequent updates', etc) when the presence broadcast 
'fails', b) there is a transformation of the presence stanza.
Both of which leads to a state mismatch between publisher and 
subscribers (so caps does not count :) ) : there is no usecase for 
ack'ing the presence to the publisher imo.


If we do have any usecases, then there can be a case made for this 
change imo.



The main concern I have with this proposal is essentially that : we will 
have bis compliant clients expecting this push, and thereby exhibiting 
some loss of functionality while interoperating with pre-bis servers.






when they talk to older servers (assuming they do something with this
presence status).


As far as I know, they don't.


If they dont, then why should we do this change ? :-)


It's not a change, it's a clarification!


More to the point, it is a /definition/.  Right now, there is no real 
definition.  The bis is proposed changes for the next version of the 
RFC; those in this discussion are proposing (at least, I know I am!) 
that the behavior should be defined as A (receive self-presence), rather 
than B (do not receive self-presence).





It looks pretty well defined in 3921 !
Maybe the language might be clarified better - but the flow is pretty 
clearly spelled out.



- Mridul

Re: [Standards] rfc3921bis: self-presence


Peter Saint-Andre wrote:

Mridul Muralidharan wrote:

Peter Saint-Andre wrote:

Mridul Muralidharan wrote:

Peter Saint-Andre wrote:

But (2) seems OK. When you send presence to your server, your server
delivers that presence to all of your available resources. Consider a
user with two resources ("foo" and "bar") who then comes online with a
third resource ("baz").



[ ... to "foo" resource ... ]



[ ... to "bar" resource ... ]



[ ... to "baz" resource ... ]




Why should an entity need to get its own presence ack'ed from the server
? What is there a usecase for this ? Or is this a nice to have
modification just to make things easier ?

I don't think it's a modification, just a clarification.


As Rachel Blackman mentioned, this is a change of behavior between the
rfc's, and any client depending on this behavior will not be able to
work properly with existing servers - unless it adds the special case
(which is required currently).


As far as we know, no clients depends on this behavior.


There are way too many client and server deployments which already use
the existing behavior - that is presence is not sent to the publisher,
so we might want to weight against that when modifying this : since the
bis spec compliant client should be able to interop with existing
servers.

Yet note that in PEP, the publisher does receive the published item. Why
should the special "pubsub-like" data called network availability be any
different? The special-casing here seems odd.


If we were doing 3921 now, it might make sense to not special case it -
though imo it is useless to ack it back, since the server is expected
not to modify the presence in any way (unlike pubsub where you might
have other filters/server side processing in place).


Really? Section 7 of XEP-0115 shows otherwise:

   A server that is managing an entity's presence session MAY choose
   to optimize traffic through the server. In this case, the server
   MAY strip off redundant capabilities annotations. Because of this,
   receivers of annotations MUST NOT expect an annotation on every
   presence packet they receive.

Which to me is argument enough that you want to receive your own presence.



I dont think capabilities getting stripped is relevant to this 
discussion - definitions of which, just like resource presence, is 
already known to the publisher.

So that particular change server effects might not be very relevant imo.




Is it harmful for the "baz" resource to receive its self-presence? I
don't see a particular reason why the server needs to avoid sending
that. Would it confuse the client?

/psa

bis compliant clients will 'expect' this behavior - and so will break

How?


Assuming 'own presence' is used by bis-client (like showing itself as
online, etc), it will not do so unless server ack's the presence - which
will never happen for pre-bis servers.


But bis-clients can presumably be written in a smarter way. That's not
breakage. Breakage means older software doesn't work.


If the intention is to get bis clients to continue to work with pre-bis 
servers (thereby requiring them not to depend on this clarification), 
then I guess there wont be any issues.





when they talk to older servers (assuming they do something with this
presence status).

As far as I know, they don't.

If they dont, then why should we do this change ? :-)


It's not a change, it's a clarification!


I will need to change server to comply with this - server will be 
sending, and component/client receiving stanza's it was not used to.

Also, the server versions prior to this wont be doing any of this.

So the clarification results in server behavior, testcase and code 
change :-)





Actually in our client, we used to always special case this (when user
was in his roster - long story of how jid got there).


Reverse might also be the case - of existing clients breaking when they
get presence for their own jid (will they treat it as conflict ?)

We have a lot of speculation here from server developers. But the client
developers who have posted say "this is fine, we like it better". So why
all the worrying?


The problem is essentially because the bis compliant clients will have
issues with 3920/3921 servers if they expect server to ack presence for
same entity - if they depend on it (if they dont, then whether server
ack's or not is redundent).


Don't depend on it.

Peter




So essentially you are proposing something like this :
bis server's should send presence of presence to all resources 
(publisher included) - but publisher should depend on recieving its own 
presence since it could be a pre-bis server ?


That should be fine I guess ...

What happens for privacy list/block list enforcement btw ? Will the 
publisher expect to get an unavailable now ? (I dont recall if it 
already does).


- Mridul

Re: [Standards] message type='headline'


Peter Saint-Andre wrote:

Joe Hildebrand wrote:

As an aside to the discussion on priority ties, I think it would be cool
for us to have a defined mechanism for sending messages to all online
(non-negative priority) resources.  Message type='headline' has never
been fully exploited, nor terribly well-described, and I propose that we
co-opt it for this purpose.

The existing usage for headline messages is derived from a one-liner in
XEP-160, but I believe that the original intent was that headlines are
for transient notification.  If they were specified in 3921bis like this:


Messages with type headline addressed to a bare JID SHOULD be delivered
to all online resources that have not specified a negative presence
priority.  Messages of type headline SHOULD NOT be stored by the server
for later delivery.


Then I think we get some cool new functionality without breaking anything.


+1. This is consistent with the fact that many servers already do not
store headlines offline.

In the I-D, this text needs to be split into two places under "Server
Rules for Processing XML Stanzas" (specifically under Section 8.3 "Bare
JID at Local Domain"), as follows...

***

8.3.1.  Available Resources

   If there is at least one available resource, how the stanza shall be
   processed depends on the stanza type.

8.3.1.1.  Message

   For a message stanza of type "headline", the server SHOULD deliver
   the stanza to all available resources.

***

AND...

***

8.3.2.  No Available Resources

   If there are no available resources associated with the user, how the
   stanza shall be processed depends on the stanza type.

8.3.2.1.  Message

   For a message stanza of type "headline", the server SHOULD NOT store
   the stanza on behalf of the user and deliver it when the user next
   becomes available, but instead SHOULD either forward the stanza to
   the user via a non-XMPP messaging system (e.g., to the user's email
   account) or return a  stanza error to the
   sender.




How to handle a headline message when there are no available resources - 
should we not just have a reference to AMP spec and leave it at that ?

How it gets handled might be impl detail, or based on AMP.


- Mridul


***

Peter

Re: [Standards] rfc3921bis: self-presence


Peter Saint-Andre wrote:

Mridul Muralidharan wrote:

Peter Saint-Andre wrote:

The old "xmppbis" page [1] had the following note:

***

It is unnecessary, potentially confusing, and not recommended to add
your own JID to your roster. However, RFC 3921 currently does not talk
about how a server should handle such "self roster items" if they exist.
The spec should probably specify that a server MUST NOT send presence
probes to self roster items, since the server already knows that the
entity is online once it receives initial presence from a specific
resource. Thus a resource should never receive presence information
about itself from its own server, although it will receive presence
information about other available resources for that entity as currently
specified in RFC 3921.

***

This conflates two issues: (1) adding yourself to your roster and (2)
receiving presence from your "self" resource.

IIRC we had list consensus that (1) is something we want to discourage.


2.3.2 talks specifically not allowing user to add his own bare jid to
the roster (as a MUST).


You don't add yourself to your roster, but still you get presence from
your other available resources. Roster and presence are separate things.



Yes, I was referring to (1) above, not (2).
(1) would be a MUST violation.




But (2) seems OK. When you send presence to your server, your server
delivers that presence to all of your available resources. Consider a
user with two resources ("foo" and "bar") who then comes online with a
third resource ("baz").



[ ... to "foo" resource ... ]



[ ... to "bar" resource ... ]



[ ... to "baz" resource ... ]





Why should an entity need to get its own presence ack'ed from the server
? What is there a usecase for this ? Or is this a nice to have
modification just to make things easier ?


I don't think it's a modification, just a clarification.



As Rachel Blackman mentioned, this is a change of behavior between the 
rfc's, and any client depending on this behavior will not be able to 
work properly with existing servers - unless it adds the special case 
(which is required currently).





There are way too many client and server deployments which already use
the existing behavior - that is presence is not sent to the publisher,
so we might want to weight against that when modifying this : since the
bis spec compliant client should be able to interop with existing servers.


Yet note that in PEP, the publisher does receive the published item. Why
should the special "pubsub-like" data called network availability be any
different? The special-casing here seems odd.



If we were doing 3921 now, it might make sense to not special case it - 
though imo it is useless to ack it back, since the server is expected 
not to modify the presence in any way (unlike pubsub where you might 
have other filters/server side processing in place).





Is it harmful for the "baz" resource to receive its self-presence? I
don't see a particular reason why the server needs to avoid sending
that. Would it confuse the client?

/psa


bis compliant clients will 'expect' this behavior - and so will break


How?



Assuming 'own presence' is used by bis-client (like showing itself as 
online, etc), it will not do so unless server ack's the presence - which 
will never happen for pre-bis servers.






when they talk to older servers (assuming they do something with this
presence status).


As far as I know, they don't.


If they dont, then why should we do this change ? :-)
Actually in our client, we used to always special case this (when user 
was in his roster - long story of how jid got there).





Reverse might also be the case - of existing clients breaking when they
get presence for their own jid (will they treat it as conflict ?)


We have a lot of speculation here from server developers. But the client
developers who have posted say "this is fine, we like it better". So why
all the worrying?



The problem is essentially because the bis compliant clients will have 
issues with 3920/3921 servers if they expect server to ack presence for 
same entity - if they depend on it (if they dont, then whether server 
ack's or not is redundent).
This is not the behavior for atleast a few servers (including our own) 
right now.


Mridul



Peter

Re: [Standards] rfc3921bis: self-presence


Peter Saint-Andre wrote:

The old "xmppbis" page [1] had the following note:

***

It is unnecessary, potentially confusing, and not recommended to add
your own JID to your roster. However, RFC 3921 currently does not talk
about how a server should handle such "self roster items" if they exist.
The spec should probably specify that a server MUST NOT send presence
probes to self roster items, since the server already knows that the
entity is online once it receives initial presence from a specific
resource. Thus a resource should never receive presence information
about itself from its own server, although it will receive presence
information about other available resources for that entity as currently
specified in RFC 3921.

***

This conflates two issues: (1) adding yourself to your roster and (2)
receiving presence from your "self" resource.

IIRC we had list consensus that (1) is something we want to discourage.



2.3.2 talks specifically not allowing user to add his own bare jid to 
the roster (as a MUST).




But (2) seems OK. When you send presence to your server, your server
delivers that presence to all of your available resources. Consider a
user with two resources ("foo" and "bar") who then comes online with a
third resource ("baz").



[ ... to "foo" resource ... ]



[ ... to "bar" resource ... ]



[ ... to "baz" resource ... ]






Why should an entity need to get its own presence ack'ed from the server 
? What is there a usecase for this ? Or is this a nice to have 
modification just to make things easier ?


There are way too many client and server deployments which already use 
the existing behavior - that is presence is not sent to the publisher, 
so we might want to weight against that when modifying this : since the 
bis spec compliant client should be able to interop with existing servers.







Is it harmful for the "baz" resource to receive its self-presence? I
don't see a particular reason why the server needs to avoid sending
that. Would it confuse the client?

/psa



bis compliant clients will 'expect' this behavior - and so will break 
when they talk to older servers (assuming they do something with this 
presence status).
Reverse might also be the case - of existing clients breaking when they 
get presence for their own jid (will they treat it as conflict ?)


Regards,
Mridul



PS: I remember getting this clarified with Peter a while back - and he 
indicated that resource will not get its own presence ack'ed to it :)




[1] http://www.xmpp.org/xmppbis.html

Re: [Standards] XEP-0138 vs. TLS compression


Jonathan Chayce Dickinson wrote:

Fletcher, Boyd C. CIV US USJFCOM JFL J9935 wrote:
Speaking of compression, I think we should consider adding the w3's 
efficient xml interchange (exi) support to xep-138. The testing 
results I've seen for EXI indicate that in many circumstances it is 
quite a bit better than zlib or tls compression. In addition to better 
b/w utilization use of exi within the xmpp router could potentially 
lead to dramatically improved scalability as binary xml is far more 
efficient to process.


Interesting note on what I was trying to get at with DIME.

"7.1.1 Binary

Values typed as Binary are represented as a length-prefixed sequence of 
octets representing the binary content. The length is represented as an 
Unsigned Integer (see 7.1.6 Unsigned Integer)."


Suddenly it all becomes plausible. No need for Base64.




There are enough extensions to supporting binary content inband in xml, 
the point is about interoperability & adoption - not whether it can or 
cant be done.
A few specs have pulled this off like wbxml, etc ... and have wider 
adoption & implementation. I would really not quote DIME, etc in this 
context.


- Mridul






boyd


*snip*



Regards,
 Jonathan Dickinson

Re: [Standards] xep-0199 redundancy

2007-08-25 Thread Mridul Muralidharan



Hi,

  It might not be a good idea to use the full JID in the error response 
- can be used for leaking presence. (and clients should not respond to 
arbitrary ping requests - again, presence leak)


And if considered in this light, this response could be coming either 
from the actual connected resource, the server or an intermediary - 
while the pong would come from the actual destination.


- Mridul

Jonathan Dickinson wrote:

Hey All,

XEP-0199 defines that if a server or client does not support ping it 
should return the following stanza:


type='error'>

  
  

  


or

type='error'>

  
  

  


I beg, is that not the same as a pong? Shouldn't the server/client 
rather ignore the packet if it doesn't allow pings? Unless of course, 
the packet is structured as follows (as per XEP-0076):


type='get'>

  
  


Just a thought.

Cheers,
 Jonathan Dickinson

Re: [Standards] Draft to Final

2007-08-17 Thread Mridul Muralidharan


Peter Saint-Andre wrote:

Hi Mridul!

Mridul Muralidharan wrote:

Hi,

  A lot of these specs have seen quite radical change recently in
comparison to the 'lifetime' of the spec. 


If we don't try to push some of these forward, we never will. :)


+ 1 !



Naturally we won't try to do that until the spec in question is mature
and has been widely implemented. Part of why I included certain specs is
to determine how mature people think they are.


Particularly the PEP & CAPS
based specs.


In fact PEP hasn't changed since last September, although the
documentation has changed. We should probably wait until is has been
more widely implemented before we try to push it (and pubsub) to Final.
That might be more than a year from now.


The basic idea of pep has not changed for an year now, but the 
auto-create related issues, and corresponding changes to pubsub were 
thrashed out only recently ... and the need for another spec which can 
be used for private storage, etc.
It is quite likely that as adoption grows we will have more discussion 
and clarifications required - on both pep and pubsub changes.




You're right that XEP-0115 has undergone radical changes recently, but
given the strong agreement that the changes were a good thing, it would
not surprise me to see wide implementation of the updated version so
that we could think about advancing it to Final in about a year.

There are others which are fairly new (xmpp ping, 


Ping is so small and straightforward, and already so widely implemented,
that I think advancing it to Final in ~6 months might be reasonable.


It is small, true but I am not sure of how many server's use it 
currently, or support it.
I think because it was so small, lot of clients ended up adding it even 
before it was draft ... I am not very sure if most of the 
implementations use it 'properly' - that is, when to use it, how 
frequently to use it, etc.
Slugging in a namespace handler and a thread to blindly send it to 
server is not the only idea :-)





pep, caps, etc), or
lot of new changes have been added to them (pubsub, link local messaging).


I put pubsub and link-local in the ~12 month category. It's possible
they would be ready by then. Maybe longer.

What are the radical changes to link-local messaging?


iirc there was quite a bit of discussion about discovery and related 
aspects, and changes made to it. It is quite possible that as we look 
more into white boarding, there might be changes required to it in 
context of p2p editing ?
My impression was that we dont have enough adoption, and so multiple 
implementations, which can unearth potential issues with this spec.





None of these newer changes have undergone rigorous testing or have much
implementation experience.


That should happen in the next 6-12 months though.


You are optimistic :-) It will be good if we have as rapid adoption !
But more seriously, PEP & specs based on it add serious amount of value 
- so it will be good to standardize on them and deprecate the others 
which predated them (avatar being what I have been bugged with off late).





It might be a good idea to wait for a while before considering them for
pushing to final.


Yes, probably at least 6 months and more like 12-18. But I think it's
good to start thinking about this now.


Being in draft stage should be enough to start implementation with 
reasonable guarantees of stability - so yes, I agree with you that in 
12-18 months we should definitely be able to commit some of the above to 
final.





Then we have oob, ibb, muc, chat state notification, privacy lists ..
these have been fairly stable and have multiple interoperable
implementations .. seem like good candidates for becoming final.


Agreed on all counts there except IBB (how widely implemented is it?)
and perhaps privacy lists -- though interop testing will tell the tale
on that one I think.


Very true .. I know of only few clients and server which support ibb & 
privacy lists. But that is hardly because of lack of stability of specs 
... it is similar to pubsub I guess, the 'harder' it is, the lower the 
adoption :-)
(hmm, this does not make sense for ibb though - rate limiting penalties 
should be the cause there I guess : the iq based ibb should 'solve' that 
one)



Another spec I forgot to mention was httpbind (xep 124 & 206) - Ian has 
managed to keep the spec remarkably stable inspite the seemingly large 
change to it 'recently'. Those two together have quite a bit of 
adoption, multiple interoperable implementations.



Regards,
Mridul



Peter

Re: [Standards] Draft to Final

2007-08-17 Thread Mridul Muralidharan


Hi,

  A lot of these specs have seen quite radical change recently in 
comparison to the 'lifetime' of the spec. Particularly the PEP & CAPS 
based specs.
There are others which are fairly new (xmpp ping, pep, caps, etc), or 
lot of new changes have been added to them (pubsub, link local messaging).


None of these newer changes have undergone rigorous testing or have much 
implementation experience.
It might be a good idea to wait for a while before considering them for 
pushing to final.


Then we have oob, ibb, muc, chat state notification, privacy lists .. 
these have been fairly stable and have multiple interoperable 
implementations .. seem like good candidates for becoming final.


Regards,
Mridul

Peter Saint-Andre wrote:

I think that we need to push more specs from Draft to Final. This will
require multiple implementations and some interop testing (preferably
via the online interop network  -- more on
that soon).

Here are some candidates for consideration in the next 6 months:

XEP-0012: Last Activity
  http://www.xmpp.org/extensions/xep-0012.html

XEP-0066: Out of Band Data
  http://www.xmpp.org/extensions/xep-0066.html

XEP-0080: User Location
  http://www.xmpp.org/extensions/xep-0080.html

XEP-0085: Chat State Notifications
  http://www.xmpp.org/extensions/xep-0085.html

XEP-0107: User Mood
  http://www.xmpp.org/extensions/xep-0107.html

XEP-0108: User Activity
  http://www.xmpp.org/extensions/xep-0108.html

XEP-0118: User Tune
  http://www.xmpp.org/extensions/xep-0118.html

XEP-0131: Stanza Headers and Internet Metadata
  http://www.xmpp.org/extensions/xep-0131.html

XEP-0138: Stream Compression
  http://www.xmpp.org/extensions/xep-0138.html

XEP-0199: XMPP Ping
  http://www.xmpp.org/extensions/xep-0199.html

XEP-0202: Entity Time
  http://www.xmpp.org/extensions/xep-0202.html

Here are some candidates for consideration in the next 12 months:

XEP-0016: Privacy Lists
  http://www.xmpp.org/extensions/xep-0016.html

XEP-0045: Multi-User Chat
  http://www.xmpp.org/extensions/xep-0045.html

XEP-0060: Publish-Subscribe
  http://www.xmpp.org/extensions/xep-0060.html

XEP-0115: Entity Capabilities
  http://www.xmpp.org/extensions/xep-0115.html

XEP-0174: Link-Local Messaging
  http://www.xmpp.org/extensions/xep-0174.html

Thoughts?

Peter

Re: [Standards] XEP-0124: which error if sid invalid?

2007-08-15 Thread Mridul Muralidharan



Hi Stefan,

Stefan Strigler wrote:

Hi, guess I hit a bug in xep-0124.

http://www.xmpp.org/extensions/xep-0124.html#errorstatus

states that 


"All HTTP codes except 200 have been superseded by Terminal Binding
Conditions to allow clients to determine whether the source of errors is
the connection manager application or an HTTP intermediary."

and

"If the client did not include a 'ver' attribute in its session creation
request then the connection manager SHOULD send a deprecated HTTP Error
Condition instead of this terminal binding condition."

But in the case that a given sid attribute is unknown or invalid a
connection manager can not determine if the session has been
instantiated with a 'ver' attribute for obvious reasons.


Intermediaries wont send a 404, which is what (i recall) the xep asks 
httpbind to send back in case of unknown/invalid sid. So we dont need to 
know the ver in this case (since httpbind assigns sid & not client, this 
is fine).
Hence if we get 404 for initial handshake request, it means httpbind is 
not running on that webserver/ctxroot, if we get 404 for any other 
request, it means session is not longer valid/exists.


So from what I see, this should not be a problem.
Or am I missing something here ?

- Mridul



Possible fixes that came to my mind:

* Define this to be a special case and demand to send an HTTP error
condition. Breaks with concept of separating error conditions at the
protocol level (you can't tell anymore whether the error is HTTP or BOSH
related).

* Make clients send a 'ver' attribute with every request. Consumes more
bandwidth.

Cheers, Steve

Re: [Standards] MUC message moderation

2007-08-09 Thread Mridul Muralidharan



Hi Peter,

  Please note that the submitted specs are based on what have been 
shipping for 2+ years now - so it is possible that subsequent xep's have 
come out with different or better idioms - we can definitely change for 
the better if it is consistent with the rest of the specs.


I have responses to the rest inline.

Thanks,
Mridul

Peter Saint-Andre wrote:

As promised, here are some questions and comments on the proposed MUC
message moderation specs:

http://www.xmpp.org/extensions/inbox/msg_moderate.html

http://www.xmpp.org/extensions/inbox/room_moderator.html


1. I think it makes sense to combine the two specs into one, with
separate sections for the occupant and moderator use cases.




The msg_moderate spec talks about occupant to room interaction - which 
is expected to be fairly stable across various moderation schemes.


room_moderator spec talks about one realization (profile ?) of message 
moderation where room moderators actively take up the role of message 
moderator - and component decides on this based on the role & affiliation.


While keeping the interaction between occupant and room stable, we could 
have other backend moderation interactions satisfying various other 
requirements - the occupant is agnostic to the actual moderation scheme.


Hence the split - since both are logically different functions.



2. What is the rationale for sending out state changes via presence from
the room's JID?

http://www.xmpp.org/extensions/inbox/msg_moderate.html#moderation-state

How will existing clients handle such state notifications?




The intention is for any occupant who does not understand the xep's to 
continue to function without any error - but with reduced functionality 
since they cant request for moderation.
I was not aware of these presence stanza's causing any problems - but we 
could very well change that to message or iq if they satisfy the same 
requirements.


Another alternative could be to discover if the client supports these 
xep's (disco ?) and the usecases and stanza's described in msg_moderate 
are applicable only to those.





I think we need to come up with a generic approach here. Perhaps the
authors of the message moderation proposal could collaborate with the
authors of the MUCOL proposal (not yet submitted)? They use IQs, not
presence.

http://www.wimba.com/labs/mucol/



mucol defines a way to using particular media like whiteboarding. In 
case of message moderation it is not a collaboration between 
participants of the room. The communication is between the 
user/moderator and room so probably we cannot co-relate them.





3. Why is the message sender forced to flag the message as intended for
moderation?

http://www.xmpp.org/extensions/inbox/msg_moderate.html#moderation-state

It seems to me that this forces the client to be smart about the state
of the room. Older clients may not be that smart, and in any case I
think the room (MUC service) can intelligently decide how to handle



The affiliation/role of an occupant which can make use msg_moderate spec 
is of one who does not have voice.
So, existing clients will not be able to send messages to the room 
currently, and they will not be expecting this ability (like no text 
area in client, etc).


This proposal enables these users to participate in the discussion - 
pending approval from moderator.
The intention here is to be explicit about exhibiting the fact that 
occupants are requesting for a moderated message submission - and due to 
the nature of submission, there are additional workflow and client side 
UI aspects which make use of this information.


For example, in our client how this works is like this:

By default if occupant has no voice, the textarea for submitting 
messages is not present. As soon as message moderation is enabled - a 
text area come up, along with a list of submitted messages and their 
status (pending, approved, rejected - with reason).


On submission of a message, it goes into the pending list - and stays 
there until room acts on it after moderator decision (which can be an 
extended amount of time).
So the user known about message moderation being active, and does not 
expect his message to show up in the room until approved.



So the moderation aspect is expected to be explicit - not implicit.
A particular client could hide these if required.


messages without forcing that intelligence on the sender. Also there is
a dependency here for the client to include an 'id' attribute, which
many clients do not. IMHO it would be good to enable the clients to be
fairly dumb in order to participate in a message-moderated MUC.




Use of id is optional.
Without using id, a client may not be able to disambiguate responses to 
two message submissions if they are rapid enough (that is, before 
component responds to both after recieving both).

Normally, this should not happen - hence optional.
Only requirement is - if present, room should ack it in the response.



4. If undelive

Re: [Standards] MUC rooms on roster.

2007-08-07 Thread Mridul Muralidharan


Peter Saint-Andre wrote:

Tomasz Sterna wrote:

I was talking with Grégoire Menuel (mu-conference developer) about
implementing Peter's idea of MUC rooms as items on the roster.

Basically the idea is to teach MUC component to answer to subscription
requests.
So when you add [EMAIL PROTECTED]/nick to the roster and send the
subscribe request, MUC server replies subscribed+subscribe to you. When
you accept, you have a room on the roster with subscription "both". Next
time you broadcast your presence, you automatically join the room.

There is a problem on the client side though.
How would client know, that the presence from [EMAIL PROTECTED]/* are from
room participants, not from many resources of [EMAIL PROTECTED] user (not
on roster, thus ignored).


Presumably the [EMAIL PROTECTED] could include entity capabilities so the
client knows this is a conference room?

/psa



This will not work in case the conference component or room is not 
'online' at that time.


Regards,
Mridul

Re: [Standards] IMML

2007-08-07 Thread Mridul Muralidharan


Peter Saint-Andre wrote:

Justin Karneges wrote:

On Monday 06 August 2007 5:33 am, Alex Jones wrote:

On Sun, 2007-08-05 at 20:05 -0700, Justin Karneges wrote:

On Sunday 05 August 2007 5:11 pm, Alex Jones wrote:

Hi list

I am intending to make an XEP of this. Is anyone interested in helping
me, as I haven't really got a clue how to write a proper specification.

http://spark.us.weej.net/~alex/temp/imml.html

Thanks!

XEP-71 (XHTML-IM), offers a subset of XHTML markup suitable for IM.  This
should be sufficient, don't you think?

No, for the reasons I specify in my text.
XEP-71 is XHTML-IM, not XHTML.  It is a reduced set of markup meant for IM, 
with security in mind, and this is essentially what you are proposing.


If your ideas have merit, then how about we apply them against XEP-71?  For 
example, if we don't want hyperlinks that trick you, we could require that 
all  hrefs have matching uri and child text in XEP-71.


IMHO that would be a good item to add to the security considerations in
XEP-0071.

I think XHTML-IM pretty much does what IMML does, but in a W3C-friendly
manner. If people want to support an even more reduced subset of XHTML
then I have no objections. I think clients can effectively do that via
XEP-0071. The baseline requirements are pretty minimal:

http://www.xmpp.org/extensions/xep-0071.html#profile-summary

If people want something even more minimal and texty, they could simply
use Textile or some other lightweight text formatting approach:

http://en.wikipedia.org/wiki/Comparison_of_lightweight_markup_languages

It seems that lots of Jabber clients already support things like *bold*
and /italic/ and _underline_ so perhaps that is enough...

/psa



The impression I got about what Alex described on jdev was that he 
wanted a way to completely separate the content from markup/other 
rendering attributes (and that he wanted a much more simpler markup ... 
I am not touching on that here :) ).


My impression was that this was already so for most of the case in 
XHTML-IM, except for the usual implicit rendering which happens - 
namely, use of _, /, *, emoticon (offhand, I cant think of anything else).


The first three already have tags within IM-XHTML, if we just add 
another tag to explicitly mark emoticons - and remove the implicit 
rendering completely - then Alex's baseline requirements should be done 
with IM-XHTML itself ?



Regards,
Mridul

Re: [Standards] summary: allowable characters

2007-08-05 Thread Mridul Muralidharan


Robin Redeker wrote:

On Sun, Aug 05, 2007 at 05:10:13AM +0530, Mridul Muralidharan wrote:

Robin Redeker wrote:

On Fri, Aug 03, 2007 at 04:29:15AM +0530, Mridul Muralidharan wrote:

Just mentioning a basic problem which was discussed at jdev.

If two 1.0 server move to 1.1, all the 'older' 1.0 jid's will become 
unroutable - which are present in user 
roster/affiliations/privacylists/etc.



Yes, this sounds like the death blow for escaping for backward
compatibility. It will poison the old 1.0 servers and make whole roster
subscriptions unusable once that server upgrades to 1.1. (Not to mention
the JIDs in the private XML storage or other places you mentioned).

Do you see any problem in just disallowing incompatible 1.1 JIDs to be
able to communicate with 1.0 JIDs? The old 1.0-compatible JID accounts
on a 1.1 server will of course still be able to talk with people on 1.0
servers.

The problem is 1.1 JID's cant communicate with 1.1 contact JID's -
if user has [EMAIL PROTECTED], what will the 1.1 server do ? It could 
either be pointing to a 1.1 [EMAIL PROTECTED] (route as-is), was a 1.0 
jid - convert to cont&[EMAIL PROTECTED] (needs transformation) or continues to 
be 1.0 [EMAIL PROTECTED] (route as-is) (all three as different cases, 
though 1 and 3 look the same).


I don't know exactly what you mean. There MUST NOT be done any escaping
between two 1.1 servers. So a 1.1 contact on server A and another 1.1
contact on server B are communicating nicely with each other. And also
the JIDs in their rosters will be a 1.1 JID.

Escaping only happens between 1.1 and 1.0 servers, and only on those
1.1 vs. 1.0 borders.

But the problem that we have then is that a 1.0 server, which will only
receive escaped JIDs, stores those (escaped) 1.1 JIDs in the 1.0 contacts
roster as escaped JIDs (because he doesn't even know they are escaped
JIDs!).

That means that after migration (1.0 server upgrades software to a 1.1
capable one) those JIDs are still in their escaped form in the roster.
And because there doesn't happen any escaping between 1.1 servers our
recently upgraded 1.0 server has broken rosters.


Yes, I am refering to this case above. 1.0 roster, 1.1 server.
It is not always practical to say - do full user data migration before 
moving to 1.1 (not always possible).





The network won't be split the day servers start speaking XMPP 1.1.
By preventing people with JIDs with incompatible characters to speak
with 1.0 servers the 1.1 servers can prevent that split.
Existing data will be present - and without jid meta-data, we cant 
associate encoding info.


One possible option would be to move to use uri scheme for jid's - (and 
so this could be the differentiator for 1.1 vs 1.0).

More importantly, it would help in case of interop with other protocols.

Last time I brought this up, it was considered a bit too disruptive, and 
so dropped :-) Since Peter was considering 1.1 of xmpp, maybe this would 
be a good time to rethink this idea !


You mean if a 1.1 server speaks with a 1.0 server it gives him an URL
instead of an escaped JID? How will 1.0 servers handle that? They will
have to code a little to handle that, don't they?


At the boundary, the 1.1 server will convert from/to uri form to current 
(1.0) form while talking to an 'older' (1.0) server, and will continue 
with uri form for a 1.1 server..


Mridul



(I like the idea of URLs btw., but changing a whole culture from their
JIDs to URIs will be quite hard I guess :-)


Robin

Re: [Standards] summary: allowable characters

2007-08-04 Thread Mridul Muralidharan


Robin Redeker wrote:

On Fri, Aug 03, 2007 at 04:29:15AM +0530, Mridul Muralidharan wrote:


Just mentioning a basic problem which was discussed at jdev.

If two 1.0 server move to 1.1, all the 'older' 1.0 jid's will become 
unroutable - which are present in user roster/affiliations/privacylists/etc.




Yes, this sounds like the death blow for escaping for backward
compatibility. It will poison the old 1.0 servers and make whole roster
subscriptions unusable once that server upgrades to 1.1. (Not to mention
the JIDs in the private XML storage or other places you mentioned).

Do you see any problem in just disallowing incompatible 1.1 JIDs to be
able to communicate with 1.0 JIDs? The old 1.0-compatible JID accounts
on a 1.1 server will of course still be able to talk with people on 1.0
servers.


The problem is 1.1 JID's cant communicate with 1.1 contact JID's -
if user has [EMAIL PROTECTED], what will the 1.1 server do ? It could 
either be pointing to a 1.1 [EMAIL PROTECTED] (route as-is), was a 1.0 
jid - convert to cont&[EMAIL PROTECTED] (needs transformation) or continues to 
be 1.0 [EMAIL PROTECTED] (route as-is) (all three as different cases, 
though 1 and 3 look the same).




The network won't be split the day servers start speaking XMPP 1.1.
By preventing people with JIDs with incompatible characters to speak
with 1.0 servers the 1.1 servers can prevent that split.


Existing data will be present - and without jid meta-data, we cant 
associate encoding info.


One possible option would be to move to use uri scheme for jid's - (and 
so this could be the differentiator for 1.1 vs 1.0).

More importantly, it would help in case of interop with other protocols.

Last time I brought this up, it was considered a bit too disruptive, and 
so dropped :-) Since Peter was considering 1.1 of xmpp, maybe this would 
be a good time to rethink this idea !



Regards,
Mridul



The 1.1<->1.0 gap will grow with people who want to use the new
characters in their JID, and hopefully the server administrators also
upgrade their servers at the same speed that these people come.

Clients would also have to take care whether they speak to a 1.0 or 1.1
server. A client error message like: "your server doesn't support these
characters in the JID, convince the admin to upgrade!" will maybe even
raise the pressure for admins a bit to upgrade :-)

The problem with forcing admins to upgrade I see here is that they are
maybe forced to upgrade to a unstable version or not so stable version
as they had before.



Robin

Re: [Standards] summary: allowable characters




Just mentioning a basic problem which was discussed at jdev.

If two 1.0 server move to 1.1, all the 'older' 1.0 jid's will become 
unroutable - which are present in user roster/affiliations/privacylists/etc.



Regards,
Mridul

Robin Redeker wrote:

(Warning, long mail ahead! Get a coffee and some time first :-)

On Thu, Aug 02, 2007 at 03:34:30PM -0600, Peter Saint-Andre wrote:

Mridul Muralidharan wrote:

The problem essentially is that any place where we have a JID persisted
in the backend (user roster, acl's, affiliations, privacy lists/block
lists, etc), it will become incompatible change.
For example, what used to be [EMAIL PROTECTED] will now become
contact&[EMAIL PROTECTED] - causing incompatibilities.

Well we're having a long discussion about this in the jdev room
right now:

http://www.jabber.org/muc-logs/[EMAIL PROTECTED]/2007-08-02.html

I volunteer elmex for posting a summary once we're done. :)


Yes, basically Mridul is completly right, we can't do much about the
already deployed backslashes in JIDs. Especially in 1.0 server rosters.

But...

First we have to wonder whethere there are actually people with
[EMAIL PROTECTED] in their roster, as registering a JID with a \ in
the username is a considerable problem with XMPP 1.0 servers with SASL
and DIGEST-MD5 (see some older message from me in the JID escaping
thread).

Of course that should be further investigaged as old-style IQ auth works
with [EMAIL PROTECTED] and also some jabberd2 servers allow
authentication as [EMAIL PROTECTED] without problems.

But there exists a possibility to migrate our old JIDs to the 1.1 world
and staying interoperable with 1.0 servers:

First: A 1.1 server that is going to communicate with 1.0 server will
escape the JIDs from his userbase when he SENDS to a 1.0 entity.
Escaping can be performed as described in XEP-0106 (after dropping the
silly \20 escaping rule).

That will work great if the 1.1 server has NO old userbase.

If we have for example jabber.org, a large userbase, and there is
actually [EMAIL PROTECTED] as registered user in. And we want to
upgrade to a 1.1 server then we will run into the problems Mridul
pointed out:

1.0 servers have [EMAIL PROTECTED] in their roster, and if we have
now 'stpeter @jabber.org' registering a new account he will collide with
that, because his JID will be escaped to the in the 1.0 servers roster
existing [EMAIL PROTECTED] Bang, we got a collision.

There exists no real easy way to prevent that except just not allowing
'stpeter @jabber.org' to register. To detect a case like this, that a
new user with a colliding JID registers, the 1.1 server needs to keep
track of the old JIDs in his database.

If the 1.1 server knows that [EMAIL PROTECTED] is a JID from the
pre-1.1 times, he can assume that [EMAIL PROTECTED] is already in
some rosters out there. So he MUST NOT allow anyone who might collide
with that to register at jabber.org after the migration to 1.1.

So when upgrading jabber.org could just mark all JIDs with a \ in their
name to be a pre-1.1 JID and disallow anyone to register who might
collide with one of the registered JIDs.

This way ' [EMAIL PROTECTED]' can register if no
'[EMAIL PROTECTED]' existed before (he knows that from his
database with the marks of old JIDs).

If ' [EMAIL PROTECTED]' now wants to talk with '[EMAIL PROTECTED]', it
would look like this:

   

As jabber.org (1.1) knows that chrome.pl (1.0) is in fact 1.0 he escapes
like XEP-0106 recommends and sends actually:

   

In [EMAIL PROTECTED]'s client will now popup a message from
"[EMAIL PROTECTED]" and except some weird JID he can talk with him.
Because if he sends a message back:

   

Then jabber.org will unescape the to-field and deliver the message to
' [EMAIL PROTECTED]'.

Of course this solution is not a perfect one for the end-users as I will
describe below, but I argue that the incompatibilities will increase
the pressure on developers a bit and on administrators to adapt XMPP
1.1. And thus that might speed up the migration while providing a
compatibility-workaround for maybr 98-99% of the cases, or maybe even
99,% (this needs to be investigated a big IMO, maybe my assumptions
are completly wrong).

So much for the server-to-server interoperability.



Now about 1.1 clients and 1.0 clients. 1.0 clients will have no way
to reach ' [EMAIL PROTECTED]', which is fine, either the user knows
that guy's JID needs to be escaped because he uses an old client, or he
has to upgrade to a client with 1.1 capabilities (what this means is
described below).

Not being able to send a message to ' [EMAIL PROTECTED]' will increase
the pressure on the client developers as stated above.
So 1.0 clients are basically out of luck if the user don't know how to
escape, however, tell em: "get a new c

Re: [Standards] Proposed XMPP Extension: Component Connections


Peter Saint-Andre wrote:

Mridul Muralidharan wrote:

XMPP Extensions Editor wrote:

The XMPP Extensions Editor has received a proposal for a new XEP.

Title: Component Connections

Abstract: This document specifies a standards-track XMPP protocol
extension that enables server components to connect to XMPP servers.

URL: http://www.xmpp.org/extensions/inbox/component.html

The XMPP Council will decide at its next meeting whether to accept
this proposal as an official XEP.


What exactly does binding a hostname mean ? Multiple component JID's
over the same stream ? If yes, why exactly do we need it ?


Think virtual hosts:

conference.jabber.org
conference.xmpp.org



Hmm, this is very tricky ground - and I am not sure if the proposal is 
considering a lot of aspects of hosted domains ...
For example, how does conference.jabber.org get associated with 
jabber.org virtual domain (so that users of jabber.org will be 
implicitly exposed to only this muc, not to conference.xmpp.org, etc).


I can understand the intention here - the way we handle this is slightly 
differently: the muc/pubsub/jud is part of the server, so the 
server/component 'knows' which hosted domain the client belongs to, and 
which hosted domain the conference should belong to, etc.


With an external component, this becomes really tricky without wildcard 
support of some sort - something like conference., etc.



Thinking more, to expose this sort of behavior, we will need a way for 
components to query for list of hosted domains (which would not be 
available in a lot of cases - it is typically lazily loaded (and subject 
to change at runtime), sometimes to the tune of 4k+ domains).


Typically, in our deployments, external components are not restricted to 
a domain - but are available to the whole deployment. We would expect 
impl specific acl's controlling which component is exposed to which 
hosted domain.





Etc.


Also, since there seems to be no restriction on what can be bound, it
can potentially bind valid s2s domains ... unlike the current component
jid which is preconfigured at the server.


Yes that needs to be specified more carefully.


Also, how would this interact with dix [1] ? Not sure of the state of
that submission - but just the support for multiple resources made it
very useful proposal.


Ask Chris Mullins. :)


Asked JD :)

Thanks,
Mridul



/psa

Re: [Standards] summary: allowable characters



Hi Peter,

Peter Saint-Andre wrote:

Mridul Muralidharan wrote:

Peter Saint-Andre wrote:

4. One solution would be to define version 2 of nodeprep in rfc3920bis.
As far as I can see, nodeprep2 would allow " & ' < > since those can be
escaped in XML (e.g., XMPP 'to' address) as the predefined entities
" & ' < >. I'm not sure why : was prohibited in the
first place so that would be allowed. I suppose / was prohibited because
it's used later in a full JID to differentiate the resource identifier,
but in a node identifier I don't think it would be confusing so that
would be allowed. 


user/[EMAIL PROTECTED] and domain/[EMAIL PROTECTED] cant be differentiated if / 
is
allowed.


Interesting, I think you're right. Consider "foo.com/[EMAIL PROTECTED]", it
could be the bare JID of a user "foo.com/bar" at jabber.org or a domain
of foo.com with a resource of "[EMAIL PROTECTED]". Not good.


Btw, changing nodeprep now will cause quite a lot of problem with
existing deployments - since the contact jid's are part of the user data
- and would pretty much mean we cant adopt bis spec.


What specifically breaks? Does it depend on which characters would be
allowed in nodeprep2? I agree that / and @ are problematic, but the
characters " & ' < > seem less so. But I may be missing something.



The problem essentially is that any place where we have a JID persisted 
in the backend (user roster, acl's, affiliations, privacy lists/block 
lists, etc), it will become incompatible change.
For example, what used to be [EMAIL PROTECTED] will now become 
contact&[EMAIL PROTECTED] - causing incompatibilities.



Regards,
Mridul





The number of deployments with these usecases are not as specialized as
it might seem.


I agree with that. Which is why I stand by XEP-0106. In part I think
that those who are so opposed to XEP-0106 are not familiar with the
deployment issues. But I agree that XEP-0106 needs to be clarified in
the ways we discussed recently. It's on my list to complete those
clarifications and post an interim version.

/psa

Re: [Standards] summary: allowable characters


Peter Saint-Andre wrote:

OK, we have had a long long discussion thread about JID Escaping and
nodeprep and allowable characters in JIDs etc. Here I summarize the
discussion and draw some conclusions for those of you who have checked
out. :)

1. Support for XEP-0106: JID Escaping (i.e., mapping of ' to \27 etc.)
is needed only in certain specialized deployment situations -- mainly
when an organization wants to reuse existing userids (e.g., email
addresses) or gateway to other messaging systems.

2. We needed to define JID escaping because version 1 of nodeprep (see
RFC 3920) prohibits including the characters SP " & ' / : < > @ in XMPP
node identifiers. (See also XEP-0029.)

3. IIRC we prohibited some of those characters because very early Jabber
clients didn't properly escape things like " & ' < > in XMPP 'to' and
'from' addresses.

4. One solution would be to define version 2 of nodeprep in rfc3920bis.
As far as I can see, nodeprep2 would allow " & ' < > since those can be
escaped in XML (e.g., XMPP 'to' address) as the predefined entities
" & ' < >. I'm not sure why : was prohibited in the
first place so that would be allowed. I suppose / was prohibited because
it's used later in a full JID to differentiate the resource identifier,
but in a node identifier I don't think it would be confusing so that
would be allowed. 



user/[EMAIL PROTECTED] and domain/[EMAIL PROTECTED] cant be differentiated if / is 
allowed.


Btw, changing nodeprep now will cause quite a lot of problem with 
existing deployments - since the contact jid's are part of the user data 
- and would pretty much mean we cant adopt bis spec.


The number of deployments with these usecases are not as specialized as 
it might seem.


- Mridul


Clearly we can't allow @ because we use that character
as a separator between the node identifier and the domain identifier. So
nodeprep2 would be the same as nodepre1 except that it would disallow
only the at-sign ("@"). (Naturally we can discuss this further...) As to
how it is discovered that a server supports nodeprep2, I will post a
separate message about that.

Peter

Re: [Standards] JID Escaping


Ralph Meijer wrote:

On Thu, 2007-08-02 at 17:21 +0200, Robin Redeker wrote:

It seems that at least the majority of the whidely deployed servers
support \ in JIDs in DIGEST-MD5 SASL authentication due to faulty SASL
DIGEST-MD5 implementations.

However, using the PLAIN authentication method seems to work!


Well yeah. As we discussed in the jdev room, the DIGEST-MD5 mechanism
keeps on piling up new issues. SASL lib devs are tired of its complexity
and incompatible implementations.

As was suggested in March in response to the unwillingness to go further
with the DIGEST-MD5 bis RFC (following RFC 4422), we should think about
dropping DIGEST-MD5 altogether in favour of something based around
SHA256, for example.

That said, I'm wondering if we should really try to go further with
general JID escaping. I'm sure in some edge cases, you would want to be
able to use apostrophes in user ids. But I think that that is rare. I've
never seen an e-mail address with an apostrophe.

Also, why go through all the effort to sync with e-mail addresses when
we have a far richer character repertoire in terms of non-latin
characters? Note that RFC2822 doesn't even allow umlauts, for example,
so you can never translate full names to usernames in either addressing
scheme.

Do we really need to have these extra characters?



Yes, we do.
I have mentioned quite a lot of instances where this is required.

- Mridul

Re: [Standards] Proposed XMPP Extension: Message Stanza Profiles

2007-08-01 Thread Mridul Muralidharan


Justin Karneges wrote:

On Wednesday 01 August 2007 10:10 am, Peter Saint-Andre wrote:

Michal 'vorner' Vaner wrote:

Hello

Wouldn't it be better to discourage _sending_ such messages instead of
recommending how to handle them?

At last a notice that sending such message is a bad thing (dumb clients,
whatever) anyway?

Yes, we need to add that. This is a very early draft and I'm looking for
Justin to provide some feedback, but I wanted to get something out there
for discussion.


Great to see this as a XEP.

First, the example 1 is an invalid message, and I don't think this is ever 
revealed.  I'd suggest putting the profile of example 1 after the rules in 
section 3.


We should probably have a set of example message stanzas where we state the 
profile next to each one.  Maybe this could be section 4.


The IM profile looks good.

The Data negotiation profile confuses me.  There are six specs listed in this 
section, and IMO these should be six separate profiles.  A question to ask 
yourself, for example, is if you'd mix Jabber-RPC and Stanza Session 
Negotiation.


I don't know if we should consider Transmission to be a profile.  Maybe it 
should be moved out of section 2.  Also, it is stated, "If a message stanza 
includes only transmission elements, it can be considered in the transmission 
profile."  I think in this case the message would rather be considered to 
have no profile.


I think Chat State Notifications falls under IM.


You can have chat state along with a body/xhtml - I thought the proposal 
said you cant have more than one element from a profile within a message ?


- Mridul



If a client receives a message stanza with no profile (this can occur if the 
stanza is actually empty, or contains only transmission elements and/or 
unknown elements), maybe we should define a  or such error 
code (or reuse a nearby code) for the client to bounce back.


It is possible for a client to determine conclusively that there is a profile 
conflict, if two types of differing profile elements that it understands 
happen to be present in the same message.  Maybe we should define an error 
code for this as well (not-acceptable?).


-Justin

Re: [Standards] Proposed XMPP Extension: Message Stanza Profiles

2007-08-01 Thread Mridul Muralidharan


XMPP Extensions Editor wrote:

The XMPP Extensions Editor has received a proposal for a new XEP.

Title: Message Stanza Profiles

Abstract: This document specifies best practices for handling extended content 
in XMPP message stanzas.

URL: http://www.xmpp.org/extensions/inbox/messageprofiles.html

The XMPP Council will decide at its next meeting whether to accept this 
proposal as an official XEP.



Might be a good idea to move the profile definition outside the xep.
So that future xep's can get added to the relevant profile without 
needing to change this proposal.

Maybe make it part of registrar in some way ?


Mridul

Re: [Standards] Proposed XMPP Extension: Component Connections

2007-07-31 Thread Mridul Muralidharan


XMPP Extensions Editor wrote:

The XMPP Extensions Editor has received a proposal for a new XEP.

Title: Component Connections

Abstract: This document specifies a standards-track XMPP protocol extension 
that enables server components to connect to XMPP servers.

URL: http://www.xmpp.org/extensions/inbox/component.html

The XMPP Council will decide at its next meeting whether to accept this 
proposal as an official XEP.



What exactly does binding a hostname mean ? Multiple component JID's 
over the same stream ? If yes, why exactly do we need it ?
Also, since there seems to be no restriction on what can be bound, it 
can potentially bind valid s2s domains ... unlike the current component 
jid which is preconfigured at the server.


Also, how would this interact with dix [1] ? Not sure of the state of 
that submission - but just the support for multiple resources made it 
very useful proposal.


Mridul

[1] http://www.xmpp.org/extensions/inbox/dix.html

Re: [Standards] JID Escaping


Mridul Muralidharan wrote:

Peter Saint-Andre wrote:

Mridul Muralidharan wrote:

Peter Saint-Andre wrote:

Mridul Muralidharan wrote:



For the server, this xep is required since its user population could
include users which have these prohibited characters in the uid .. and
so requires it to identify the backend user (hence need to 
standardize)

Well it's really required only if you have customers who want to port
existing UserIDs (e.g., email addresses) to JIDs.

Unfortunately, this is a very frequent deployment.


Personally I think this is fortunate -- organizations are rolling out


Unfortunate from point of view of xmpp nodeprep :-)
It is a necessary feature to support - especially when deployments tend 
to use single sign on (SSO) for all internal servers.



Jabber services to their large installed base of email users. Let's ask
ourselves how we can make that easier. Enabling those organizations to
map existing userids to JIDs makes sense. Saying "you can't re-use
existing userids so some of your users will need to have different
addresses or not use Jabber at all" makes no sense.

Email allows the following characters that are disallowed in JIDs (by
which I mean local-part of email address and node identifier portion of
JID):

&
'
/


There are lot of cases where email gets used 'as-is' also as xmpp node.
But there are other sso schemes where the other prohibited characters 
also can get used.




So IMHO the focus should be on those characters (the same mapping
applies to SIP addresses, which might be re-used in the same way that
email addresses are re-used, though I see that as less likely).

And again I ask, is that "gatewaying" or the automated construction of a
native XMPP address from an existing userid? I don't know that it makes
much of a difference really, but to me gatewaying is for exchange of
messages between different communication systems, not pure address
mapping to re-use userids.


It is not that is only mailid which has this issue - there are also SSO
mechanism of form [EMAIL PROTECTED]


But is [EMAIL PROTECTED] going to be re-used as an XMPP node identifier?


Yes.
Simple scenario - [EMAIL PROTECTED] approves [EMAIL PROTECTED] 
(note - same domain) subscription : for server to 'find out' the backend 
store for [EMAIL PROTECTED], it will need the whole uid - 'contact' by 
itself wont do : in a lot of cases, the server would have direct control 


*would not*

over the backend anyway, and will need to go through sso api which 
expect the full identifier for the users.


In the example above, I explicitly called it realm - though usually 
different realm's get mapped to different domains. It could have been 
anyother identifier which is global to the SSO system in place.



Regards,
Mridul



/psa

Re: [Standards] JID Escaping


Peter Saint-Andre wrote:

Mridul Muralidharan wrote:

Peter Saint-Andre wrote:

Mridul Muralidharan wrote:



For the server, this xep is required since its user population could
include users which have these prohibited characters in the uid .. and
so requires it to identify the backend user (hence need to standardize)

Well it's really required only if you have customers who want to port
existing UserIDs (e.g., email addresses) to JIDs.

Unfortunately, this is a very frequent deployment.


Personally I think this is fortunate -- organizations are rolling out


Unfortunate from point of view of xmpp nodeprep :-)
It is a necessary feature to support - especially when deployments tend 
to use single sign on (SSO) for all internal servers.



Jabber services to their large installed base of email users. Let's ask
ourselves how we can make that easier. Enabling those organizations to
map existing userids to JIDs makes sense. Saying "you can't re-use
existing userids so some of your users will need to have different
addresses or not use Jabber at all" makes no sense.

Email allows the following characters that are disallowed in JIDs (by
which I mean local-part of email address and node identifier portion of
JID):

&
'
/


There are lot of cases where email gets used 'as-is' also as xmpp node.
But there are other sso schemes where the other prohibited characters 
also can get used.




So IMHO the focus should be on those characters (the same mapping
applies to SIP addresses, which might be re-used in the same way that
email addresses are re-used, though I see that as less likely).

And again I ask, is that "gatewaying" or the automated construction of a
native XMPP address from an existing userid? I don't know that it makes
much of a difference really, but to me gatewaying is for exchange of
messages between different communication systems, not pure address
mapping to re-use userids.


It is not that is only mailid which has this issue - there are also SSO
mechanism of form [EMAIL PROTECTED]


But is [EMAIL PROTECTED] going to be re-used as an XMPP node identifier?


Yes.
Simple scenario - [EMAIL PROTECTED] approves [EMAIL PROTECTED] 
(note - same domain) subscription : for server to 'find out' the backend 
store for [EMAIL PROTECTED], it will need the whole uid - 'contact' by 
itself wont do : in a lot of cases, the server would have direct control 
over the backend anyway, and will need to go through sso api which 
expect the full identifier for the users.


In the example above, I explicitly called it realm - though usually 
different realm's get mapped to different domains. It could have been 
anyother identifier which is global to the SSO system in place.



Regards,
Mridul



/psa

Re: [Standards] JID Escaping


Peter Saint-Andre wrote:

Mridul Muralidharan wrote:


IMO, (un)escaping should only be done by the entities which need to do
so - we should not mix a routing construct with display.


Sure. We never mess with the routing. From the client perspective,
XEP-0106 is only for display purposes.


From a routing/resolution point of view, this xep makes a lot of sense.
There are much better and more unambiguous ways to handle display 
problem - nick, roster, jud, etc.





A client wishing to display contact should not use this xep - there are
better ways to obtain what is to be displayed, and unescaping node is
not the right way to go about showing 'who' the contact is.

The only real usecase I can see with this xep from clients point of view
is to construct a jid for authorization when the node would otherwise
contain prohibited characters.


Probably.

If XEP-0106 support were in all the clients, you could tell other people
that your JID is "tim.o'[EMAIL PROTECTED]" or whatever and things would
"just work". The problem is that JID (node) escaping support is not in
all the clients. :)


Allowing what is described above is going to hit too many edgecases 
where things cant be handled properly.
For example, [EMAIL PROTECTED] vs user\40id vs [EMAIL PROTECTED] vs 
[EMAIL PROTECTED]@defdomain], etc .


It would be preferable to keep both the aspects separate and stop trying 
to use this xep for display purpose. It cant do a good job of it anyway.





For the server, this xep is required since its user population could
include users which have these prohibited characters in the uid .. and
so requires it to identify the backend user (hence need to standardize)


Well it's really required only if you have customers who want to port
existing UserIDs (e.g., email addresses) to JIDs.


Unfortunately, this is a very frequent deployment.
It is not that is only mailid which has this issue - there are also SSO 
mechanism of form [EMAIL PROTECTED]



Regards,
Mridul




From a gateway's point of view - even if there is some other encoding
(urlencoding, etc), it does not matter - the rest of the system does not
depend on how the gateway encodes or decodes - ofcourse it helps to
standardize so that implementations dont end up with illegal nodes.


Correct.

/psa

Re: [Standards] JID Escaping


Peter Saint-Andre wrote:

Chris Mullins wrote:

PSA Wrote:
Perhaps it would help for us to define a "profile" 
of characters that we think are reasonable in 
native XMPP bare JIDs?

Down that route leads an insane array of international headaches! We may
be it right in English, but how about in Chinese? Or Arabic? Or Russian?
Hebrew? Korean? Esperanto? 


Well by "characters" I meant from among the short list of prohibited
characters, that is:

* U+0020 (" " or SP)
* U+0022 (")
* U+0026 (&)
* U+0027 (')
* U+002F (/)
* U+003A (:)
* U+003C (<)
* U+003E (>)
* U+0040 (@)

Everything else is fair game!

/psa




IMO, (un)escaping should only be done by the entities which need to do 
so - we should not mix a routing construct with display.
A client wishing to display contact should not use this xep - there are 
better ways to obtain what is to be displayed, and unescaping node is 
not the right way to go about showing 'who' the contact is.


The only real usecase I can see with this xep from clients point of view 
is to construct a jid for authorization when the node would otherwise 
contain prohibited characters.
For the server, this xep is required since its user population could 
include users which have these prohibited characters in the uid .. and 
so requires it to identify the backend user (hence need to standardize)


From a gateway's point of view - even if there is some other encoding 
(urlencoding, etc), it does not matter - the rest of the system does not 
depend on how the gateway encodes or decodes - ofcourse it helps to 
standardize so that implementations dont end up with illegal nodes.


Regards,
Mridul

Re: [Standards] XEP-0045: roomnick case

2007-07-26 Thread Mridul Muralidharan


Jack Moffitt wrote:

Currently in XEP-0045, roomnicks are case-sensitive. To be precise
roomnicks are handled according to the Resourceprep profile of 
stringprep:


http://www.xmpp.org/extensions/xep-0045.html#bizrules-jids

This means that the following roomnicks are all different:

StPeter
stpeter
STPETER

Some people have pointed out that this can be confusing to end users.


Not only this, but it's very easy to "steal" someone's identity when
they are not there.  You just log in with their normal nick.

At Chesspark we make all public rooms non-anonymous and we always show
the full jid or (if they are in your roster) the roster nick for that
person.  That way no one is ever confused who is who.  So we've
basically solved this in the client.  All this nick stuff stuff is so
IRCish anyway.  It's nice if what you want is an anonymous room, but
for everything else, it's just a mess IMO.

After trying several solutions we found that this was least confusing
to everyone and we have gotten no complaints except for the occasional
jerk that signs up with a name like st.peter or stpeter_, but there's
little you can do about that but ban the offenders.

jack.


Unless rooms are not anonymous, clients have no way to validate who the 
participants are anyway - so it is not really stealing : you dont 
register the nick, it is not tied to your jid in any way.
In anonymous rooms you dont know who the participants are - so relying 
on nicks to give a hint of the identity would be wrong.


Mridul

Re: [Standards] mutual authentication and XEP 178

2007-07-26 Thread Mridul Muralidharan


Toly Menn wrote:

An XML stream always goes in one direction, it's just that in the c2s



case both streams go over the same TCP connection, whereas in the s2s



case there are two TCP connections. However, as Justin says, the



directionality matters only for the sending of stanzas, not for the



sending of XML elements that are used to establish the stream. I'll



clarify this in the -04 version of rfc3920bis, and will post to the list



once I have proposed text.







/psa


 

Going back to StPeter’s original example of the s2s case, server 1 (s1) 
sends STANZAs to server 2 (s2) over TCP connection 1 (t1), s2 sends 
STANZAs to s1 over TCP connection 2 (t2).  I just wanted to confirm that 
this applies to ALL stanzas, including IQ stanzas.  So if s1 sends s2 an 
IQ stanza of type “set” over t1, s2 will reply to s1 to that “set” with 
a “result” stanza over t2?  Either way, this may be a good clarification 
in 3920bis as well.



You are right.
The reference to http in 3920 might be slightly confusing, but the 
intent is that all stanza's from server to the remote server goes only 
over the outbound connection.
And server will recieve stanza's only over the inbound socket - after 
the session has been established. That is, you could have stanza's 
exchanged both ways over an s2s stream before session establishment is 
complete.


Regards,
Mridul


 


Thanks, Toly

Re: [Standards] JID Escaping

2007-07-25 Thread Mridul Muralidharan


Greg Hudson wrote:

On Wed, 2007-07-25 at 10:02 +0530, Mridul Muralidharan wrote:
As long as we have prohibited characters - and '@' is always going to be 
there in node part, we will need escaping :-)


There's an underlying assumption here that JID nodes must be able to
contain, in their display representations, the verbatim identifiers from
any other system.


The requirement here is that deployments/users would want to use the 
same user id across multiple applications - and the node of their JID 
ends up being same as their uid typically.
Since node cant contain prohibited characters, we escape or encode them 
- a spec allows all clients and servers to do this in a standard way.
For display, use JUD or nick, etc - node should be the fallback in case 
info cant be obtained through other means.





That's not true of email; why does it need to be true of XMPP?  If a JID
node can contain a "@" character in its display representation, there's
no nice way to display that JID safely to the user.
[EMAIL PROTECTED]@montague.org is perhaps unambiguous but is certainly
confusing.



This is invalid as a JID as per xmpp rfc.

Mridul

Re: [Standards] JID Escaping

2007-07-24 Thread Mridul Muralidharan


Peter Saint-Andre wrote:

Ian Paterson wrote:

Robin Redeker wrote:

Great, JIDs with '\20' in the beginning and end have been deprecated
then?
Shouldn't the RFC be changed then?
  

Maybe. I don't know what other people think, but it seems like XEP-0106
could be usefully rolled into 3920bis. Employing SHOULDs instead of
MUSTs (for things like whitespace prefixes/suffixes) would make it
backward compatible.


I'd rather get rid of JID Escaping entirely than add it to rfc3920bis.

/psa


As long as we have prohibited characters - and '@' is always going to be 
there in node part, we will need escaping :-)


Mridul

Re: [Standards] JID Escaping

2007-07-24 Thread Mridul Muralidharan



Hi Robin,

You should analyze as to who will actually need to encode or decode nodes.

1) Gateway's.
For the purpose of mapping foreign uid's to xmpp nodes.
In this case, ONLY the gateway, will need to do encode/decode.
All other entities will treat is as a JID - without any transformation 
to node/domain/resource.

It will encode a foreign id to node so that it becomes a valid xmpp JID.
It will decode node from an xmpp 'to' for obtaining the destination in 
the foreign network.


2) Client's and server's.
When the node is same as uid, and the uid of the user contains 
prohibited characters. In this case, when client authorizes to server, 
it would encode the uid to obtain the node - and then form the JID to be 
used (Only the client encodes it as part of auth, and once authorization 
is over, encoding of the JID is opaque to the client).


At the server, it would decode the node to obtain the actual uid and use 
that (backend store update, etc) - note that for purpose of routing, the 
server would treat the jid as-is, only decode it to identify the backend 
entry (database, ldap, file, etc) to which it has to persist/query data.
(This is one way in which you would model things - servers can ofcourse 
come up with other alternate ways to do this).


Other than for these two, I cant really envision any other important 
usecase which requires any entity (client, gateway, component or server) 
to encode or decode - the above are directly related to and required for 
xmpp routing.


Hopefully, from this point of view, the xep might make more sense.

More inline ...


Robin Redeker wrote:

On Tue, Jul 24, 2007 at 10:10:45PM +0530, Mridul Muralidharan wrote:

Robin Redeker wrote:

On Sat, Jul 21, 2007 at 08:17:19PM -0600, Peter Saint-Andre wrote:

Robin Redeker wrote:

On Sat, Jul 21, 2007 at 09:20:27AM +0200, Mats Bengtsson wrote:

I think the whole XEP should be renamed to something like:

 XEP-0106 - JID Mapping for Gateways
This would be better. But it breaks the generic usage of JIDs for both 
users

and gateways. It will create a lot of trouble.


The XEP seems to already create a lot of trouble. Just remind me to
register '[EMAIL PROTECTED]' when every client unescapes JIDs ;-)

No problem. The spec says:

"The character sequence \20 MUST NOT be the first or last character of
an escaped node identifier."

But of course you can violate the spec if desired. ;-)

I don't violate the RFC here. I violate some optional extension.
You cant specify the characters mentioned in the xep in the node without 
escaping them - so trying to do so otherwise is a violation of the rfc.
Ofcourse you can come up with a custom encoding (as we used to have), 
but this does not allow any arbitrary client/server combination to 
interoperate.


Of course I can? With an old client? And it's even allowed and sane and
valid? Or do I miss something here?


You cannot use prohibited characters - whether they are old clients or 
bad clients.
The first conforming xmpp recipient (typically the server) would kick 
your stream out with a stream error.





The XEP-0106 has to exclude the JIDs which start or end with '\20' in the
nodepart from the escaping AND unescaping transformations.

This is already present.


Great, JIDs with '\20' in the beginning and end have been deprecated then?
Shouldn't the RFC be changed then?


No, this is not related to the rfc.
The rfc specifies list of prohibited characters - and they MUST NOT be 
in the node.
The xep allows a way of encoding these characters into the JID because 
of requirements like what I mentioned above.


Note that the xep just standardizes one way of how to encode, you can 
always come up with any other form of encoding which makes the resulting 
jid conforment with the rfc (urlencoding, etc).






At the moment the paragraph says that it MUST NOT be first or last
in the node part, but it doesn't say WHAT to do when this perfectly
fine JID arrives from the line. Should the JID not be unescaped at all?
Should only the parts after and before '\20' be unescaped?
Should the client close the connection?

It depends on who is doing what.
If the recipient is expected to 'parse' the node, then it would return 
an error, else it would pass it on (directed packets through server for 
example).


To who will it return an error? Will it throw a pop-up at the user
"Someone with an invalid JID sent you something!"?
Or back to the sender? Why should it do that for a perfectly fine JID?


Most entities in the xmpp network would route/process stanza's 
irrespective of whether it is encoded node or not - and they are 
agnostic to it.
Only those entities which need to be aware of it to decode it (relevant 
gateway's and server's) would typically check the semantics of the 
decoded node - and potentially return an error back. I would assume it 
would be a stanza error

Re: [Standards] JID Escaping

2007-07-24 Thread Mridul Muralidharan


Robin Redeker wrote:

On Sat, Jul 21, 2007 at 08:17:19PM -0600, Peter Saint-Andre wrote:

Robin Redeker wrote:

On Sat, Jul 21, 2007 at 09:20:27AM +0200, Mats Bengtsson wrote:

I think the whole XEP should be renamed to something like:

  XEP-0106 - JID Mapping for Gateways

This would be better. But it breaks the generic usage of JIDs for both users
and gateways. It will create a lot of trouble.


The XEP seems to already create a lot of trouble. Just remind me to
register '[EMAIL PROTECTED]' when every client unescapes JIDs ;-)

No problem. The spec says:

"The character sequence \20 MUST NOT be the first or last character of
an escaped node identifier."

But of course you can violate the spec if desired. ;-)


I don't violate the RFC here. I violate some optional extension.


You cant specify the characters mentioned in the xep in the node without 
escaping them - so trying to do so otherwise is a violation of the rfc.
Ofcourse you can come up with a custom encoding (as we used to have), 
but this does not allow any arbitrary client/server combination to 
interoperate.




The XEP-0106 has to exclude the JIDs which start or end with '\20' in the
nodepart from the escaping AND unescaping transformations.


This is already present.



At the moment the paragraph says that it MUST NOT be first or last
in the node part, but it doesn't say WHAT to do when this perfectly
fine JID arrives from the line. Should the JID not be unescaped at all?
Should only the parts after and before '\20' be unescaped?
Should the client close the connection?


It depends on who is doing what.
If the recipient is expected to 'parse' the node, then it would return 
an error, else it would pass it on (directed packets through server for 
example).




Do I miss something in the XEP? (If I do so please ignore the rest of
the mail.)

Please also note the nice, but maybe not so important collision that
here happens when the client just doesn't unescape:

   unescape ("\5c20foobar\5c20") => "\20foobar\20"
   unescape ("\20foobar\20") => "\20foobar\20"

This is of course not really an important JID, and who cares about a few
optical collisions in clients which confuse the user. And these only happens
once someone else decides to put '\20' at the beginning or end
of his name and why would someone do that?

Hey, we could add security notes to all clients which tell the user:

   "Never attach '\20' to the beginning or end of your name, it is unsafe!"

The U.S. Army will love this! (One might think of a case where they actually
name their units by enumerating them with a \ in the end:

   Unescaped: Escaped: Unescaped:
   "Tank\1"   "Tank\5c1"   "Tank\1"
   "Tank\20"  "Tank\20""Tank\20"
   "Tank\22"  "Tank\5c22"  "Tank\22"
  "Tank\5c20"  "Tank\20" ... ps

Ah... never... why would they do that... :-)


These sort of problems are common to any form of encoding - example 
urlencoding.

It is obviously expected that the client/gateway would do the right thing.




I propose to rename the XEP to make clear that this escaping/unescaping should
only happen in very rare cases (only at gateways or heavily specialized client
frontends). And that the terms 'escaping' and 'unescaping' are replaced by
'mapping' and 'unmapping', because thats what is happening here.




Not really very specialized clients - even common clients will need it.
Example, if uid's used in the server are mailid's for example.
Then the client will need to escape the node for the bind.


- Mridul


Robin

Re: [Standards] XEP-0047 (Flow rate control for IBB)

2007-07-19 Thread Mridul Muralidharan

William Voorsluys wrote:

Hello,

> Justin, what say you?

I'm against adding redundant information like this into the stanzas.

Maybe William can explain what he means by "filtering" and how this is
difficult?

This is really an implementation issue and is more related to parsing.
Suppose I need both 'sid' and 'seq' to be included in the response.
Without child elements I would use an 'id' like "sid001_10". Since the
values I need are not as an XML structure, I need to create a special
"ID parser" that would break the id into pieces and deliver the values
to the application.
This is needed because we want to create Packet Filters in the Smack
library that only match a specific session id. Messages of the
different sessions are delivered to different Objects (the Packet
Listeners or Packet Collectors). If I don't break the 'id' and get
'sid' to use as the argument input, I have to create one Packet
Collector for each message sent, using the full 'id' as the filter
argument, so that the correct sender will receive the message
acknowledgment.

As I said, this is an implementation issue and we could cope with
using just 'id' for tracking packets, even though it makes the
implementation harder.

Thanks,

William.

For xmpp, iq response (result/error) and requests are to be associated
based on [from, to, id] tuple - nothing else. So expecting or relying on
other additional information will not work across usecases or clients.
And it makes no sense to duplicate this in other forms when it is
possible to make this associated unambiguously.

For example, the response need not contain the namespace element to
which the request was sent to, but can be a bare response (from="[EMAIL PROTECTED]" id="reqid" type="result" />). I have seen libraries
assuming recommended behavior as though it was MUST and not handling
these cases.

Mridul

Re: [Standards] mutual authentication and XEP 178

2007-07-18 Thread Mridul Muralidharan


Peter Saint-Andre wrote:

Tony Finch wrote:

On Tue, 17 Jul 2007, Peter Saint-Andre wrote:

If you are referring to certificate validation, that is covered in RFC3920:

Of course. Thanks for reminding me!


Now, there *is* a question about s2s TLS that I started wondering about
while updating rfc3920bis recently, but it's related to TCP connections.

Server1 realizes that it needs an XML stream to Server2 in order to
route some stanzas. So Server1 completes address resolution via SRV or
whatever and opens a TCP connection to Server2. That happens on
TCPconn1. Then Server1 sends a stream header to Server2. So far so good.

RFC3920 says that for s2s there are 2 TCP connections. So in order to
send a response stream header to Server1, I assume that Server2 opens a
second TCP connection, which we'll call TCPconn2, and then sends the
response stream header over TCPconn2.

Correct?

I don't know if the spec needs to talk about this, but it couldn't hurt
(since it's different for c2s vs. s2s).

/psa



What is this 'stream header' you are refering to here ?
The actual stanzas to be routed ? then yes - anything else, then no.

- Mridul

Re: [Standards] XEP-0047 (Flow rate control for IBB)

2007-07-17 Thread Mridul Muralidharan


William Voorsluys wrote:

Hello,

We're adding flow rate control support for IBB since our application
makes heavy use of file transfers.
Since we need to receive ACKs for packets, we're using  for data
transport, according to  XEP-0047. The first problem is that the
algorithm we're using needs to know the sequence number of the packet
being acknowledged.
But, according to the XEP, it is not allowed to include any inner XML
stanza on the  of type RESULT used as ACK:



What would be the best way of including this information in the ACK?
Should we use  + AMP for having that info?

Thank you,

William


Hi,

  You could encode the sequence number into the 'id' attribute ?

Regards,
Mridul

Re: [Standards] XEP-0060: publish-options

2007-07-17 Thread Mridul Muralidharan


Peter Saint-Andre wrote:

Mridul Muralidharan wrote:

Peter Saint-Andre wrote:

I understand handling of fields that are preconditions, it's what we
outlined before:

1. If the node exists and the precondition is not met (in this case, if
the access model is something other than "whitelist"), then the publish
fails with a suitable error condition (probably  along with
some pubsub-specific condition).

2. If the node exists and the precondition is met, then the publish
succeeds.

3. If the node does not exist, then the service auto-creates the node
with default configuration in all respects except those specified in the
preconditions (in this case, the node would be created with an access
model of "whitelist") and the publish succeeds.

What other field types do people envision for publishing options? Here
are some possibilities:

- publish this item with the specified metadata

- publish but override node configuration for this item only (yes this
would enable per-item access controls, but let's not talk about that too
loudly and maybe people won't notice... ;-)

Naturally it's up to the implementation or deployment whether it
supports any of these field types.


A means to specify, dont publish if precondition is not met - a means to
use it as config assertion.


Isn't that precondition? See point #1 above.

/psa




Ouch, half asleep :-) Yes I was looking for the very same !

Thanks,
Mridul

Re: [Standards] XEP-0060: publish-options

2007-07-17 Thread Mridul Muralidharan


Peter Saint-Andre wrote:

At http://mail.jabber.org/pipermail/standards/2007-July/015878.html and
other messages in that thread, we talked about a kind of publishing an
item only certain preconditionsn are met. Ralph Meijer mentioned that we
could broaden this to include publish-options other than preconditions:

http://mail.jabber.org/pipermail/council/2007-July/002169.html

So we might have something like this:


  

  

  Soliloquy
  
To be, or not to be: that is the question:
Whether 'tis nobler in the mind to suffer
The slings and arrows of outrageous fortune,
Or to take arms against a sea of troubles,
And by opposing end them?
  
  
  tag:denmark.lit,2003:entry-32397
  2003-12-13T18:30:02Z
  2003-12-13T18:30:02Z

  


  

http://jabber.org/protocol/pubsub#publish-options


  presence

  

  


It seems to me that the following rules would apply:

1. The  element MUST contain a data form (see XEP-0004).

2. The FORM_TYPE of the data form MUST be
"http://jabber.org/protocol/pubsub#publish-options"; (see XEP-0068).

3. Fields registered with the XMPP Registrar for that FORM_TYPE MUST
specify how they are to be handled by the form-processing entity.

I understand handling of fields that are preconditions, it's what we
outlined before:

1. If the node exists and the precondition is not met (in this case, if
the access model is something other than "whitelist"), then the publish
fails with a suitable error condition (probably  along with
some pubsub-specific condition).

2. If the node exists and the precondition is met, then the publish
succeeds.

3. If the node does not exist, then the service auto-creates the node
with default configuration in all respects except those specified in the
preconditions (in this case, the node would be created with an access
model of "whitelist") and the publish succeeds.

What other field types do people envision for publishing options? Here
are some possibilities:

- publish this item with the specified metadata

- publish but override node configuration for this item only (yes this
would enable per-item access controls, but let's not talk about that too
loudly and maybe people won't notice... ;-)

Naturally it's up to the implementation or deployment whether it
supports any of these field types.



A means to specify, dont publish if precondition is not met - a means to 
use it as config assertion.


Regards,
Mridul



Thoughts?

/psa

Re: [Standards] private storage revisited

2007-07-08 Thread Mridul Muralidharan


Ian Paterson wrote:

Peter Saint-Andre wrote:

So we'd have something like this:


  

  

  

  
  My nurse's birthday!

  


  

  http://jabber.org/protocol/pubsub#node_config


  whitelist

  

  


If the node exists and the precondition is not met (in this case, if the
access model is something other than "whitelist"), then the publish
fails with a suitable error condition (probably  along with
some pubsub-specific condition).

If the node exists and the precondition is met, then the publish 
succeeds.


If the node does not exist, then the service auto-creates the node with
default configuration in all respects except those specified in the
preconditions (in this case, the node would be created with an access
model of "whitelist") and the publish succeeds.

Correct?
  


Correct. +1

Thank you Ralph, Peter.

Wow! consensus on Personal Publishing! I'm off to celebrate :-) :-)

- Ian



Whether to autocreate or to return error saying node does not exist 
(item-not-found) - can this be an implementation detail ? That is, are 
clients expected to handle the error path too and explictly create ?
We do not have auto create in pubsub iirc (not sure if pubsub was 
modified to support this) - so supporting this for pep will implictly 
mean supporting it for pubsub too (same namespace, etc).


But in general, preconditions are great way to assert access level for 
clients/nodes which require strict acl's.


Regards,
Mridul

PS : Hope this is not going back to the same path's earlier, just wanted 
to get it clarified.

Re: [Standards] -

2007-07-05 Thread Mridul Muralidharan


Peter Saint-Andre wrote:

Mridul Muralidharan wrote:

Peter Saint-Andre wrote:

Mridul Muralidharan wrote:


Now, a 'from' address of the full JID seems odd to me. What if I
send an
IQ-set from one of my resources to another? Does that mean I can do
roster pushes directly from one resource to another without updating
the
roster on the server? Does the server deliver the IQ-result packets
from
all interested resources to the initiating resource for the roster set?
That seems wrong to me (i.e., I think it's a spec bug in RFC 3921).

A bare JID makes more sense because IQs sent to the bare JID are
handled
by the server. But in that case, the server can't perform the usual
swapping of 'from' and 'to' addresses anyway, so it seems easier to not
include the 'from' address.


In our case, server handles roster iq's, irrespective of destination
specified in stanza and will always be processed for the sender.

Here's what I'm talking about:

1. res1 sends a roster set:


  .


2. Server processes the set and sends out roster pushes to res1, res2,
and res3:


  .



  .



  .


3. In accordance with RFC 3920 and RFC 3921, all three resources process
the roster push and return IQ-result:


  .



  .



  .


4. In accordance with RFC 3920, server routes all three IQ-results to
res1 -- it does not process them itself because IQs addressed to full
JIDs are delivered to the client, not processed by the server. So as a
result, the client running at res1 receives 3 IQ-results.

Is that desired behavior? I think not. The server doesn't process the
IQ-results (were they received?) and the res1 client is going to be
confused.

Or so it seems to me.

I say we didn't specify this fully or carefully enough in RFC 3921 and
should fix it.

Peter


I was describing about how our server processes roster requests.
In our case the 'from' gets set to the bare jid of the user before the
roster push - so this problem particular problem you describe is not
present.
That being said, this is an implementation detail 


I wouldn't quite call it an implementation detail. Usually an
implementation detail is something that doesn't get spec'ed out.


I think I did not phrase that properly.
I meant, what I described above was our implementation detail; and yes, 
it needs to be spec'ed out properly :-)






and you are right that
this must be specified more clearly in the bis spec.


I'm saying that a full JID is bad here. A bare JID is harmless. We
didn't see the problems with a full JID when we wrote RFC 3921 because
we didn't think about the case of multiple resources (or we specified
things such that the full JID would be the JID of the connected resource
for each push, i.e., the 'from' in the above examples would be res1 when
sending the push to res1, res2 when sending the push to res2, etc.,
which is a lot of work for no gain, and in fact for quite a bit of
potential confusion).


But specifying that 'from' should not be present for roster push might
not be a good idea ...
What about just stating that :
a) from == null || bareJid(from) == user.bareJid for all roster push.


No 'to' or to='bareJID' is fine by me. It's the full JID case that seems
problematic.


Yes, makes sense.
Why ... below




b) the client response must be to == user.bareJid or no 'to'.


Most XMPP software just swaps the 'from' and the 'to' when sending an
IQ-result or IQ-error. So I think we really need to specify only part
(a) here. Part (b) is just normal XMPP processing.


I mentioned that for bis clients talking to 3920/3921 servers.
A bis compliant server would do the right thing (no to/to == bareJid).

Mridul



Peter

Re: [Standards] -

2007-07-05 Thread Mridul Muralidharan


Peter Saint-Andre wrote:

Mridul Muralidharan wrote:


Now, a 'from' address of the full JID seems odd to me. What if I send an
IQ-set from one of my resources to another? Does that mean I can do
roster pushes directly from one resource to another without updating the
roster on the server? Does the server deliver the IQ-result packets from
all interested resources to the initiating resource for the roster set?
That seems wrong to me (i.e., I think it's a spec bug in RFC 3921).

A bare JID makes more sense because IQs sent to the bare JID are handled
by the server. But in that case, the server can't perform the usual
swapping of 'from' and 'to' addresses anyway, so it seems easier to not
include the 'from' address.


In our case, server handles roster iq's, irrespective of destination
specified in stanza and will always be processed for the sender.


Here's what I'm talking about:

1. res1 sends a roster set:


  .


2. Server processes the set and sends out roster pushes to res1, res2,
and res3:


  .



  .



  .


3. In accordance with RFC 3920 and RFC 3921, all three resources process
the roster push and return IQ-result:


  .



  .



  .


4. In accordance with RFC 3920, server routes all three IQ-results to
res1 -- it does not process them itself because IQs addressed to full
JIDs are delivered to the client, not processed by the server. So as a
result, the client running at res1 receives 3 IQ-results.

Is that desired behavior? I think not. The server doesn't process the
IQ-results (were they received?) and the res1 client is going to be
confused.

Or so it seems to me.

I say we didn't specify this fully or carefully enough in RFC 3921 and
should fix it.

Peter



I was describing about how our server processes roster requests.
In our case the 'from' gets set to the bare jid of the user before the 
roster push - so this problem particular problem you describe is not 
present.
That being said, this is an implementation detail and you are right that 
this must be specified more clearly in the bis spec.


But specifying that 'from' should not be present for roster push might 
not be a good idea ...

What about just stating that :
a) from == null || bareJid(from) == user.bareJid for all roster push.
b) the client response must be to == user.bareJid or no 'to'.

This would make it backwardly compatible while avoiding the problem we 
have above.
And since the roster push was from the server (and not from a client), 
(b) makes logical sense though it might be violating strict iq 
requirements (result.to != request.from) - tightening would make it 
incompatible with existing deployments which use full jid's for 'from'.


Regards,
Mridul

Re: [Standards] 'from' address on roster push

2007-07-05 Thread Mridul Muralidharan


Peter Saint-Andre wrote:

Tomasz Sterna wrote:

Dnia 27-06-2007, śro o godzinie 16:50 -0600, Peter Saint-Andre
napisał(a):

So I propose the following text:

   A server MUST ignore any 'to' address on a roster set, and MUST
   treat any roster "set" as applying to the sender.  A server MUST
   NOT include a 'from' address on a roster push.  If a roster push
   includes a 'from' address then the client SHOULD ignore the
stanza. 

Is it backwards compatible?


Good question.

RFC 3921 talks only about what the client must do with regard to the
'from' address on a roster push:

   a client SHOULD check the "from" address of a "roster push" (incoming
   IQ of type "set" containing a roster item) to ensure that it is from
   a trusted source; specifically, the stanza MUST either have no 'from'
   attribute (i.e., implicitly from the server) or have a 'from'
   attribute whose value matches the user's bare JID (of the form
   <[EMAIL PROTECTED]>) or full JID (of the form <[EMAIL PROTECTED]/resource>);
   otherwise, the client SHOULD ignore the "roster push".

If a bis-compliant server never includes a 'from' address on a roster
push, a 3921-compliant client will not break.

However, a bis-compliant client might ignore roster pushes from a
3921-compliant server, since a 3921-compliant server might include a
'from' address whose value is the bare JID or full JID of the user.

Now, a 'from' address of the full JID seems odd to me. What if I send an
IQ-set from one of my resources to another? Does that mean I can do
roster pushes directly from one resource to another without updating the
roster on the server? Does the server deliver the IQ-result packets from
all interested resources to the initiating resource for the roster set?
That seems wrong to me (i.e., I think it's a spec bug in RFC 3921).

A bare JID makes more sense because IQs sent to the bare JID are handled
by the server. But in that case, the server can't perform the usual
swapping of 'from' and 'to' addresses anyway, so it seems easier to not
include the 'from' address.




In our case, server handles roster iq's, irrespective of destination 
specified in stanza and will always be processed for the sender.


Regards,
Mridul


Peter

Re: [Standards] Re: [jdev] XEP-0115: Entity Capabilities

2007-07-03 Thread Mridul Muralidharan


Joe Hildebrand wrote:


On Jul 3, 2007, at 3:04 PM, Ian Paterson wrote:

Hmm, going forward, are the clients that most people use going to 
continue showing these icons? Is this a feature we need to care about? 
Even though I'm one of the small group of people involved in the XMPP 
community, I really don't care what client my contacts are using. Will 
there ever be mass demand for this feature? On the rare occasions 
where people are interested, they'll probably be perfectly happy to 
explicitly ask their client to find out the other user's client 
version on a case-by-case basis.


In general, I agree with you, but this was one of the reasons people 
were doing version floods, which is why we came up with 115 in the first 
place.


In specific, I have a particular use case (that I can't talk much about, 
unfortunately) that absolutely relies the node being distinguishable.


Changing the meaning of node breaks backwards compatibility, whereas 
nothing else in the current proposal does.  If there's no good reason to 
break backward compatibility, I suggest that we avoid it.




I am not sure what was decided as the final design for the spec 
regarding hashing, but moving from existing scheme of ver & ext also 
breaks backward compatibility.
The xep was a draft standard and there are multiple implementations 
already released - of server & client which rely on this and use these 
semantics for both documented (other xep's) and undocumented features.


Validation of caps data using hash is invaluable (esp for pep), but I am 
not very happy about breaking compatibility with existing clients and 
servers.


Regards,
Mridul

Re: [Standards] Re: [jdev] XEP-0115: Entity Capabilities

2007-07-03 Thread Mridul Muralidharan


Mridul Muralidharan wrote:

Peter Saint-Andre wrote:

Mridul wrote:

Joe Hildebrand wrote:

On Jul 2, 2007, at 4:49 PM, Mridul Muralidharan wrote:


Peter Saint-Andre wrote:

Mridul Muralidharan wrote:

Forgot to add, change name from ver & ext to verh and exth ?

Why?

Conflict with existing clients - too many of them in the wild dont use
these semantics.

Others have already responded to this, but just to reinforce, I *did*
talk about backward compatibility.  Existing clients would continue to
work just fine. New clients just have to be able to detect other new
clients, to know if they are supposed to be able to check the hash. 
Presumably, new clients could choose by policy to ignore un-hashed caps

from old clients.

Not sure if anyone addressed the actual I was thinking of (need to read
rest of thread).

Essentially, how would 'new' clients know is something exhibited in ver
or ext is hash or 'old' value ? Aren't those identifiers not expected to
be opaque (though consistent) ?

Considering an ext of "my_ext 1233ab" and "#hash1 #hash2" exhibited by
two clients - how would the reciever know what is hashed as per 'new'
idea and what is 'old' ver/ext ?


As I understand the proposal, there would not be "#hash1 #hash2" -- why
do you need multiple values here? You concatenate all the supported
namespaces according to some rule and then hash the whole thing. So
there's only one hash. But that means something different from 'ext' or
'node' or 'ver' so I think it needs to go in its own attribute.

/psa


What Joe Hildebrand proposed initially had hashes for node & ext's - I 
was refering to that here.
The approach has the advantage that, clients can query and validate (and 
so independently cache) namespace#node_hash, namespace#ext1_hash, etc - 
and so having multiple hash'es allows reuse of cap's info across clients 
and allows them to modify ext's each independent of the others.
Addition or removal of a plugin will not result in the entire hash being 
invalidated - just a specific hash will be removed, or modified.



A single hash has the drawback that it will either protect the entire 
set, or none at all - and so effectively we lose ability of separating 
node's from ext's since we cannot independently validate each.


Which is why my initial query was if this should be 'verh' and 'exth' to 
indicate hash'es and not 'ver' & 'ext' for the data itself (because of 
new clients rejecting caps from old clients) - and 'new' clients would 
query for these instead of ver/ext. I am sure there would be better 
ideas to tackle this problem.


Though cache pollution looks like a serious issue (especially server 
cache for pep case), I am wondering if we are not taking this way too 
seriously - I did not see so much discussion for esessions ;-)


Regards,
Mridul



s/node/ver/g
Apologies.

Mridul

Re: [Standards] Re: [jdev] XEP-0115: Entity Capabilities

2007-07-03 Thread Mridul Muralidharan


Peter Saint-Andre wrote:

Mridul wrote:

Joe Hildebrand wrote:

On Jul 2, 2007, at 4:49 PM, Mridul Muralidharan wrote:


Peter Saint-Andre wrote:

Mridul Muralidharan wrote:

Forgot to add, change name from ver & ext to verh and exth ?

Why?

Conflict with existing clients - too many of them in the wild dont use
these semantics.

Others have already responded to this, but just to reinforce, I *did*
talk about backward compatibility.  Existing clients would continue to
work just fine. New clients just have to be able to detect other new
clients, to know if they are supposed to be able to check the hash. 
Presumably, new clients could choose by policy to ignore un-hashed caps

from old clients.

Not sure if anyone addressed the actual I was thinking of (need to read
rest of thread).

Essentially, how would 'new' clients know is something exhibited in ver
or ext is hash or 'old' value ? Aren't those identifiers not expected to
be opaque (though consistent) ?

Considering an ext of "my_ext 1233ab" and "#hash1 #hash2" exhibited by
two clients - how would the reciever know what is hashed as per 'new'
idea and what is 'old' ver/ext ?


As I understand the proposal, there would not be "#hash1 #hash2" -- why
do you need multiple values here? You concatenate all the supported
namespaces according to some rule and then hash the whole thing. So
there's only one hash. But that means something different from 'ext' or
'node' or 'ver' so I think it needs to go in its own attribute.

/psa


What Joe Hildebrand proposed initially had hashes for node & ext's - I 
was refering to that here.
The approach has the advantage that, clients can query and validate (and 
so independently cache) namespace#node_hash, namespace#ext1_hash, etc - 
and so having multiple hash'es allows reuse of cap's info across clients 
and allows them to modify ext's each independent of the others.
Addition or removal of a plugin will not result in the entire hash being 
invalidated - just a specific hash will be removed, or modified.



A single hash has the drawback that it will either protect the entire 
set, or none at all - and so effectively we lose ability of separating 
node's from ext's since we cannot independently validate each.


Which is why my initial query was if this should be 'verh' and 'exth' to 
indicate hash'es and not 'ver' & 'ext' for the data itself (because of 
new clients rejecting caps from old clients) - and 'new' clients would 
query for these instead of ver/ext. I am sure there would be better 
ideas to tackle this problem.


Though cache pollution looks like a serious issue (especially server 
cache for pep case), I am wondering if we are not taking this way too 
seriously - I did not see so much discussion for esessions ;-)


Regards,
Mridul

Re: [Standards] Re: [jdev] XEP-0115: Entity Capabilities

2007-07-02 Thread Mridul Muralidharan


Peter Saint-Andre wrote:

Mridul Muralidharan wrote:

Peter Saint-Andre wrote:

Mridul Muralidharan wrote:


Forgot to add, change name from ver & ext to verh and exth ?

Why?


Conflict with existing clients - too many of them in the wild dont use
these semantics.


But introducing new attributes is backward-incompatible, no?

Given that both the 'ver' and 'ext' attributes have no semantic meaning
in XEP-0115 right now, I don't see why it is a problem to use those
attribute names. In fact we're adding semantic meaning with the hashes,
but existing clients should work just fine AFAICS.

/psa



  When new clients attempt to interop with existing clients, they will 
not be able to do so - since none of the ver/ext exhibited by existing 
clients will match what gets generated through the md5/sha/etc sum of 
features & capabilities when newer clients attempt to validate this.
So we will not have interop going forward (well, existing clients will 
be able to use new ones though ... weird situation, since usually a 
changes leaves older clients hanging !).


Or did I get it wrong ?

Regards,
Mridul

Re: [Standards] Re: [jdev] XEP-0115: Entity Capabilities

2007-07-02 Thread Mridul Muralidharan


Peter Saint-Andre wrote:

Mridul Muralidharan wrote:


Forgot to add, change name from ver & ext to verh and exth ?


Why?



Conflict with existing clients - too many of them in the wild dont use 
these semantics.


Mridul

Re: [Standards] Re: [jdev] XEP-0115: Entity Capabilities

2007-07-02 Thread Mridul Muralidharan


Mridul Muralidharan wrote:

Joe Hildebrand wrote:


On Jun 27, 2007, at 2:32 AM, Jacek Konieczny wrote:


That is not true. Years ago I have proposed other solution: instead of
announcing client name version and caps clients should announce digest
(e.g. MD5 or SHA) of normalized set of supported features. The list
would have to be obtained only once per feature set and it could be
verified. The traffic would not be much bigger than with current
solution and the 'cache taint' problem would be gone. And
implementations could be simpler (no need for capability registry --
namespace registry is enough) and less error-prone (when a new namespace
is added the digest would change 'automatically'. Currently developers
have to manually update version or capability string).

I think the digest could be used with current specification too -- as
the only capability string, bound with all the supported namespaces. But
XEP-0115 is not optimized for such usage and says nothing about digest
verification.


The current spec could absolutely be used for this.  The hardest part 
is spec'ing how to generate a string that has all of the capabilities, 
so that you can run the hash.  Canonical XML is massive overkill, but, 
for example, if we just said:


- For all sorting, use the Unicode Collation Algorithm 
(http://www.unicode.org/unicode/reports/tr10/)

- Initialize an empty string E
- sort the identities by category, then type
- for each identity, append the category, then the type (if it exists) 
to E (note: any information inside an identity will be ignored)

- sort the features by URI
- for each feature, append the URI to E  (note: any information inside 
a feature will be ignored)

- calculate the MD5 sum for E
- use this for the version number or extension name

Example (adapted from XEP-115, example 2):


   ext='d6224a352df544cfde1fbce177301c67 
d0ef9e8327acf5873d16fe083b4d3f3f'/>



The receiving client SHOULD check the hashes, after doing the IQ/gets:

md5(clientpchttp://jabber.org/protocol/disco#infohttp://jabber.org/protocol/disco#itemshttp://jabber.org/protocol/feature-neghttp://jabber.org/protocol/muc) 
= 730c80b442e150dd5e19a31f8edfa8b1
md5(clientpchttp://jabber.org/protocol/bytestreamshttp://jabber.org/protocol/sihttp://jabber.org/protocol/si/profile/file-transfer) 
= d6224a352df544cfde1fbce177301c67
md5(clientpchttp://jabber.org/protocol/xhtml-im) = 
d0ef9e8327acf5873d16fe083b4d3f3f


If the receiving client detects an inconsistency, it MUST NOT use the 
information it received, and SHOULD show an error of some kind.


For backwards-compatibility, any version number that is not 32 octets 
long consisting only of [0-9a-f] MUST be treated as if it does not 
implement MD5 checking.


Analysis:
- Existing entities, both sending and receiving, should work fine
- Over time, we can phase in entities that send md5 versions and ext's
- Receiving clients that care about security can start checking MD5 


+1
This sounds good enough to prevent polluting the client side cache.




Forgot to add, change name from ver & ext to verh and exth ?

Also, relationship between caps and pep :
If the server supports pep - then cant it not directly respond back to 
the requester for caps disco queries ?


Regards,
Mridul




hashes of the features to check for poisoning.
- Downside: more bytes in presence than today.


With server optimization implemented, wont this not be restricted to 
first time presence push to a contact ?

So maybe not as bad ?


- Assertion: anything else we do will be at least this bad if not worse.


yes



If we add these bits to -115, will everyone agree to never bring up 
changing caps again, and to all agree on that the next time a n00b 
comes around?


heh



--Joe Hildebrand





Regards,
Mridul

Re: [Standards] Re: [jdev] XEP-0115: Entity Capabilities

2007-06-28 Thread Mridul Muralidharan


Joe Hildebrand wrote:


On Jun 27, 2007, at 2:32 AM, Jacek Konieczny wrote:


That is not true. Years ago I have proposed other solution: instead of
announcing client name version and caps clients should announce digest
(e.g. MD5 or SHA) of normalized set of supported features. The list
would have to be obtained only once per feature set and it could be
verified. The traffic would not be much bigger than with current
solution and the 'cache taint' problem would be gone. And
implementations could be simpler (no need for capability registry --
namespace registry is enough) and less error-prone (when a new namespace
is added the digest would change 'automatically'. Currently developers
have to manually update version or capability string).

I think the digest could be used with current specification too -- as
the only capability string, bound with all the supported namespaces. But
XEP-0115 is not optimized for such usage and says nothing about digest
verification.


The current spec could absolutely be used for this.  The hardest part is 
spec'ing how to generate a string that has all of the capabilities, so 
that you can run the hash.  Canonical XML is massive overkill, but, for 
example, if we just said:


- For all sorting, use the Unicode Collation Algorithm 
(http://www.unicode.org/unicode/reports/tr10/)

- Initialize an empty string E
- sort the identities by category, then type
- for each identity, append the category, then the type (if it exists) 
to E (note: any information inside an identity will be ignored)

- sort the features by URI
- for each feature, append the URI to E  (note: any information inside a 
feature will be ignored)

- calculate the MD5 sum for E
- use this for the version number or extension name

Example (adapted from XEP-115, example 2):


   ext='d6224a352df544cfde1fbce177301c67 
d0ef9e8327acf5873d16fe083b4d3f3f'/>



The receiving client SHOULD check the hashes, after doing the IQ/gets:

md5(clientpchttp://jabber.org/protocol/disco#infohttp://jabber.org/protocol/disco#itemshttp://jabber.org/protocol/feature-neghttp://jabber.org/protocol/muc) 
= 730c80b442e150dd5e19a31f8edfa8b1
md5(clientpchttp://jabber.org/protocol/bytestreamshttp://jabber.org/protocol/sihttp://jabber.org/protocol/si/profile/file-transfer) 
= d6224a352df544cfde1fbce177301c67
md5(clientpchttp://jabber.org/protocol/xhtml-im) = 
d0ef9e8327acf5873d16fe083b4d3f3f


If the receiving client detects an inconsistency, it MUST NOT use the 
information it received, and SHOULD show an error of some kind.


For backwards-compatibility, any version number that is not 32 octets 
long consisting only of [0-9a-f] MUST be treated as if it does not 
implement MD5 checking.


Analysis:
- Existing entities, both sending and receiving, should work fine
- Over time, we can phase in entities that send md5 versions and ext's
- Receiving clients that care about security can start checking MD5 


+1
This sounds good enough to prevent polluting the client side cache.



hashes of the features to check for poisoning.
- Downside: more bytes in presence than today.


With server optimization implemented, wont this not be restricted to 
first time presence push to a contact ?

So maybe not as bad ?


- Assertion: anything else we do will be at least this bad if not worse.


yes



If we add these bits to -115, will everyone agree to never bring up 
changing caps again, and to all agree on that the next time a n00b comes 
around?


heh



--Joe Hildebrand





Regards,
Mridul

Re: [Standards] roster schema

2007-06-25 Thread Mridul Muralidharan



More important than the limits, imo, would be the error to be conveyed 
to the client in case it set's a roster item which violates the server 
policies on size.
This could potentially be reused in other places as well ... is 
not-acceptable descriptive enough for this ?


If we specify this, then rest is just an implementation detail imo with 
a recommendation to clients/servers to support atleast so many characters.


Regards,
Mridul



Peter Saint-Andre wrote:

Matthias Wimmer wrote:

Hi Michal!

Michal 'vorner' Vaner schrieb:

What is the problem with saying the server can have a limit and deny to
perform such crazy operation.
Sounds reasonable. Roster items are not exchanged between servers, 


Yet. :) What happens when we define shared rosters?


so it
seems we do not need a common limit. Each implementation could have it's
own and reject a request that contains longer items.

If a limitation is added to the spec, it should only be an advice for
the minimum that should be supported by any implementation. 


Sure. BTW the schemas are NOT normative, so this is mostly a guideline
anyway.


And it
should be defined which error is returned if the item is to big.


I'm doing that in rfc3920bis, which is why I started to think about the
schemas.

Specifying this more tightly in rfc3920bis seems uncontroversial to me,
I never expected the idea to generate so much list traffic!

Peter

Re: [Standards] roster schema

2007-06-24 Thread Mridul Muralidharan


Peter Saint-Andre wrote:

Currently, the XML schema for the jabber:iq:roster namespace does not
limit the length of an item name or a group name. I think that might
cause problems. In particular I think it might be good to specify that:

1. The 'name' attribute can be a string between 0 and 1023 characters in
length. [1]

2. The XML character data of the  element can be a string
between 1 and 1023 characters in length.

Objections?

/psa

[1] I am assuming that the following are equivalent:





If we don't like name='' then we could specify that the
'name' attribute must be of non-zero length. But I see no
harm in saying that including name='' in a roster set is
equivalent to not including the 'name' attribute.



+1 for specifying upper limit for octets for each.
Naturally there are existing limits to this, but those are 
implementation details - something standard will give both clients and 
servers a upper limit confidence.


Regards,
Mridul

PS: Strange, I was discussing about this with some others just a couple 
of weeks back :)

Re: [Standards] adding body as RECOMMENDED field for PEP-protocols?

2007-06-23 Thread Mridul Muralidharan


Joe Hildebrand wrote:

On Jun 21, 2007, at 2:33 PM, Mridul Muralidharan wrote:


Joe Hildebrand wrote:
A body inside the namespace for the particular PEP node is perfectly 
fine, if it makes sense for that namespace.  If a client doesn't know 
about that namespace, it's not going to add the +notify capability, 
nor subscribe to the node directly, so the notification should never 
come to a client that doesn't know how to process it; "process" here 
may mean just pull out the body element in the appropriate namespace 
and display it in some interesting way.

--Joe Hildebrand


user subscribes to a pep node, and later on a different resource comes 
along on a different client which does not understand pep.
So you can have pep data getting pushed to resources which do not 
understand pep.


Only if you're using explicit subscriptions, not if you're using 
implicit caps-based subs, right?  I see the use case now.



Yes, not implict subscription.
I assumed both are supported ?

Mridul



--Joe Hildebrand

Re: [Standards] adding body as RECOMMENDED field for PEP-protocols?

2007-06-21 Thread Mridul Muralidharan


Joe Hildebrand wrote:


On Jun 14, 2007, at 8:45 PM, Mridul Muralidharan wrote:

You are right, application payloads getting sent (as messages) should, 
imo, not contain  unless it expects to communicate that to the 
user.
In a lot of cases for pep typically, it would be consumed by the 
client to appropriately add meta-data for the contact - it just would 
not make sense to show the plain text info to user.


That being said, we should not preclude addition of body, it might 
make sense for usecases (maybe where pep is more used like pubsub with 
infrequent updates ?)


A body inside the namespace for the particular PEP node is perfectly 
fine, if it makes sense for that namespace.  If a client doesn't know 
about that namespace, it's not going to add the +notify capability, nor 
subscribe to the node directly, so the notification should never come to 
a client that doesn't know how to process it; "process" here may mean 
just pull out the body element in the appropriate namespace and display 
it in some interesting way.


--Joe Hildebrand




user subscribes to a pep node, and later on a different resource comes 
along on a different client which does not understand pep.
So you can have pep data getting pushed to resources which do not 
understand pep.


Regards,
Mridul

Re: [Standards] dialback: piggybacking

2007-06-21 Thread Mridul Muralidharan


Peter Saint-Andre wrote:

Mridul Muralidharan wrote:

Peter Saint-Andre wrote:

Matthias Wimmer wrote:

Hi Peter!

Peter Saint-Andre schrieb:
1. Dialback itself is not mandatory to implement, so a change to 
dialback would not affect the XMPP versioning.


Well ... I think it would be okay to just remove dialback without 
changing the versioning. But if you advertize support for dialback 
by including its namespace, you have to be compatible with dialback 
as specified in RFC 3920.


Right, everything in rfc3920bis will be backward-compatible with 
RFC3920.


2. Removing piggybacking from the specification would not mean that 
an implementation MUST NOT do piggybacking, only that such behavior 
is not specified.


Just removing specification would not make the situation better, I 
think.


I agree. Nothing says that piggybacking must be specified in 
rfc3920bis, but I think it's always better to document things than 
not to document them (well, except for the route and log stuff from 
jabberd 1.x).


Piggybacking was woefully underspecified in RFC 3920. The only text 
I can find is this:


**

After successful dialback negotiation, the Receiving Server SHOULD 
accept subsequent  packets (e.g., validation requests 
sent to a subdomain or other hostname serviced by the Receiving 
Server) from the Originating Server over the existing validated 
connection; this enables "piggybacking" of the original validated 
connection in one direction.


**


It is really interesting that it is only a SHOULD. I expected it to 
be a MUST. In the SHOULD case we indeet might be able to remove it. 
But still SHOULD means that it should be implemented as long as 
there are no "valid reasons in particular circumstances" not to 
implement it. (It's not the term "MAY".)


Correct.


We have tried to specify it more completely in rfc3920bis:

[...]

Reads okay ... but as you said it should be specified how error 
flows are handled. I.e. how a server not supporting piggybacking 
does refuse its use and how a server trying to do piggybacking has 
to react when the other server refuses its use.


Yes, let's fix that up.


The error flows are not well specified here. In particular:

1. What does the Receiving Server return to the Originating Server 
if it does not accept  over the validated connection?


My first thought was , but this would not 
allow to differentiate between a failed dialback and a dialback that 
is just not accepted on this connection.


Yes, and I think it would be good to differentiate between those two 
cases.


2. What does the Authoritative Server return to the Receiving 
Server if it does not accept  over the validated 
connection?


Same with 

Presumably, if the Receiving Server in #1 or the Authoritative 
Server in #2 does not want to do piggybacking, they would close the 
streams in question. But it is still possible for the Originating 
Server in #1 or the Receiving Server in #2 to send a  
or  before the stream is closed, so we need to specify 
how these are handled. A  or  
stream error?


I think that in this case the stream should not be closed. The 
server just refused to do additional authentication on this stream. 
It can still be used for the already authenticated domain.


Ah, OK.

Also the server should notify which db:result/db:verify was not 
accepted. So maybe it should return something like this:


from='example.net'>98AF014EDC0...


or

id='457F9224A0...'>98AF014EDC0...


That works for me.



This would also be change of behavior from 3920.
Either way, it looks like we are going to introduce incompatibility 
with 3920.


A change of behavior can be backward-compatible. For example, rfc3920bis 
introduces a new SASL error condition and two new stanza error 
conditions. Those changes are backward-compatible since an older 
implementation knows that there is an error, but it doesn't understand 
the new error condition.



Yes, but it treats it as an error in case of sasl - which it is.



In the case of dialback, error handling was never specified very well. 
The only thing the Receiving Server can return to the Originating Server 
is a  element of type='valid' or type='invalid' (same for 
what the Authoritative Server returns to the Receiving server, except 
the element is ).



This is tricky.
We have two cases now - 3920-bis server trying piggybacking with 3920 
server & vice versa.


In the first case, since we go ahead and specify the behavior of 
piggybacking and since we expect recipient to always support it ('cos of 
the MUST), server will end up attempting piggybacking on a 3920 server 
which does not support it. We have servers which do not support it, have 
weird issues with it, or partially support it- and each case, the 
behavior is impl specific as to what 'happens' : ranging from invalid, 
error, stream termination, ignoring request, etc.


Reverse case

Re: [Standards] dialback: piggybacking

2007-06-21 Thread Mridul Muralidharan


Justin Karneges wrote:

On Thursday 21 June 2007 8:42 am, Peter Saint-Andre wrote:

Matthias Wimmer wrote:

Philipp Hancke schrieb:

Most of the complexity of piggybacking must be implemented on the
originating server. There are (lots of) pitfalls when deciding whether
to use piggybacking on 1.0 streams which are encrypted by TLS or
authenticated by SASL, etc.
Yet, as the spec does not mandate that you MUST reuse a connection, you
don't have to implement 'active' piggybacking.

What about discouraging active usage ("you don't want to implement
that") while keeping 'passive' support (on the receiving  server) for
backward compability?

I would not like to see active piggybacking discouraged. But maybe it
would really be a good idea to make passive support a MUST (should not
be hard to implement) while active support could get downgreaded from
SHOULD to MAY.

It's worth considering.


Of all the places in Jabber to value backwards compatibility, dialback is 
arguably the most important.  IMO, the real trouble is not the implementation 
difficulty, but the fact that dialback is underspecified in the RFCs.  Let's 
get this thing fully specified in the bis drafts, and then I agree with 
Matthias: MUST for receiving and MAY for sending is the most compatible path 
to take.


-Justin


MUST is a bit too strong. Unless the MUST is going to result in 'always 
return error saying piggybacking is not supported'.

Which would, imo, be against the spirit of introducing it anyway.

It is because dialback is important for bacjward compatibility (though 
something we should actively consider deprecating in favor of sasl 
external/etc) that I am not in favor of complicating it further.


Implementation fragility due to complexity is not a good thing to have 
in a spec - and dialback already allows various weird combinations 
possible in a cluster.


Mridul

Re: [Standards] dialback: piggybacking

2007-06-20 Thread Mridul Muralidharan


Mridul Muralidharan wrote:

Peter Saint-Andre wrote:

Matthias Wimmer wrote:

Hi Peter!

Peter Saint-Andre schrieb:
1. Dialback itself is not mandatory to implement, so a change to 
dialback would not affect the XMPP versioning.


Well ... I think it would be okay to just remove dialback without 
changing the versioning. But if you advertize support for dialback by 
including its namespace, you have to be compatible with dialback as 
specified in RFC 3920.


Right, everything in rfc3920bis will be backward-compatible with RFC3920.

2. Removing piggybacking from the specification would not mean that 
an implementation MUST NOT do piggybacking, only that such behavior 
is not specified.


Just removing specification would not make the situation better, I 
think.


I agree. Nothing says that piggybacking must be specified in 
rfc3920bis, but I think it's always better to document things than not 
to document them (well, except for the route and log stuff from 
jabberd 1.x).


Piggybacking was woefully underspecified in RFC 3920. The only text 
I can find is this:


**

After successful dialback negotiation, the Receiving Server SHOULD 
accept subsequent  packets (e.g., validation requests 
sent to a subdomain or other hostname serviced by the Receiving 
Server) from the Originating Server over the existing validated 
connection; this enables "piggybacking" of the original validated 
connection in one direction.


**


It is really interesting that it is only a SHOULD. I expected it to 
be a MUST. In the SHOULD case we indeet might be able to remove it. 
But still SHOULD means that it should be implemented as long as there 
are no "valid reasons in particular circumstances" not to implement 
it. (It's not the term "MAY".)


Correct.


We have tried to specify it more completely in rfc3920bis:

[...]

Reads okay ... but as you said it should be specified how error flows 
are handled. I.e. how a server not supporting piggybacking does 
refuse its use and how a server trying to do piggybacking has to 
react when the other server refuses its use.


Yes, let's fix that up.


The error flows are not well specified here. In particular:

1. What does the Receiving Server return to the Originating Server 
if it does not accept  over the validated connection?


My first thought was , but this would not 
allow to differentiate between a failed dialback and a dialback that 
is just not accepted on this connection.


Yes, and I think it would be good to differentiate between those two 
cases.


2. What does the Authoritative Server return to the Receiving Server 
if it does not accept  over the validated connection?


Same with 

Presumably, if the Receiving Server in #1 or the Authoritative 
Server in #2 does not want to do piggybacking, they would close the 
streams in question. But it is still possible for the Originating 
Server in #1 or the Receiving Server in #2 to send a  or 
 before the stream is closed, so we need to specify how 
these are handled. A  or  stream 
error?


I think that in this case the stream should not be closed. The server 
just refused to do additional authentication on this stream. It can 
still be used for the already authenticated domain.


Ah, OK.

Also the server should notify which db:result/db:verify was not 
accepted. So maybe it should return something like this:


from='example.net'>98AF014EDC0...


or

id='457F9224A0...'>98AF014EDC0...


That works for me.



This would also be change of behavior from 3920.
Either way, it looks like we are going to introduce incompatibility with 
3920.

So it would be better to just remove support for piggybacking.
I am not sure what sort of gain we get by having piggybacking around, 
but the relative increased complexity does lead to fragile 
implementations in s2s - even vanilla dialback + tls required + use/not 
use of 'xmpp 1.0', and combinations seems to have issues across servers.


Btw, are we not moving to using the stream feature instead of the db 
namespace in the stream to advertise dialback ?


In which case, we could just deprecate both use of the namespace, and 
support for dialback.


To be read as "In which case, we could just deprecate both use of the 
namespace to indicate support for dialback and piggybacking"



Mridul



Regards,
Mridul




I'll update rfc3920bis accordingly so we can see how it all looks.

Peter

Re: [Standards] dialback: piggybacking

2007-06-20 Thread Mridul Muralidharan


Peter Saint-Andre wrote:

Matthias Wimmer wrote:

Hi Peter!

Peter Saint-Andre schrieb:
1. Dialback itself is not mandatory to implement, so a change to 
dialback would not affect the XMPP versioning.


Well ... I think it would be okay to just remove dialback without 
changing the versioning. But if you advertize support for dialback by 
including its namespace, you have to be compatible with dialback as 
specified in RFC 3920.


Right, everything in rfc3920bis will be backward-compatible with RFC3920.

2. Removing piggybacking from the specification would not mean that 
an implementation MUST NOT do piggybacking, only that such behavior 
is not specified.


Just removing specification would not make the situation better, I think.


I agree. Nothing says that piggybacking must be specified in rfc3920bis, 
but I think it's always better to document things than not to document 
them (well, except for the route and log stuff from jabberd 1.x).


Piggybacking was woefully underspecified in RFC 3920. The only text I 
can find is this:


**

After successful dialback negotiation, the Receiving Server SHOULD 
accept subsequent  packets (e.g., validation requests 
sent to a subdomain or other hostname serviced by the Receiving 
Server) from the Originating Server over the existing validated 
connection; this enables "piggybacking" of the original validated 
connection in one direction.


**


It is really interesting that it is only a SHOULD. I expected it to be 
a MUST. In the SHOULD case we indeet might be able to remove it. But 
still SHOULD means that it should be implemented as long as there are 
no "valid reasons in particular circumstances" not to implement it. 
(It's not the term "MAY".)


Correct.


We have tried to specify it more completely in rfc3920bis:

[...]

Reads okay ... but as you said it should be specified how error flows 
are handled. I.e. how a server not supporting piggybacking does refuse 
its use and how a server trying to do piggybacking has to react when 
the other server refuses its use.


Yes, let's fix that up.


The error flows are not well specified here. In particular:

1. What does the Receiving Server return to the Originating Server if 
it does not accept  over the validated connection?


My first thought was , but this would not 
allow to differentiate between a failed dialback and a dialback that 
is just not accepted on this connection.


Yes, and I think it would be good to differentiate between those two cases.

2. What does the Authoritative Server return to the Receiving Server 
if it does not accept  over the validated connection?


Same with 

Presumably, if the Receiving Server in #1 or the Authoritative Server 
in #2 does not want to do piggybacking, they would close the streams 
in question. But it is still possible for the Originating Server in 
#1 or the Receiving Server in #2 to send a  or 
 before the stream is closed, so we need to specify how 
these are handled. A  or  stream 
error?


I think that in this case the stream should not be closed. The server 
just refused to do additional authentication on this stream. It can 
still be used for the already authenticated domain.


Ah, OK.

Also the server should notify which db:result/db:verify was not 
accepted. So maybe it should return something like this:


from='example.net'>98AF014EDC0...


or

id='457F9224A0...'>98AF014EDC0...


That works for me.



This would also be change of behavior from 3920.
Either way, it looks like we are going to introduce incompatibility with 
3920.

So it would be better to just remove support for piggybacking.
I am not sure what sort of gain we get by having piggybacking around, 
but the relative increased complexity does lead to fragile 
implementations in s2s - even vanilla dialback + tls required + use/not 
use of 'xmpp 1.0', and combinations seems to have issues across servers.


Btw, are we not moving to using the stream feature instead of the db 
namespace in the stream to advertise dialback ?
In which case, we could just deprecate both use of the namespace, and 
support for dialback.


Regards,
Mridul




I'll update rfc3920bis accordingly so we can see how it all looks.

Peter

Re: [Standards] UPDATED: XEP-0106 (JID Escaping)

2007-06-18 Thread Mridul Muralidharan


Peter Saint-Andre wrote:

XMPP Extensions Editor wrote:


CVS Diff:
http://svn.xmpp.org:18080/browse/XMPP/trunk/extensions/xep-0106.xml?r1=972&r2=644 



Yes, source control diffs are back, except now they are Subversion diffs 
instead of CVS diffs (must update my scripts).


Peter



Finally, this is great !
Thanks :)

- Mridul

Re: [Standards] compliance: cert(s)

2007-06-15 Thread Mridul Muralidharan


Peter Saint-Andre wrote:

Mridul Muralidharan wrote:

Justin Karneges wrote:

On Thursday 14 June 2007 2:59 pm, Peter Saint-Andre wrote:

Would it be appropriate to recommend that client and server developers
bundle support for the root certificate under which the XMPP ICA issues
domain certificates?


The XSF is not in a position to vouch for the trustworthiness of a 
certificate authority.  


+1


The XSF runs the XMPP Intermediate Certification Authority, so I'd hope 
we can trust it. We do not run the root CA upon which the XMPP ICA depends.


ICA has value since it provides as easy way to obtain an xmpp 
certificate with the oid defined ... which is usually a pain.
But this is just based on top of startcom - and the trust for startcom 
should come from web of trust, not because xsf vouches for it.

So xmpp ica is as trust worthy as startcom ca is.
If tomorrow we support other ca's, or possibly move away from ica, the 
protocol spec would still remain unchanged, and tls's web of trust will 
take care of certificate verification (for people with ocsp enabled for 
example).


Which is why I mentioned that we could have a wiki of a page which talks 
about how deployers/admins (not developers) can obtain xmpp certificates 
(we do not have client certs there do we ?) from xca and point a link 
from protocol to that page as 'helpful info'. This could then be 
referenced by developers, admin and deployers; while we could keep it up 
to date more easily.





 > At best, you could cite some other organization as being the
basis of the recommendation.  For example, a XEP could claim that 
StartCom is WebTrust-certified, and is therefore generally accepted 
as trustworthy for economic usage over the open internet.


That said, I think making a recommendation like this is mostly 
redundant.


Yes, if it is trusted, most keystores will already include it as a ca 
by default.


The certificate for the root CA is included in the Mozilla store, the 
store on various flavors of Linux as well as Mac OS X 10.5. I do not 
know when it might be included on Windows.



Not yet the last time I checked.

Mridul



Peter

Re: [Standards] dialback: piggybacking


Peter Saint-Andre wrote:
I received some extensive feedback on server dialback from someone 
offlist, and the commenter complained long and loud about the many 
ambiguities involved in the so-called "piggybacking" method described here:


http://www.xmpp.org/internet-drafts/draft-saintandre-rfc3920bis-02.html#dialback-reuse 



The suggestion is to remove piggybacking. I would like feedback from 
people on this list about whether that is desirable.


Thanks.

Peter



Totally agree.
I dislike piggybacking - and even had code which actively drop any s2s 
connection which attempts it.
Dialback is already complex enough with the edgecases, tls, pre-1.0 and 
what not without adding more to it.



Mridul

Re: [Standards] compliance: cert(s)


Justin Karneges wrote:

On Thursday 14 June 2007 2:59 pm, Peter Saint-Andre wrote:

Would it be appropriate to recommend that client and server developers
bundle support for the root certificate under which the XMPP ICA issues
domain certificates?


The XSF is not in a position to vouch for the trustworthiness of a certificate 
authority.  


+1

> At best, you could cite some other organization as being the
basis of the recommendation.  For example, a XEP could claim that StartCom is 
WebTrust-certified, and is therefore generally accepted as trustworthy for 
economic usage over the open internet.


That said, I think making a recommendation like this is mostly redundant.


Yes, if it is trusted, most keystores will already include it as a ca by 
default.


Mridul



-Justin

Re: [Standards] adding body as RECOMMENDED field for PEP-protocols?


Peter Saint-Andre wrote:

Adam Nemeth wrote:

On 6/11/07, Olivier Goffart <[EMAIL PROTECTED]> wrote:


And i would even put the body element in the root of the message 
element. So

even client that doesn't support pubsub can receive such message



Hmm... I disagree here a bit, but of course, you're the developer, so
the final decision is always yours ;) Here are my reasons:

1) It's not standard compliant I believe: every pubsub event is a
subchild of  field (at least I think this looking at XEP-0060
examples), so you can't go out of this field anyway without breaking
the protocol

2) We want (at least, me :) PEP protocols to spread, so I believe it
would be a bad idea to let it be granted (after all, it's not a
message, it's not a presence, but something in between, probably
closer to presence but not that close)

3) Personally I'd like to see it through knotify/growl, and not a
message - since it would be hard to tell if user typed it in or it is
just automatic eventing from AmaroK. Example:

http://jabbermania.blogspot.com/2007/05/general-pubsub-pep-receiver.html

Look at the picture (mockup of knotify).

Of course it's only my personal taste, but differentiating eventing
protocols from standard messages is a feature I believe.


This gets back to something that Justin Karneges keeps mentioning. If 
you receive a message with a  will your client just assume it's a 
regular old chat message? Probably. So then you're going to have all 
sorts of messages popping up "Adam is giving a presentation", "Oliver is 
 at the movies", "Peter is listening to Heart of the Sunrise" and so on, 
it will drive you crazy and you'll quickly curse the day you ever 
enabled that feature.


Peter




You are right, application payloads getting sent (as messages) should, 
imo, not contain  unless it expects to communicate that to the user.
In a lot of cases for pep typically, it would be consumed by the client 
to appropriately add meta-data for the contact - it just would not make 
sense to show the plain text info to user.


That being said, we should not preclude addition of body, it might make 
sense for usecases (maybe where pep is more used like pubsub with 
infrequent updates ?)


Mridul

Re: [Standards] compliance: RFCs or bis drafts?