headers
Lisa Dusseault | 1 Nov 2002 06:06
Favicon

JEPs and Internet-Drafts

I've noticed this week a couple references to content/proposals in JEP
documents.  What is the group's intent with respect to these documents?

IETF practice is that unless proposals are published in Internet-Draft
format.  The Internet-Draft format entails certain guarantees:  that the
draft will be readable by pretty much everybody, that they are archived
in a predictable manner, that there are certain intellectual property
rights guaranteed to the IETF, and finally that anybody interested can
get notified about new versions in a predictable manner.

Because of this practice, it wouldn't be a good idea to refer people to
JEP documents during Working Group meetings (ie. Atlanta).  Attendees
who read I-Ds but do not keep up with the mailing list will be
justifiably annoyed, because the general practice is that if one reads
up on the I-Ds published by a working group one is sufficiently informed
to have an opinion.  

It's not too late to add material from important JEPs to the three
existing I-Ds if we plan to discuss that material in Atlanta. The
deadline for updates to existing I-Ds is Nov 4 so there's not much time.
It's already too late for brand new drafts.

While we're at it, we should start planning the agenda for subjects to
be discussed at the Atlanta meeting.  Have I missed any thoughts on that
subject?

BTW It's a pleasure to be involved in XMPP & I'm looking forward to
working with everybody in this group.

lisa
(Continue reading)

Permalink | Reply | 2 comments |
headers
Marshall Rose | 1 Nov 2002 10:01
Picon
Picon

Re: JEPs and Internet-Drafts

> I've noticed this week a couple references to content/proposals in JEP
> documents.  What is the group's intent with respect to these documents?

it depends on the jep. there are a couple that are pretty relevant to the
charter (e.g., doing sasl in jabber), and there are quite a few that are out of
scope with respect to the charter.

> IETF practice is that unless proposals are published in Internet-Draft
> format.  The Internet-Draft format entails certain guarantees:  that the
> draft will be readable by pretty much everybody, that they are archived
> in a predictable manner, that there are certain intellectual property
> rights guaranteed to the IETF, and finally that anybody interested can
> get notified about new versions in a predictable manner.
> 
> Because of this practice, it wouldn't be a good idea to refer people to
> JEP documents during Working Group meetings (ie. Atlanta).  Attendees
> who read I-Ds but do not keep up with the mailing list will be
> justifiably annoyed, because the general practice is that if one reads
> up on the I-Ds published by a working group one is sufficiently informed
> to have an opinion.  

i agree.

> It's not too late to add material from important JEPs to the three
> existing I-Ds if we plan to discuss that material in Atlanta. The
> deadline for updates to existing I-Ds is Nov 4 so there's not much time.
> It's already too late for brand new drafts.

i think the only jeps of substantive interest are the ones talking
about sasl, tls, and gpg.
(Continue reading)

Permalink | Reply | 1 comment |
headers
Lisa Dusseault | 1 Nov 2002 18:44
Favicon

Availability of offline storage

In draft-miller-xmpp-core-01.txt, Appendix A provides an error code
(503) that the server can return to the message sender if the message
cannot be delivered. This section describes that the service may support
offline message storage, which would affect whether or not this error
code is returned.

First, is offline message storage in-charter?  Is it a basic required
feature? If the answer to these is "no", then perhaps the draft is fine
on this point, or could use minor text adjustments to make it clear that
offline message storage is not defined.  Also
draft-miller-xmpp-im-01.txt may need similar clarification in section 8.

However, if offline message storage is intended to be an interoperable
feature of XMPP right off the bat, there are more questions to be
answered.  Most concern interoperability between the XMPP server and the
client that will eventually receive the offline messages, but the first
one concerns the message-sending client.
 1.  Doesn't the message-sending user get confused if delivery is
successful, believing that the message popped up on their buddy's
screen? IOW, is there a need for a separate error message for "delivery
successful but not immediate"?
 2.  Is there a need for the message-receiving client software to be
able to know if their xmpp server supports offline message storage? 
 3.  If the XMPP server does support offline storage, how are those
messages delivered when the client comes online? Does the XMPP client
receive a flood of messages if many have arrived?  Can the client
request the stored messages one by one to impose flood control on the
server?  Can the client postpone the delivery of stored messages for
later?
 4.  How does the client know when offline stored messages were
(Continue reading)

Permalink | Reply | 4 comments |
headers
Lisa Dusseault | 1 Nov 2002 18:52
Favicon

