Subject: [xmpp] Last Call: <draft-ietf-xmpp-3920bis-17.txt> (Extensible Messaging and Presence Protocol (XMPP): Core) to Proposed Standard

From: The IESG <[email-masked]>
Date: Thu, 07 Oct 2010 08:00:09 -0700

The IESG has received a request from the Extensible Messaging and
Presence Protocol WG (xmpp) to consider the following document:
- 'Extensible Messaging and Presence Protocol (XMPP): Core'
  <draft-ietf-xmpp-3920bis-17.txt> as a Proposed Standard

The IESG plans to make a decision in the next few weeks, and solicits
final comments on this action. Please send substantive comments to the
[email-masked] mailing lists by 2010-10-21. Exceptionally, comments may be
sent to [email-masked] instead. In either case, please retain the
beginning of the Subject line to allow automated sorting.

In particular, this document contains a normative reference to a document of
lower maturity level:

RFC 3447: Public-Key Cryptography Standards (PKCS) #1: RSA Cryptography 
Specifications Version 2.1

The IESG is interested in community feedback on whether this
downward reference is appropriate.

The file can be obtained via
https://datatracker.ietf.org/doc/draft-ietf-xmpp-3920bis/

IESG discussion can be tracked via
https://datatracker.ietf.org/doc/draft-ietf-xmpp-3920bis/

No IPR declarations were found that appear related to this I-D.

---

From: Martin Rex <[email-masked]>
Date: Fri, 8 Oct 2010 05:01:05 +0200 (MEST)

> Specifications Version 2.1

To me, it looks like this document is INFORMATIONAL, published in 2003,
and the Abstract of this document clearly states

http://tools.ietf.org/html/rfc3447#abstract

   This memo represents a republication of PKCS #1 v2.1 from RSA
   Laboratories' Public-Key Cryptography Standards (PKCS) series, and
   change control is retained within the PKCS process.  The body of this
   document is taken directly from the PKCS #1 v2.1 document, with
   certain corrections made during the publication process.

So the document is as mature as it can get.

I'm currently a little confused about CMS (rfc-5652) which appears to
be at the highest possible maturity level (STANDARD).  CMS lists PKCS#1
only as informative reference, although it is entirely impossible
to do CMS SignedData and CMS EncryptedData with RSA keypairs without
using PKCS#1.  :)

Seeing this question on the mailing list, I'm getting the impression
that some formal processes might have edges that would benefit from an
encounter with Mr. Grinder.  ;-)

-Martin

---

From: Jehan Pagès <[email-masked]>
Date: Sat, 16 Oct 2010 01:02:27 +0900

Hi,

> beginning of the Subject line to allow automated sorting.

A few remarks I just noted:

1) 3.2.4 Use of SRV Records with Add-On Services

«
If an entity from a remote domain
   wishes to use such add-on services, it would generate an appropriate
   XML stanza and the remote domain itself would attempt to resolve the
   service's hostname via an SRV lookup on resource records such as
   "_xmpp-server._tcp.conference.example.net." or "_xmpp-
   server._tcp.muc.example.com.".
»

"remote domain" should be replaced by "remote server" (or remote
service), at least in the second instance: "the remote server itself
would attempt to resolve the service hostname". Because a "domain"
does not resolve another domain (but a server does, or more
"abstractly" a service does, but really "domain" is just technically
wrong).

It could be then:

«
If an entity from a remote domain
   wishes to use such add-on services, it would generate an appropriate
   XML stanza and the associated remote server itself would attempt to
resolve the
   service's hostname via an SRV lookup on resource records such as
   "_xmpp-server._tcp.conference.example.net." or "_xmpp-
   server._tcp.muc.example.com.".
»

2) Moreover the plural is used "add-on services", then singular:
"service's hostname". So if I remember correctly my English lessons
from school (at least for this, I think I do), it should be "services'
hostnames" (should "hostname" be pluralized as well?), or else our
example is about one service: "use such add-on service".

(sorry for this non-technical one)

3) 4.1 Streams Overview

The streams are represented as unidirectional so the initial stream
and the response stream (even though they actually typically use the
same tcp connection) are considered as separate. As explained for
instance by this text:

«
The initial stream enables unidirectional
      communication from the initiating entity to the receiving entity;
      in order to enable exchange of stanzas from the receiving entity
      to the initiating entity, the receiving entity MUST negotiate a
      stream in the opposite direction (the "response stream").
»

But the "Figure 2: A Simplified Stream" shows stanzas from both the
initial and response stream (as we can read an iq with to="bar" and
another with from="bar"). So this figure (even though "simplified")
contradicts the 2-stream model and should be adapted.

4) 9.2 Server-to-Server Examples

«
Note how Server1 declares the content namespace "jabber:
   server" as the default namespace and prefixes for stream-related
   elements, whereas Server2 uses prefix-free canonicalization.
»

But, in "4.7.2 Content Namespace" has been edicted the rule:
«
(2) the
   content namespace MUST be the same for the initial stream and the
   response stream so that both streams are qualified consistently
»

So it is contradictory to me, unless we meant that IF the response
stream uses also the content namespace, it must be the same, but it
MAY still use the prefix-free canonicalization instead. Anyway
something is unclear and has to be fixed somewhere.

