headers
Nolan Eakins | 5 Oct 2005 11:16

Schema errors

I decided to be lazy and started parsing the XMPP schemas up at XMPP.org 
so I could pull out all the element names. "server.xsd" is missing an 
end tag for "statusType". That probably needs to be added so the schema 
is valid.

- Nolan

--

-- 
SemanticGap: To act as one (TM) -- http://www.semanticgap.com/
Instant awareness & messaging * Online presence design
Cross platform and agile development
Permalink | Reply | 1 comment |
headers
Peter Saint-Andre | 5 Oct 2005 18:25

Re: Schema errors

Nolan Eakins wrote:
> I decided to be lazy and started parsing the XMPP schemas up at XMPP.org 
> so I could pull out all the element names. "server.xsd" is missing an 
> end tag for "statusType". That probably needs to be added so the schema 
> is valid.

That was a copy and paste error. Fixed here:

http://www.xmpp.org/schemas/server.xsd

Peter
Attachment (smime.p7s): application/x-pkcs7-signature, 3511 bytes
Permalink | Reply | 0 comments |
headers
Tony Finch | 20 Oct 2005 15:04
Picon
Favicon

subdomains

[sorry if this is the wrong list for this kind of question]

I'm trying to get to grips with jabber, so I've read the XMPP RFCs. I was
puzzled by the special case handling for subdomains which is written into
the specs (especially section 10 of RFC 3920). The assumption seems to be
that the service provided by a subdomain is intimately tied to the service
provided by the domain itself. This assumption can be wrong.

I would have thought that the restriction is unnecessary. It would seem
simpler to just treat domains as opaque strings, which the server either
knows how to handle locally (either processing stanzas itself or passing
them to a specialized service), or routes routes stanzas to in the usual
s2s way.

Section 10.3 seems to prevent a large organization from having both an
organization-wide jabber server and departmental servers. For example, if
I set up a jabber server at cam.ac.uk then that server is required to
consider all subdomains of cam.ac.uk to be its responsibility. This
prevents a department from setting up their own jabber server (e.g.
because they want closer integration with their departmental email server)
without co-operation from me and extra configuration of my server.

Have I understood this part of the protocol correctly? Is this how
server implementations work in practice?

Tony.
--

-- 
f.a.n.finch  <dot <at> dotat.at>  http://dotat.at/
BISCAY: WEST 5 OR 6 BECOMING VARIABLE 3 OR 4. SHOWERS AT FIRST. MODERATE OR
GOOD.
(Continue reading)

Permalink | Reply | 2 comments |
headers
Ralph Meijer | 24 Oct 2005 23:04
Picon

Incorrect SASL Digest MD5 example in XMPP Core

Hi all,

While attempting to implement SASL authentication in Twisted, I
discovered a discrepancy between RFC 2831 (Using Digest Authentication
as a SASL Mechanism) and the examples 6.5 and 6.6 in RFC 3920 (XMPP
Core) that do DIGEST-MD5 SASL authentication.

The discrepancy is about Step 3 (section 2.1.3) of RFC 2831. After
the server having sent a challenge in Step 1 and the client sending a response
in Step 2, Step 3 is the server checking this response and sending an
'rspauth'. This is not a challenge, but extra information for subsequent
authorization, sent along with the affirmation of a succesful authentication.

The ACAP example in section 4 of RFC 2831 shows this. However, the IMAP
example needs an extra roundtrip because there is no way in IMAP to do
both an 'OK' and send along this rspauth information. Probably the IMAP
example was taken to erroneously craft the example in XMPP Core.

Peter Saint-Andre made mention of this error in the notes for
RFC3920bis. You can find that here:
http://www.xmpp.org/xmppbis.html#sasl.  For the correct authentication
sequence of example 6.5, step 7 is changed and steps 8 and 9 removed:

  Step 7: Server informs client of successful authentication and sends
  the [BASE64] encoded value for subsequent authentication to client:

  <success xmlns='urn:ietf:params:xml:ns:xmpp-sasl'>
  cnNwYXV0aD1lYTQwZjYwMzM1YzQyN2I1NTI3Yjg0ZGJhYmNkZmZmZAo=
  </success>
(Continue reading)

Permalink | Reply | 7 comments |
headers
Peter Saint-Andre | 25 Oct 2005 00:38

Re: [xmppwg] Incorrect SASL Digest MD5 example in XMPP Core

Thanks for the error report, we will definitely fix this in rfc3920bis 
and I will look into having the IETF also publish an erratum as well.

Peter