XML Extensibility and DTDs

I've been looking at the DTDs in draft-miller-xmpp-core-01.txt.  For
example, the DTD for 'presence' includes:

   <!ELEMENT presence (( show? | status? | priority? | error? )*)>

Is it the intent that in the future, somebody (particularly the XMPP WG)
could extend the 'presence' element to include other elements such as
'location' or 'presence-timeout', in order to introduce advanced
features?  If so, I presume it's also important for clients and servers
that are implemented based on the base XMPP specifications to ignore
elements that they don't understand.  We could theoretically allow
extensions to introduce sub-elements that can safely be ignored by
clients/servers not yet aware of the extensions.

The WebDAV WG does this with its XML, but has found that some
implementers use DTDs to strictly determine validity of a
request/response. For example, if any element in addition to (show,
status, priority, error) shows up inside 'presence', a validating parser
would reject the packet.  Since that approach causes any XML containing
extension sub-elements to fail, WebDAV draft editors have started to put
extra effort into encouraging implementers to accept (and ignore)
extensions.  For example, we've started writing DTDs that include
English text, such as:

   <!ELEMENT presence ANY >

   ANY: May contain zero or more of any of the sub-elements from (show, 
	status, priority, error).  May contain additional elements which

	must be ignored if not understood.
(Continue reading)

Permalink | Reply | 25 comments |
headers
Peter Saint-Andre | 1 Nov 2002 19:10

Re: JEPs and Internet-Drafts

Speaking as the JEP Editor and the primary I-D author, I can say the
intent is this:

Anything that is relevant to the XMPP WG discussions will be incorporated
into the I-Ds. This would include SASL, i81n, and OpenPGP. Standards-track
JEPs that were created on such topics will be deprecated or dropped, and
informational JEPs will remain active. So for example the SASL JEP -- even
though it is a Draft document in the JSF's process, it will be deprecated
in favor of whatever is decided by the XMPP WG. Of course there are many
JEPs that address functionality that is not required by RFC 2779, for
example the JEP I recently wrote on multi-user chat. It is possible that
such JEPs will be reformatted and then submitted as I-Ds in the future,
but that is out of scope right now. What is in scope is borrowing
protocols from existing JEPs and working those protocols into the I-Ds
when appropriate (e.g., with regard to end-to-end encryption using PGP). I
am in the process of doing that now.

As I tried to express in the WG announcement I put on the jabber.org
website yesterday, we see the JSF process as a testing ground for
protocols that *may* in the future be submitted to the IETF's process
(certainly some of the things we discuss in the JSF are neither necessary
nor appropriate for work within the IETF). Obviously the JSF has discussed
some protocols in the past that now overlap with the focus of the WG, but
those are "legacy" JEPs, as it were, and such overlap will be avoided if
at all possible in the future.

Hope that helps.

Peter
(Continue reading)

Permalink | Reply | 0 comments |
headers
Peter Saint-Andre | 1 Nov 2002 19:20

Re: XML Extensibility and DTDs

If we were starting over, there would be no defined children of either
<presence/> or <message/> -- that is, each of these would be the same as
<iq/>, which does not have defined children but rather is extended by
children in separate namespaces. So I think now we would do things like
this:

<presence>
  <x xmlns='http://jabber.org/protocol/availability'>
    <show>xa</show>
    <status>In a meeting</status>
  </x>
  <x xmlns='http://jabber.org/protocol/location'>
    <long>104.87</long>
    <lat>39.75</lat>
  </x>
</presence>

Or something along those lines.

The defined children of message and presence are "legacy" elements and I
would think that all future extensions would occur in the manner outlined
above. We may even want to show how the current child elements could be
handled using namespaced child elements as outlined above.

Peter

--
Peter Saint-Andre
Jabber Software Foundation
http://www.jabber.org/people/stpeter.php
(Continue reading)

Permalink | Reply | 24 comments |
headers
Lisa Dusseault | 1 Nov 2002 19:52
Favicon

RE: XML Extensibility and DTDs

This is another thing I don't understand.  What is the 'x' element? Why
do we have an element named 'x'?  Why not name the one for availability
'availability', and the one for location 'location'?

lisa