For the fix, if it was depending only on me, I would remove this rule
(2) in 4.7.2 and not change the example of section 9.2, because the
reality is that most (any?) XMPP implementation nowadays uses real XML
parsers keeping memory of namespace contexts (and if not, I would
advise they should) and won't get lost anyway by different entities
using different namespace default/declaration, etc. So the example in
9.2 should be anyway no problem for nowaydays servers... I hope. For
me all our rules for namespace-prefix specific naming, and default,
etc. are just silly (but we already had this discussion. I just wanted
to write it again to mark my point. Maybe after some years, more and
more people will agree to this. :p).
But if you prefer, you can also change the example. Or else there is
no contradiction, hence I will read with great pleasure the
explanation. :-)

That's all for now, I think.
Bye.

Jehan

---

From: Peter Saint-Andre <[email-masked]>
Date: Fri, 15 Oct 2010 15:09:17 -0600

On 10/15/10 10:02 AM, Jehan Pagès wrote:

> « If an entity from a remote domain wishes to use such add-on
> services, it would generate an appropriate XML stanza and the remote
> domain itself would attempt to resolve the service's hostname via an
> SRV lookup on resource records such as 
> server._tcp.muc.example.com.". »
> 

It's a small point, but you're right.

> It could be then:
> 
> « If an entity from a remote domain wishes to use such add-on
> services, it would generate an appropriate XML stanza and the
> associated remote server itself would attempt to resolve the 
> server._tcp.muc.example.com.". »

I now have:

   If an entity associated with a remote
   XMPP server wishes to use such an add-on service, it would generate
   an appropriate XML stanza and the remote server would attempt to
   resolve the add-on service's DNS domain name via an SRV lookup on
   resource records such as "_xmpp-server._tcp.conference.example.net."
   or "_xmpp-server._tcp.muc.example.com.".

> from school (at least for this, I think I do), it should be
> "services' hostnames" (should "hostname" be pluralized as well?), or
> else our example is about one service: "use such add-on service".
> 

Fixed.

> « The initial stream enables unidirectional communication from the
> initiating entity to the receiving entity; in order to enable
> exchange of stanzas from the receiving entity to the initiating
> entity, the receiving entity MUST negotiate a stream in the opposite
> direction (the "response stream"). »
> 

Sure, I've cleaned up the ASCII art to show two streams...

###

   In essence, then, one XML stream functions as an envelope for the XML
   stanzas sent during a session and another XML stream functions as an
   envelope for the XML stanzas received during a session.  We can
   represent this in a simplistic fashion as follows.

   +--------------------+--------------------+
   | INITIAL STREAM     |  RESPONSE STREAM   |
   +--------------------+--------------------+
   | <stream>           |                    |
   |--------------------|--------------------|
   |                    | <stream>           |
   |--------------------|--------------------|
   | <presence>         |                    |
   |   <show/>          |                    |
   | </presence>        |                    |
   |--------------------|--------------------|
   | <message to='foo'> |                    |
   |   <body/>          |                    |
   | </message>         |                    |
   |--------------------|--------------------|
   | <iq to='bar'       |                    |
   |     type='get'>    |                    |
   |   <query/>         |                    |
   | </iq>              |                    |
   |--------------------|--------------------|
   |                    | <iq from='bar'     |
   |                    |     type='result'> |
   |                    |   <query/>         |
   |                    | </iq>              |
   |--------------------|--------------------|
   | [ ... ]            |                    |
   |--------------------|--------------------|
   |                    | [ ... ]            |
   |--------------------|--------------------|
   | </stream>          |                    |
   |--------------------|--------------------|
   |                    | </stream>          |
   +--------------------+--------------------+

                Figure 2: A Simplistic View of Two Streams

###

> « Note how Server1 declares the content namespace "jabber: server" as
> the default namespace and prefixes for stream-related elements,
> whereas Server2 uses prefix-free canonicalization. »
> 
> But, in "4.7.2 Content Namespace" has been edicted the rule: « (2)
> the content namespace MUST be the same for the initial stream and
> the response stream so that both streams are qualified consistently 
> »
> 

Yes, "if". That's what 4.7.2 already says:

   An entity MAY declare a "content namespace" as the default namespace
   for data sent over the stream (i.e., data other than elements
   qualified by the streams namespace).  If so, (1) the content
   namespace MUST be other than the streams namespace, and (2) the
   content namespace MUST be the same for the initial stream and the
   response stream so that both streams are qualified consistently.

The first two words of the second sentence are "If so, ..."

> For the fix, if it was depending only on me, I would remove this
> rule (2) in 4.7.2 and not change the example of section 9.2, because
> the reality is that most (any?) XMPP implementation nowadays uses
> real XML parsers keeping memory of namespace contexts (and if not, I
> would advise they should) and won't get lost anyway by different
> entities using different namespace default/declaration, etc. So the
> example in 9.2 should be anyway no problem for nowaydays servers... I
> hope. For me all our rules for namespace-prefix specific naming, and
> default, etc. are just silly (but we already had this discussion. I
> just wanted to write it again to mark my point. Maybe after some
> years, more and more people will agree to this. :p). But if you
> prefer, you can also change the example. Or else there is no
> contradiction, hence I will read with great pleasure the explanation.
> :-)

See above.

Peter

-- 
Peter Saint-Andre
https://stpeter.im/

---

From: Jehan Pagès <[email-masked]>
Date: Sat, 16 Oct 2010 22:36:38 +0900

Hi,

>   or "_xmpp-server._tcp.muc.example.com.".

Nice.

>> (sorry for this non-technical one)

Indeed.

>   represent this in a simplistic fashion as follows.

Seems good to me.

>> contradiction, hence I will read with great pleasure the explanation.

Hum... Ok. That still looks strange to me, but probably is it only me.
:-) Fine for me anyway.

Thanks.

Jehan