[standards-jig] RFC draft 3.0

James Barry JMBarry at jabber.com
Thu Feb 14 21:58:25 UTC 2002


General comments below.  The specifics I'll let 

> -----Original Message-----
> From: Iain Shigeoka [mailto:iainshigeoka at yahoo.com]
> Sent: Thursday, February 14, 2002 1:06 PM
> To: Jabber standards
> Subject: Re: [standards-jig] RFC draft 3.0
> 
> 
> Hello,
> 
> A lot of these are nit picks but since you asked for it... :) 

They are all good points please keep the reviews coming in.

We did fix the abstract/introduction duplication problem, as well as made
the intro more "speclike".  
> 
> I'm also thinking that perhaps the whole security issue 
> should be moved out
> into its own RFC or other doc as well and just mentioned in 
> this RFC.  There
> is just so much information in here...  OTOH, I realize that 
> this may be
> just a way to "throw it all out there" in which case, this 
> may be the best
> way to go.  I suppose the question is whether this is an RFC 
> for defining
> implementation compliance or simply an FYI.

The intent of this is the be an informational document in IETF parlance.
The only reason this copy doesn't say that is we have yet to figure out how
to do that in the generator that we run it through from the IETF.  

We want first to submit Jabber as a informational RFC, so that we can be
documented at the IETF.  Right now people can search the IETF database and
not find any info on Jabber.  This should allow us to get published without
debate only as an informational document.  We felt this is necessary because
of the growing volume of Jabber usage throughout the Internet, and the lack
of "official" documentation. 

Secondarily we will "chunk" the protocol into pieces that make sense and
work with the appropriate IETF areas to make them standardized through the
normal process.  IRC did this in 2000 to get their latest protocol changes
documented. (RFC #'s 2811,2812,2813.) What this effectively means is that
the next version of this RFC will be in pieces that are more narrowly
focused and functional in their description and together make up Jabber as
it will be in the future.  We may also do another historical (++) where we
fix some of the underlying problems with Jabber but keep it together as a
whole specification (Like separation of the transport layer from the rest of
the protocol, and having proper namespace support.) 

All this RFC should represent is how Jabber works today.  Section 13
outlines what we could be working on for future specifications.  Today lets
get what is used down properly.  Tomorrow we can piece part the new advances
in the standards groups where we will submit.

>  Great job Peter!
> 
I wholeheartedly agree !!!

James Barry
jmbarry at jabber.com
303.308.3275
JID:jmbarry at jabber.com 



More information about the Standards mailing list