> -----Original Message-----
> From: Peter Saint-Andre [mailto:stpeter <at> jabber.org]
> Sent: Friday, November 01, 2002 10:21 AM
> To: xmppwg <at> jabber.org
> Subject: Re: [xmppwg] XML Extensibility and DTDs
> 
> If we were starting over, there would be no defined children of either
> <presence/> or <message/> -- that is, each of these would be the same
as
> <iq/>, which does not have defined children but rather is extended by
> children in separate namespaces. So I think now we would do things
like
> this:
> 
> <presence>
>   <x xmlns='http://jabber.org/protocol/availability'>
>     <show>xa</show>
>     <status>In a meeting</status>
>   </x>
>   <x xmlns='http://jabber.org/protocol/location'>
>     <long>104.87</long>
>     <lat>39.75</lat>
>   </x>
> </presence>
(Continue reading)

Permalink | Reply | 23 comments |
headers
Peter Saint-Andre | 1 Nov 2002 20:00

RE: XML Extensibility and DTDs

Because all that matters is the namespace. The element name is immaterial.

Peter

--
Peter Saint-Andre
Jabber Software Foundation
http://www.jabber.org/people/stpeter.php

On Fri, 1 Nov 2002, Lisa Dusseault wrote:

> This is another thing I don't understand.  What is the 'x' element? Why
> do we have an element named 'x'?  Why not name the one for availability
> 'availability', and the one for location 'location'?
> 
> lisa
> 
> > -----Original Message-----
> > From: Peter Saint-Andre [mailto:stpeter <at> jabber.org]
> > Sent: Friday, November 01, 2002 10:21 AM
> > To: xmppwg <at> jabber.org
> > Subject: Re: [xmppwg] XML Extensibility and DTDs
> > 
> > If we were starting over, there would be no defined children of either
> > <presence/> or <message/> -- that is, each of these would be the same
> as
> > <iq/>, which does not have defined children but rather is extended by
> > children in separate namespaces. So I think now we would do things
> like
> > this:
(Continue reading)

Permalink | Reply | 22 comments |
headers
Lisa Dusseault | 1 Nov 2002 20:21
Favicon

RE: XML Extensibility and DTDs

That's one way of looking at it.  Another way of looking at it is that
the element name is the important information, and the namespace is only
a way to make the element name unique. One way of making the element
name unique is by using a name already reserved to the owner/creator,
but there are other ways.  For example, namespaces can be GUIDs, which
have no meaning but definitely solve the uniquify-element-name problem.

That said, I don't really know what advantages lie on either side.  Is
it a disadvantage to have "namespace explosion"?  By putting the
element's meaningful name inside the namespace, we would create many
more namespaces.  Is there a manageability problem there?

I believe it is a disadvantage to diverge from standard practice.  Since
I've never seen 'x' elements before (in IETF use of XML or in W3C use of
XML), I assume this diverges from standard practice.  I'd like to
understand the benefits that would outweigh the disadvantage.

Lisa

> -----Original Message-----
> From: Peter Saint-Andre [mailto:stpeter <at> jabber.org]
> Sent: Friday, November 01, 2002 11:01 AM
> To: xmppwg <at> jabber.org
> Subject: RE: [xmppwg] XML Extensibility and DTDs
> 
> Because all that matters is the namespace. The element name is
immaterial.
> 
> Peter
>
(Continue reading)

Permalink | Reply | 21 comments |
headers
David Waite | 1 Nov 2002 21:24

Re: Availability of offline storage

I would agree that we should indicate that offline message storage is 
not defined by the existing I-Ds. Hopefully we can put it out of 
charter.

Discovery if offline message storage is present on your account or on 
the recipient's account is not currently defined with any publicly 
documented protocol.  Notification of message delivery to offline vs. 
an active client has some publicly documented protocol in the form of 
an informational JEP, but there are several known issues with that 
proposal.

-David Waite

On Friday, Nov 1, 2002, at 10:44 America/Denver, Lisa Dusseault wrote:

> In draft-miller-xmpp-core-01.txt, Appendix A provides an error code
> (503) that the server can return to the message sender if the message
> cannot be delivered. This section describes that the service may 
> support
> offline message storage, which would affect whether or not this error
> code is returned.
>
> First, is offline message storage in-charter?  Is it a basic required
> feature? If the answer to these is "no", then perhaps the draft is fine
> on this point, or could use minor text adjustments to make it clear 
> that
> offline message storage is not defined.  Also
> draft-miller-xmpp-im-01.txt may need similar clarification in section 
> 8.
>
(Continue reading)

Permalink | Reply | 1 comment |

Gmane