Subject: [xmpp] what goes where?

From: Peter Saint-Andre <[email-masked]>
Date: Thu, 25 Jun 2009 11:12:17 -0600

The division between "core" and "im/pres" (RFC 3920 and RFC 3921)
reflected a preference expressed by Pete Resnick, co-chair of the
original XMPP WG (2002-2004). I have a few questions:

1. Do people find this division useful?

2. Would it be better or worse to combine this material into one large
specification?

3. Would some other division be even more useful? For example, I have
long toyed with the following:

- - One spec for XML streams, which would be agnostic regarding the
default namespace and thus show people how they could use XML streams
for default namespaces other than jabber:client and jabber:server. This
would be essentially Sections 1-7 of draft-ietf-xmpp-3920bis-00, along
with most of Sections 12, 14, 15, and 16.

- - One spec for the "Jabber" application, i.e., the jabber:client and
jabber:server namespaces. This would essentially be Sections 8, 9, and
11 of draft-ietf-xmpp-3920bis-00 along with all of 3921bis.

While such an approach has a certain conceptual appeal, I think it would
be a lot of work to split up the content in that way, and I have my
doubts that the results would be worth the time and effort required.

Peter

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

---

From: Jiří Zárevúcky <[email-masked]>
Date: Thu, 25 Jun 2009 19:54:30 +0200

2009/6/25 Peter Saint-Andre <[email-masked]>:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>

I certainly do.

> 2. Would it be better or worse to combine this material into one large

I think it would be worse. I like the way CORE describes
stream/session initiation and tear-down, while IM is just about stanza
semantics.

> long toyed with the following:

I'm skeptical about that. The current division seems logical to me.

> doubts that the results would be worth the time and effort required.

I agree that such change wouldn't be worthwhile.

---

From: Curtis King <[email-masked]>
Date: Thu, 25 Jun 2009 11:35:32 -0700

> 1. Do people find this division useful?

Yes.

> 2. Would it be better or worse to combine this material into one large

much worse.

>
> 3. Would some other division be even more useful?

I also think it would be worse to split the RFCs up too much.

Note: I'm in favor of getting the bis drafts moved to RFC status  
sooner than later, as they are hugh improvement over current RFCs. I  
think it will be hard to make any more significant improvements to the  
drafts.

ck

---

From: Alexey Melnikov <[email-masked]>
Date: Thu, 25 Jun 2009 20:18:34 +0100

Hi Peter,
In my capacity of an individual contributor:

Yes.

>2. Would it be better or worse to combine this material into one large
I think combining would be worse. I personally hate big documents.

>long toyed with the following:
Further partitioning might be helpful, but only if you have time to do 
it ;-).

As counter argument: keep in mind that preserving existing structure 
might help diffing the new documents against original RFCs. This is 
*very* helpful to IESG ;-).

---

From: Peter Saint-Andre <[email-masked]>
Date: Thu, 25 Jun 2009 14:10:11 -0600

>> 1. Do people find this division useful?

OK.

> I think combining would be worse. I personally hate big documents.

Me, too.

> Further partitioning might be helpful, but only if you have time to do

I think the cost/benefit ratio is not favorable. There are more
productive ways for me to spend my time...

> *very* helpful to IESG ;-).

Duly noted. :)

Peter

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

---

From: Peter Saint-Andre <[email-masked]>
Date: Thu, 25 Jun 2009 14:16:38 -0600

On 6/25/09 12:35 PM, Curtis King wrote:

> Note: I'm in favor of getting the bis drafts moved to RFC status sooner
> than later, as they are hugh improvement over current RFCs. I think it
> will be hard to make any more significant improvements to the drafts.

Why, thanks! I have put a lot of work into the bis drafts. My goal is
for them to be the best RFCs ever written. :)

IMHO there are still some things we need to fix in these specs, but we
can file issues in the issue tracker:

http://trac.tools.ietf.org/wg/xmpp/trac/report/1

I'll start to do that soon. In fact anyone can file issues, just sign up
for an account here:

http://trac.tools.ietf.org/newpasswd

Peter

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

---

From: Dave Cridland <[email-masked]>
Date: Fri, 26 Jun 2009 10:07:14 +0100

Yes.

> 2. Would it be better or worse to combine this material into one  
Worse, but mostly for the psychological impact of dealing with such a  
huge document.

> long toyed with the following:
Gah.

I'd agree that there isn't actually a clean split between -CORE and  
-IM, in as much as -CORE describes <iq/> stanzas that we aren't, yet,  
told how to route and process, but I don't really worry about this  
much. In any practical deployment of XMPP, people are going to be  
using both XMPP-CORE and XMPP-IM anyway, and working too much on how  
the specifications should be split or combined is a lot of effort  
when really, they're going to be read together anyway.

At the moment, however, I don't have to think about which spec to  
look something up in, and I'd be happy to keep things that way.

Dave.
-- 
Dave Cridland - mailto:[email-masked] - xmpp:[email-masked]
  - acap://acap.dave.cridland.net/byowner/user/dwd/bookmarks/
  - http://dave.cridland.net/
Infotrope Polymer - ACAP, IMAP, ESMTP, and Lemonade

---

From: Remko Tronçon <[email-masked]>
Date: Fri, 26 Jun 2009 11:41:07 +0200

> I have a few questions:

I always found the division of the specs pretty odd because of what Dave
mentioned, that the two specs depend on each other (i.e. 3920 talks about
things only introduced in 3921). I'm not sure how useful the split is from a
technical point of view, since all XMPP implementations implement both specs
anyway (and I'm not sure how an implementation of 3920 looks like without
3921, exactly because of its dependency).  I do agree that collapsing them
would generate too big of a spec to psychologically handle.

I guess I would have felt more comfortable if the split was done more in a
way that would make both specs clearly separated, and make 3920 a real
standalone thing (and would feel even more comfortable if there were
actually real life use cases of 3920 without 3921). But on the other hand,
I'm not feeling so strong about it that I would invest Peter's valuable time
in it ;-)

cheers,
Remko

---

From: Kevin Smith <[email-masked]>
Date: Fri, 26 Jun 2009 11:55:02 +0100

I've never understood the split between the two beyond the need not to
 have a huge spec, but it's never caused me any hardship either so I
 see no need to spend time changing it.

 /K

---

From: Pedro Melo <[email-masked]>
Date: Fri, 26 Jun 2009 10:51:40 +0100

Hi,

Yes.

> 2. Would it be better or worse to combine this material into one large

No.

> long toyed with the following:

As parts of the spec become obsolete or no longer recommended, it  
might make sense to pull those outside the RFC and into XEP's, but  
right now, I don't see any parts of the current spec that would qualify.

And as Alexey pointed out, keeping the same structure as rfc392{0,1}  
is very usefull for diff'ing.

Best regards,
-- 
Pedro Melo
Blog: http://www.simplicidade.org/notes/
XMPP ID: [email-masked]
Use XMPP!