[standards-jig] Re: Standards-JIG digest, Vol 1 #371 - 10 msgs

Jean-Louis Seguineau/EXC/TEC jean-louis.seguineau at antepo.com
Thu Nov 14 09:08:26 UTC 2002


Thanks for the comment. That said, I totaly agree that a decent feature
negotiation is the way to go. Our answer to the problem was, as you rightly
said, in a controled environment. And as Richard pointed out, it has also
the drawback of broadcasting the extra extension to all buddies.
That said, if we go for a feature negotiation, we need to define how and
when in the sequence of event this is going to take place. The more we add
to the login sequence before the client is seen online may have adverse user
experience on slow networks (like wireless).

More generaly speaking, shouldn't we have a true agreed upon way to have
seemless adaptation of any client to any server in terms of features.  What
I mean by that is a document (a JEP) describing what the behaviour of a
client and of a server should be when they don't support certain features. I
know there is some "agreed practices" but I have never seen it formaly
expressed in a document. (Peter ?) The outcome would be to have a set of
best practice recommendations as to server/client response to non
implemented features, and may be a limited number of recommended
alternatives to advertise/discover features according to client
capabilities.


----- Original Message -----
> Message: 1
> Date: Wed, 13 Nov 2002 11:30:50 -0700
> From: Craig Kaes <ckaes at jabber.com>
> To: standards-jig at jabber.org
> Subject: Re: [standards-jig] Re: thoughts on POP3 Offline (JEP-0013)
> Reply-To: standards-jig at jabber.org
>
> I like this approach, Jean-Louis.  It meets about 95% of the need and
> all of your need.  For installations controlling both server and client,
> it is sufficient.  The case I'd like to be able to handle with feature
> negotiation that falls through the cracks in your approach is this:
>
> 1)  I have a client that supports POP3 offline.
> 2)  I'm connecting to a server that doesn't support POP3 offline.
> 3)  I do not ever want to be flooded with offline messages.
>
> I do like the simplicity of your approach but it just can't handle a
> case like this -- I'd like the option to see a dialogue like "Only flood
> offline supported on server -- set presence to available anyway?"
>
> A non-feature-negotiation patch to this would be to just send the header
> request from the client before sending initial presence.  If it errors,
> it must be unsupported....
>
> --C
>
> Jean-Louis Seguineau/EXC/TEC wrote:
>
> >Peter,
> >
> >I do not totally aggree with your statement quote:
> >
> >
> >>   Without the ability to query a given client for feature sets,
> >>   POP3-like offline message handling is incompatible with the
> >>   existing offline model.
> >>
> >>
> >
> >We have implemented a very simple model that allow both offline message
> >handling to work together without resorting to the full feature
negitiation>
> >The offline message retrieval is triggered by the initial presence a
client
> >is sending to the server. If you ad an extension to the presence message,
> >then the client has a way to advertise its support for a given namespace.
> >The client sends the following snippet (this is an extract of our
> >implementation of the offline management, hence the different namspace,
but
> >it can easily be converted):
> >
> ><presence>
> >
> ><show>Chat</show>
> >
> ><status>Here I am again.</status>
> >
> ><x xmlns='xmpp:x:omm'/>
> >
> >        </presence>
> >
> >and the server is answering with an headline message such as
> >
> ><message type='headline' to='user at domain'>
> >
> ><subject>Offline messages</subject>
> >
> ><body>You have 4 offline messages waiting</body>
> >
> ><x xmlns='xmpp:x:omm'>
> >
> ><item jid='contact1 at domain' count='3'/>
> >
> ><item jid='contact2 at domain'/>
> >
> ></x>
> >
> >          </message>
> >
> >from then on you are back to using the normal iq to handle the rest of
the
> >dialog. This is a generic solution that allow to catter for offline
> >managemet aware client and the old generation.
> >
> >--jean louis
> >
> >----- Original Message -----
> >
> >
> >>Date: Mon, 11 Nov 2002 13:15:59 -0600 (CST)
> >>From: Peter Saint-Andre <stpeter at jabber.org>
> >>To: standards-jig at jabber.org
> >>Subject: [standards-jig] thoughts on POP3 Offline (JEP-0013)
> >>Reply-To: standards-jig at jabber.org
> >>
> >>Based on discussions held in the last Council meeting [1], I've thought
> >>some more about JEP-0013 (POP3 Handling of Offline Messages) [2]. Here
are
> >>some tentative suggestions:
> >>
> >>1. It would be good to bring the namespace into line with the newer
> >>conventions (e.g., "http://jabber.org/protocol/offline").
> >>
> >>2. It would be good for a user to receive more information in the
headers.
> >>Specifically, the subject and thread might be useful.
> >>
> >>3. Section 2.4 (Compatibility) says the following:
> >>
> >>   Without the ability to query a given client for feature sets,
> >>   POP3-like offline message handling is incompatible with the
> >>   existing offline model.
> >>
> >>This was true when the JEP was written but is no longer accurate given
> >>the existence of JEP-0020 (Feature Negotiation) [3]. I suggest that
> >>handling of offline messages is a fine example of feature negotiation.
It
> >>might work as follows:
> >>
> >>Step 1. User logs in but does not send presence.
> >>
> >>Step 2. User asks if the offline namespace is supported.
> >>
> >><iq type='get' to='myserver' id='a1'>
> >>  <query xmlns='jabber:iq:disco'/>
> >></iq>
> >>
> >>Step 3. Server replies in the affirmative.
> >>
> >><iq type='result' from='myserver' to='me at myserver/foo' id='a1'>
> >>  <query xmlns='jabber:iq:disco'>
> >>    ...
> >>    <feature type='http://jabber.org/protocol/offline'/>
> >>    ...
> >>  </query>
> >></iq>
> >>
> >>Step 4. User asks if pop3 handling of offline messages is supported.
> >>
> >><iq type='get' id='a2'>
> >>  <query xmlns='jabber:iq:negotiate'>
> >>    <feature type='http://jabber.org/protocol/offline'>
> >>      <option>pop3</option>
> >>    </feature>
> >>  </query>
> >></iq>
> >>
> >>Step 5. Server replies in the affirmative.
> >>
> >><iq type='result' from='myserver' to='me at myserver/foo' id='a2'/>
> >>
> >>Step 6. User retrieves headers as shown in Example 1 of the JEP.
> >>
> >>And so on from there.
> >>
> >>4. David Waite suggested retrieving offline messages via disco. I played
> >>around with this some but it would seem to require that at some point in
> >>the process every message is a JID (e.g., me at myserver/indox/some-uid)
> >>which is sub-optimal IMHO.
> >>
> >>Thoughts?
> >>
> >>Peter
> >>
> >>[1] log at
> >>
> >>
> >>
>
>http://www.jabber.org/chatbot/logs/conference.jabber.org/foundation/2002-11
-
> >08.html
> >
> >
> >>[2] http://www.jabber.org/jeps/jep-0013.html
> >>
> >>[3] http://www.jabber.org/jeps/jep-0020.html
> >>
> >>--
> >>Peter Saint-Andre
> >>Jabber Software Foundation
> >>http://www.jabber.org/people/stpeter.php
> >>
> >>
> >>
> >
> >
> >_______________________________________________
> >Standards-JIG mailing list
> >Standards-JIG at jabber.org
> >http://mailman.jabber.org/listinfo/standards-jig
> >
> >
> >
>
>
>
>
> --__--__--
>
> Message: 2
> Date: Wed, 13 Nov 2002 12:50:46 -0600 (CST)
> From: Peter Saint-Andre <stpeter at jabber.org>
> To: standards-jig at jabber.org
> Subject: Re: [standards-jig] NEW JEP: Private XML Storage
> Reply-To: standards-jig at jabber.org
>
> These changes are all interesting and good. I'm going to send JEP-0049 to
> last call since it's just informational, but maybe a standards-track
> proposal would be in order?
>
> Peter
>
> --
> Peter Saint-Andre
> Jabber Software Foundation
> http://www.jabber.org/people/stpeter.php
>
> On Mon, 11 Nov 2002, Robert Norris wrote:
>
> > > Unless I'm mistaken, there _was_ a rationale to that decision. If you
> > > don't restrict what namespaces can be stored via iq:private, end users
> > > could overwrite stuff like their roster with pure goobdley-gook (since
> > > iq:private packets are directly unwrapped and sent off as typically
XDB
> > > calls).
> >
> > Makes sense. However, that is specific to the original implementation -
> > jabberd2 will store private data seperately, so there is no need for
> > this restriction.
> >
> > --
> > Robert Norris                                       GPG: 1024D/FC18E6C2
> > Email+Jabber: rob at cataclysm.cx                Web: http://cataclysm.cx/
> >
>
>
> --__--__--
>
> Message: 3
> Date: Wed, 13 Nov 2002 12:54:03 -0600 (CST)
> From: Peter Saint-Andre <stpeter at jabber.org>
> To: standards-jig at jabber.org
> Subject: [standards-jig] LAST CALL: jabber:iq:private (JEP-0049)
> Reply-To: standards-jig at jabber.org
>
> I hereby issue a Last Call on JEP-0049. This is an informational JEP that
> documents current usage of the 'jabber:iq:private' namespace. This is not
> a standards-track proposal. If you see errors in the documentation, please
> bring them to the attention of the list.
>
> This Last Call will end on Monday, November 25, 2002.
>
> http://www.jabber.org/jeps/jep-0049.html
>
> Peter
>
> --
> Peter Saint-Andre
> Jabber Software Foundation
> http://www.jabber.org/people/stpeter.php
>
>
>
> --__--__--
>
> Message: 4
> Date: Wed, 13 Nov 2002 12:57:10 -0600 (CST)
> From: Peter Saint-Andre <stpeter at jabber.org>
> To: standards-jig at jabber.org
> Subject: [standards-jig] LAST CALL: jabber:iq:search (JEP-0055)
> Reply-To: standards-jig at jabber.org
>
> I hereby issue a Last Call on JEP-0055. This is an informational JEP that
> documents current usage of the 'jabber:iq:search' namespace. This is not
> a standards-track proposal. If you see errors in the documentation, please
> bring them to the attention of the list.
>
> This Last Call will end on Monday, November 25, 2002.
>
> http://www.jabber.org/jeps/jep-0055.html
>
> Peter
>
> --
> Peter Saint-Andre
> Jabber Software Foundation
> http://www.jabber.org/people/stpeter.php
>
>
> --__--__--
>
> Message: 5
> Date: Wed, 13 Nov 2002 13:00:14 -0600 (CST)
> From: Peter Saint-Andre <stpeter at jabber.org>
> To: standards-jig at jabber.org
> Subject: [standards-jig] LAST CALL: vcard-temp (JEP-0054)
> Reply-To: standards-jig at jabber.org
>
> I hereby issue a Last Call on JEP-0054. This is an informational JEP that
> documents current usage of the 'vcard-temp' namespace. This is not a
> standards-track proposal. If you see errors in the documentation, please
> bring them to the attention of the list.
>
> This Last Call will end on Monday, November 25, 2002.
>
> http://www.jabber.org/jeps/jep-0054.html
>
> BTW, I've sent an email to the author of the original Internet-Draft
> regarding the <CTRY/> element in our DTD. All of his DTDs have this
> element as <COUNTRY/> so I'm suspicious that this is a typo in our DTD,
> but I'm double-checking on this. Perhaps someone who was involved in the
> original documentation of this DTD within the Jabber community could chime
> in if I'm wrong here.
>
> Peter
>
> --
> Peter Saint-Andre
> Jabber Software Foundation
> http://www.jabber.org/people/stpeter.php
>
>
> --__--__--
>
> Message: 6
> From: Joe Hildebrand <JHildebrand at jabber.com>
> To: "'standards-jig at jabber.org'" <standards-jig at jabber.org>
> Subject: RE: [standards-jig] RFC822 style JIDs
> Date: Wed, 13 Nov 2002 12:19:19 -0700
> Reply-To: standards-jig at jabber.org
>
> I actually use @ in resources quite frequently, more from server
components
> than user connections.
>
> --
> Joe Hildebrand
>
>
> > -----Original Message-----
> > From: Justin Karneges [mailto:justin-jdev at affinix.com]
> > Sent: Tuesday, November 12, 2002 9:03 PM
> > To: standards-jig at jabber.org
> > Subject: Re: [standards-jig] RFC822 style JIDs
> >
> >
> > I agree with putting the same restrictions as the node to the
> > resource.  I
> > guess the question really, is are there any current implementations /
> > applications that utilize these characters we wish to restrict?
> >
> > Personally, I've only witnessed these characters on rare
> > occasions.  I've seen
> > resources like "windows/home" or "Psi at work", but these are
> > hand crafted and
> > thus not a problem (future servers could deny these resources
> > with an error,
> > no change needed in the clients).
> >
> > The only problematic resource I've seen is "Jabber Instant
> > Messenger", which
> > interestingly does not use any of the characters we are
> > discussing, but
> > instead uses spaces, which JEP-0029 does not allow.  That
> > considered, it is
> > arguably easier to put a restriction on " | & | ' | / | : | <
> > | > | @, since
> > nobody uses them.  Putting a restriction on spaces is going
> > to require a JIM
> > awareness campaign.
> >
> > So maybe there could be a bigger debate about whether or not
> > resources should
> > be allowed to contain spaces.  After all, you might want a
> > space in your
> > groupchat nickname (at least moreso than any of these other
> > weird characters
> > we'd like to restrict).  One possibility is that the resource
> > could be
> > URL-encoded.  So a space would become %20.  Maybe the server
> > could do this
> > conversion on-the-fly as an optional transitional feature.
> >
> > With that in mind, I think it should not be a problem at all
> > to add a few more
> > character restrictions to JEP-0029 and call it good.
> >
> > -Justin
> >
> > On Tuesday 12 November 2002 01:56 pm, Peter Saint-Andre wrote:
> > > Why not go all the way and apply the node identifier
> > restrictions to the
> > > resource identifier? Then the following would be disallowed:
> > >
> > >    " | & | ' | / | : | < | > | @
> > >
> > > Those need to be escaped now, but would anyone be seriously
> > hindered if
> > > they were disallowed?
> > >
> > > Since JEP-0029 is deferred, it's probably best to discuss
> > this on the
> > > xmppwg list, but it can't hurt to find out what people's
> > feelings are
> > > here.
> > >
> > > Peter
> > >
> > > --
> > > Peter Saint-Andre
> > > Jabber Software Foundation
> > > http://www.jabber.org/people/stpeter.php
> > >
> > > On Tue, 12 Nov 2002, Justin Karneges wrote:
> > > > Hi all,
> > > >
> > > > JEP-0029 proposes a JID definition:
> > > > http://www.jabber.org/jeps/jep-0029.html
> > > >
> > > > Would it also be worthwhile to add additional restriction to the
> > > > Resource, to exclude angle brackets?  This way, full JIDs could be
> > > > represented in a simple, parsable, RFC822-style text format:
> > > >
> > > >   Peter Saint-Andre <stpeter at jabber.org/Work>
> > > >
> > > > Since Jabber is often attributed to email, it would be
> > nice if JIDs could
> > > > be represented in the same way as an email address.
> > > >
> > > > -Justin
> > > > _______________________________________________
> > > > Standards-JIG mailing list
> > > > Standards-JIG at jabber.org
> > > > http://mailman.jabber.org/listinfo/standards-jig
> > >
> > > _______________________________________________
> > > Standards-JIG mailing list
> > > Standards-JIG at jabber.org
> > > http://mailman.jabber.org/listinfo/standards-jig
> >
> > _______________________________________________
> > Standards-JIG mailing list
> > Standards-JIG at jabber.org
> > http://mailman.jabber.org/listinfo/standards-jig
> >
>
> --__--__--
>
> Message: 7
> From: "Richard Dobson" <richard at dobson-i.net>
> To: <standards-jig at jabber.org>
> Subject: Re: [standards-jig] Re: thoughts on POP3 Offline (JEP-0013)
> Date: Wed, 13 Nov 2002 19:19:05 -0000
> Reply-To: standards-jig at jabber.org
>
> The problem with this is that the <x xmlns='xmpp:x:omm'/> will be
> broadcasted inside your presence to everyone in your roster, IMO an IQ
based
> command is much more appropriate and will also allow the client to find
out
> if offline messaging is supported at all by seeing if an error response is
> generated.
>
> Richard
>
> ----- Original Message -----
> From: "Jean-Louis Seguineau/EXC/TEC" <jean-louis.seguineau at antepo.com>
> To: <standards-jig at jabber.org>
> Sent: Wednesday, November 13, 2002 5:52 PM
> Subject: [standards-jig] Re: thoughts on POP3 Offline (JEP-0013)
>
>
> > Peter,
> >
> > I do not totally aggree with your statement quote:
> > >    Without the ability to query a given client for feature sets,
> > >    POP3-like offline message handling is incompatible with the
> > >    existing offline model.
> >
> > We have implemented a very simple model that allow both offline message
> > handling to work together without resorting to the full feature
> negitiation>
> > The offline message retrieval is triggered by the initial presence a
> client
> > is sending to the server. If you ad an extension to the presence
message,
> > then the client has a way to advertise its support for a given
namespace.
> > The client sends the following snippet (this is an extract of our
> > implementation of the offline management, hence the different namspace,
> but
> > it can easily be converted):
> >
> > <presence>
> >
> > <show>Chat</show>
> >
> > <status>Here I am again.</status>
> >
> > <x xmlns='xmpp:x:omm'/>
> >
> >         </presence>
> >
> > and the server is answering with an headline message such as
> >
> > <message type='headline' to='user at domain'>
> >
> > <subject>Offline messages</subject>
> >
> > <body>You have 4 offline messages waiting</body>
> >
> > <x xmlns='xmpp:x:omm'>
> >
> > <item jid='contact1 at domain' count='3'/>
> >
> > <item jid='contact2 at domain'/>
> >
> > </x>
> >
> >           </message>
> >
> > from then on you are back to using the normal iq to handle the rest of
the
> > dialog. This is a generic solution that allow to catter for offline
> > managemet aware client and the old generation.
>
>
> --__--__--
>
> Message: 8
> Date: Wed, 13 Nov 2002 13:29:44 -0600 (CST)
> From: Peter Saint-Andre <stpeter at jabber.org>
> To: "'standards-jig at jabber.org'" <standards-jig at jabber.org>
> Subject: RE: [standards-jig] RFC822 style JIDs
> Reply-To: standards-jig at jabber.org
>
> Well, I'd prefer to leave well enough alone since we don't really know how
> people want to use resources -- I can definitely see a use for '/' and '@'
> and probably a few others that are forbidden by the node identifier spec.
> Many such characters need to be escaped anyway when the entity provides
> the resource on login (e.g., <resource><work/></resource>).
>
> The specific concern that Justin raised was enabling JIDs to be shown in
> RFC822 style, such as <stpeter at jabber.org> or (including the resource)
> <stpeter at jabber.org/Work>. If I create a funky resource like
> <work>office</work> then such a representation looks weird. But I see no
> special reason to follow RFC822 syntax in Jabber.
>
> Peter
>
> --
> Peter Saint-Andre
> Jabber Software Foundation
> http://www.jabber.org/people/stpeter.php
>
> On Wed, 13 Nov 2002, Joe Hildebrand wrote:
>
> > I actually use @ in resources quite frequently, more from server
components
> > than user connections.
> >
> > --
> > Joe Hildebrand
> >
> >
> > > -----Original Message-----
> > > From: Justin Karneges [mailto:justin-jdev at affinix.com]
> > > Sent: Tuesday, November 12, 2002 9:03 PM
> > > To: standards-jig at jabber.org
> > > Subject: Re: [standards-jig] RFC822 style JIDs
> > >
> > >
> > > I agree with putting the same restrictions as the node to the
> > > resource.  I
> > > guess the question really, is are there any current implementations /
> > > applications that utilize these characters we wish to restrict?
> > >
> > > Personally, I've only witnessed these characters on rare
> > > occasions.  I've seen
> > > resources like "windows/home" or "Psi at work", but these are
> > > hand crafted and
> > > thus not a problem (future servers could deny these resources
> > > with an error,
> > > no change needed in the clients).
> > >
> > > The only problematic resource I've seen is "Jabber Instant
> > > Messenger", which
> > > interestingly does not use any of the characters we are
> > > discussing, but
> > > instead uses spaces, which JEP-0029 does not allow.  That
> > > considered, it is
> > > arguably easier to put a restriction on " | & | ' | / | : | <
> > > | > | @, since
> > > nobody uses them.  Putting a restriction on spaces is going
> > > to require a JIM
> > > awareness campaign.
> > >
> > > So maybe there could be a bigger debate about whether or not
> > > resources should
> > > be allowed to contain spaces.  After all, you might want a
> > > space in your
> > > groupchat nickname (at least moreso than any of these other
> > > weird characters
> > > we'd like to restrict).  One possibility is that the resource
> > > could be
> > > URL-encoded.  So a space would become %20.  Maybe the server
> > > could do this
> > > conversion on-the-fly as an optional transitional feature.
> > >
> > > With that in mind, I think it should not be a problem at all
> > > to add a few more
> > > character restrictions to JEP-0029 and call it good.
> > >
> > > -Justin
> > >
> > > On Tuesday 12 November 2002 01:56 pm, Peter Saint-Andre wrote:
> > > > Why not go all the way and apply the node identifier
> > > restrictions to the
> > > > resource identifier? Then the following would be disallowed:
> > > >
> > > >    " | & | ' | / | : | < | > | @
> > > >
> > > > Those need to be escaped now, but would anyone be seriously
> > > hindered if
> > > > they were disallowed?
> > > >
> > > > Since JEP-0029 is deferred, it's probably best to discuss
> > > this on the
> > > > xmppwg list, but it can't hurt to find out what people's
> > > feelings are
> > > > here.
> > > >
> > > > Peter
> > > >
> > > > --
> > > > Peter Saint-Andre
> > > > Jabber Software Foundation
> > > > http://www.jabber.org/people/stpeter.php
> > > >
> > > > On Tue, 12 Nov 2002, Justin Karneges wrote:
> > > > > Hi all,
> > > > >
> > > > > JEP-0029 proposes a JID definition:
> > > > > http://www.jabber.org/jeps/jep-0029.html
> > > > >
> > > > > Would it also be worthwhile to add additional restriction to the
> > > > > Resource, to exclude angle brackets?  This way, full JIDs could be
> > > > > represented in a simple, parsable, RFC822-style text format:
> > > > >
> > > > >   Peter Saint-Andre <stpeter at jabber.org/Work>
> > > > >
> > > > > Since Jabber is often attributed to email, it would be
> > > nice if JIDs could
> > > > > be represented in the same way as an email address.
> > > > >
> > > > > -Justin
> > > > > _______________________________________________
> > > > > Standards-JIG mailing list
> > > > > Standards-JIG at jabber.org
> > > > > http://mailman.jabber.org/listinfo/standards-jig
> > > >
> > > > _______________________________________________
> > > > Standards-JIG mailing list
> > > > Standards-JIG at jabber.org
> > > > http://mailman.jabber.org/listinfo/standards-jig
> > >
> > > _______________________________________________
> > > Standards-JIG mailing list
> > > Standards-JIG at jabber.org
> > > http://mailman.jabber.org/listinfo/standards-jig
> > >
> > _______________________________________________
> > Standards-JIG mailing list
> > Standards-JIG at jabber.org
> > http://mailman.jabber.org/listinfo/standards-jig
> >
>
>
> --__--__--
>
> Message: 9
> Date: Wed, 13 Nov 2002 13:08:54 -0700
> From: Craig Kaes <ckaes at jabber.com>
> To: standards-jig at jabber.org
> Subject: Re: [standards-jig] RFC822 style JIDs
> Reply-To: standards-jig at jabber.org
>
> As long as we're opening up this can of worms, how do folks at large
> like the node identifier requirement that they be compared in a case
> insensitive manner but case must maintained?  In implementing a simple
> pubsub mechanism, this forces one to maintain a case-folded
> canonicalized JID (for queries like "show all subscriptions held by
> foo at bar.com") as well as the JID that was sent in (for sending of
> notifications to "FoO at bar.com").  Why can't I just send to the
> case-folded canonicalized JID?  The current implementations may not
> route cacnonicalized JIDs having multibyte characters correctly, but
> that is no reason to muddy the spec with this requirement, IMHO.
>
> --C
>
> Peter Saint-Andre wrote:
>
> >Well, I'd prefer to leave well enough alone since we don't really know
how
> >people want to use resources -- I can definitely see a use for '/' and
'@'
> >and probably a few others that are forbidden by the node identifier spec.
> >Many such characters need to be escaped anyway when the entity provides
> >the resource on login (e.g., <resource><work/></resource>).
> >
> >The specific concern that Justin raised was enabling JIDs to be shown in
> >RFC822 style, such as <stpeter at jabber.org> or (including the resource)
> ><stpeter at jabber.org/Work>. If I create a funky resource like
> ><work>office</work> then such a representation looks weird. But I see no
> >special reason to follow RFC822 syntax in Jabber.
> >
> >Peter
> >
> >--
> >Peter Saint-Andre
> >Jabber Software Foundation
> >http://www.jabber.org/people/stpeter.php
> >
> >
> >
>
>
> --__--__--
>
> Message: 10
> From: "Richard Dobson" <richard at dobson-i.net>
> To: <standards-jig at jabber.org>
> Subject: Re: [standards-jig] LAST CALL: jabber:iq:private (JEP-0049)
> Date: Wed, 13 Nov 2002 19:05:27 -0000
> Reply-To: standards-jig at jabber.org
>
> It is missing an example of the current behaviour when you query for a
> namespace that has not been previously stored, i.e. return the query as
the
> result.
>
> Richard
>
> ----- Original Message -----
> From: "Peter Saint-Andre" <stpeter at jabber.org>
> To: <standards-jig at jabber.org>
> Sent: Wednesday, November 13, 2002 6:54 PM
> Subject: [standards-jig] LAST CALL: jabber:iq:private (JEP-0049)
>
>
> > I hereby issue a Last Call on JEP-0049. This is an informational JEP
that
> > documents current usage of the 'jabber:iq:private' namespace. This is
not
> > a standards-track proposal. If you see errors in the documentation,
please
> > bring them to the attention of the list.
> >
> > This Last Call will end on Monday, November 25, 2002.
> >
> > http://www.jabber.org/jeps/jep-0049.html
> >
> > Peter
> >
> > --
> > Peter Saint-Andre
> > Jabber Software Foundation
> > http://www.jabber.org/people/stpeter.php
> >
> >
> > _______________________________________________
> > Standards-JIG mailing list
> > Standards-JIG at jabber.org
> > http://mailman.jabber.org/listinfo/standards-jig
> >
>
>
>
> --__--__--
>
> _______________________________________________
> Standards-JIG mailing list
> Standards-JIG at jabber.org
> http://mailman.jabber.org/listinfo/standards-jig
>
>
> End of Standards-JIG Digest
>




More information about the Standards mailing list