Ralph Meijer wrote:
> Hi all,
> 
> While attempting to implement SASL authentication in Twisted, I
> discovered a discrepancy between RFC 2831 (Using Digest Authentication
> as a SASL Mechanism) and the examples 6.5 and 6.6 in RFC 3920 (XMPP
> Core) that do DIGEST-MD5 SASL authentication.
> 
> The discrepancy is about Step 3 (section 2.1.3) of RFC 2831. After
> the server having sent a challenge in Step 1 and the client sending a response
> in Step 2, Step 3 is the server checking this response and sending an
> 'rspauth'. This is not a challenge, but extra information for subsequent
> authorization, sent along with the affirmation of a succesful authentication.
> 
> The ACAP example in section 4 of RFC 2831 shows this. However, the IMAP
> example needs an extra roundtrip because there is no way in IMAP to do
> both an 'OK' and send along this rspauth information. Probably the IMAP
> example was taken to erroneously craft the example in XMPP Core.
> 
> Peter Saint-Andre made mention of this error in the notes for
> RFC3920bis. You can find that here:
> http://www.xmpp.org/xmppbis.html#sasl.  For the correct authentication
> sequence of example 6.5, step 7 is changed and steps 8 and 9 removed:
> 
>   Step 7: Server informs client of successful authentication and sends
(Continue reading)

Permalink | Reply | 0 comments |
headers
Matthias Wimmer | 26 Oct 2005 10:28

Question regarding section 10.1 (Blocking Communication - Syntax and Sematics) of RFC 3921

I am implementing the privacy lists in jabberd14 and I am not sure how 
to interpret section 10.1 of RFC 3921 at present.

What I do not completely understand is the paragraph about the matching 
order of JIDs.

"[...]JIDs SHOULD be matched in the following order:

1. <user <at> domain/resource> (only that resource matches)
2. <user <at> domain> (any resource matches)
3. <domain/resource> (only that resource matches)
4. <domain> (the domain itself matches, as does any user <at> domain, 
domain/resource, or address containing a subdomain)"

What is meant here by "order"?

E.g. if I have two following two items in a privacy list:

<item type='jid' value='example.com' order='1' action='deny'/>
<item type='jid' value='user <at> example.com' order='2' action='allow'/>

A message is arriving from user <at> example.com. Do I have to accept or deny 
the message? The order attribute of the rules tell, that I have to match 
against the first item first. - Bug the matching order of JIDs tell me, 
that I should match <user <at> domain> before <domain>.

I think, that it just means that a rule for user <at> domain/resource will 
always only match a given user on a given server using a given resource 
but nothing else. - While a rule for user <at> domain matches only a given 
user on a given server, but allowing any resource to match. - While
(Continue reading)

Permalink | Reply | 19 comments |
headers
Peter Saint-Andre | 27 Oct 2005 21:36

Re: Resource binding question

On 2005-06-18, Vinod Panicker wrote:
> 
> If there is a stream over which Resource Binding has successfully
> happened, should the client be allowed to perform Resource Binding
> again if it requests?

Not in RFC 3920. What's the use case? Theoretically it would be nice to 
offer that functionality, but I'm trying to understand why it might be 
needed. (And of course if you tried to bind a new resource, the server 
could always return an error if changing the resource is not allowed.)

Peter
Attachment (smime.p7s): application/x-pkcs7-signature, 3641 bytes
Permalink | Reply | 0 comments |
headers
Ralph Meijer | 28 Oct 2005 11:50
Picon

Re: subdomains

On Thu, Oct 20, 2005 at 02:04:09PM +0100, Tony Finch wrote:
> [sorry if this is the wrong list for this kind of question]
> 
> I'm trying to get to grips with jabber, so I've read the XMPP RFCs. I was
> puzzled by the special case handling for subdomains which is written into
> the specs (especially section 10 of RFC 3920). The assumption seems to be
> that the service provided by a subdomain is intimately tied to the service
> provided by the domain itself. This assumption can be wrong.
> 
> I would have thought that the restriction is unnecessary. It would seem
> simpler to just treat domains as opaque strings, which the server either
> knows how to handle locally (either processing stanzas itself or passing
> them to a specialized service), or routes routes stanzas to in the usual
> s2s way.
> 
> Section 10.3 seems to prevent a large organization from having both an
> organization-wide jabber server and departmental servers. For example, if
> I set up a jabber server at cam.ac.uk then that server is required to
> consider all subdomains of cam.ac.uk to be its responsibility. This
> prevents a department from setting up their own jabber server (e.g.
> because they want closer integration with their departmental email server)
> without co-operation from me and extra configuration of my server.
> 
> Have I understood this part of the protocol correctly? Is this how
> server implementations work in practice?

If you have deployed a company wide and some departmental servers the
stanzas destined for those departmental servers would be delivered
directly to them by the origin server, based on DNS.
(Continue reading)

Permalink | Reply | 1 comment |
headers
Tony Finch | 28 Oct 2005 15:05
Picon
Favicon

Re: subdomains

On Fri, 28 Oct 2005, Ralph Meijer wrote:
>
> If a stanza does get to your company wide server (most probably from a
> connected client), it should not recognise the departmental servers'
> domains as 'internal' and revert to trying DNS to deliver the stanza
> just like section 10.2.

That makes sense, but it isn't what the RFC says. In fact that behaviour
is explicitly forbidden.

Perhaps this is an item for 3920bis?

Tony.
--

-- 
f.a.n.finch  <dot <at> dotat.at>  http://dotat.at/
BISCAY: WEST 5 OR 6 BECOMING VARIABLE 3 OR 4. SHOWERS AT FIRST. MODERATE OR
GOOD.
Permalink | Reply | 0 comments |

Gmane