Re: [Standards] updated Sensors proposal

[Nathan Fritz]

This feedback is obviously very late, but here it is just the same.
The reason that I vetoed this spec is specifically that I think
sending commands over Publish-Subscribe is a misuse of the spec.
Commands generally require error handling and acknowledgement.
Additionally, I don't see the use-case for broadcasting commands to
subscribers in this spec. IQ payloads, XEP-0050, and others handle
sending commands, and given the nature of the examples in the spec, I
think these would be better suited for the "setValue" scenario.

I encourage you to either provide an example and argument against my
reasons stated or re-submit the spec using a more appropriate method
for setValue.  I agree that this has use, but I disagree with the
current form for sending commands.

I apologize that this feedback is so late.

-Nathan Fritz

Re: [Standards] [Council] Minutes 2010-12-08

[Nathan Fritz]

+1 on Remote Auth being accepted as a XEP.

On Fri, Dec 10, 2010 at 9:51 AM, Kevin Smith  wrote:
> Minute correction - I'd misunderstood a conversation with Nathan that
> he'd intended to be apologies for missing Council.
>
> /K
>
> On Thu, Dec 9, 2010 at 11:08 AM, Kevin Smith  wrote:
>> FYI
>>
>> -- Forwarded message --
>> From: Kevin Smith
>> Date: Thu, Dec 9, 2010 at 11:07 AM
>> Subject: Minutes 2010-12-08
>> To: XMPP Council
>>
>> Logs: http://logs.xmpp.org/council/101208/
>>
>> 1) Roll call
>> Kev and both Matts present, Nathan sends apologies, Ralph absent.
>>
>> 2) Agenda bashing.
>> Kev added an item to the end.
>>
>> 3) http://www.xmpp.org/extensions/inbox/remote-auth.html
>> Accept as XEP?
>>
>> No objections to publication, although MM and KS  aren't convinced of
>> its utility. Nathan and Ralph to say whether they object or not within
>> a fortnight.
>>
>> 4) Interop report (Kev)
>> "M-Link, Ejabberd, Prosody, Tigase and Psyched are participating on
>> the server side, things are underway, we're doing basic today, TLS
>> tomorrow, and TLS with cert checking Friday. I've put up some basic
>> test plan, am vaguely overseeing (I'm avoiding being the Isode contact
>> so I can keep my XSF hat on), and I'll write up an informal report at
>> the end of the week."
>>
>> 5) bis report (Peter)
>> "the bis docs are getting closer every day"
>>
>> 6) e2e report (Peter)
>> "I've talked with the OTR guys about potentially documenting their
>> stuff in an RFC (probably informational), we'll see where that leads"
>>
>> 7) Minutes of Council attendance.
>> General agreement that it's useful for the membership to know if
>> Council members are on time (and therefore present for the votes), or
>> turned up as the meeting finished. Kev to start minuting attendance
>> based on present/late/absent.
>>
>> 8) Date of next meeting
>> Wed. 15th December, 1600UTC.
>>
>> 9) Any other business.
>> None.
>>
>

Re: [Standards] XEP-0080 interoperability

[Nathan Fritz]

On Mon, Apr 12, 2010 at 1:52 PM, Stephen Pendleton
 wrote:
> PEP is great - it works, easy to implement and widely supported on the
> server side.
>
> Without a way to search meta information for pubsub nodes, or to have a
> well-known name for common services though, pubsub itself is less useful
> than it could be.
>
> For example, in the microblogging XEP it suggests using PEP, but says: "A
> person's microblog SHOULD be located at a personal eventing (PEP) node whose
> name is "urn:xmpp:microblog:0" but MAY be located at a generic
> publish-subscribe node that is not attached to a user's IM account. For
> instance, if the Shakespearean character Romeo has a JabberID of
>  then his microblog would be located at that JID with a
> node of "urn:xmpp:microblog:0". Outside of native XMPP systems, this node
> can be referred to as the following XMPP URI (see RFC 5122 [5]).
> xmpp:ro...@montague.lit?;node=urn%3Axmpp%3Atmp%3Amicroblog".
>
> It goes on to say you can use service discovery to discover this node, but I
> am not sure that can really be accomplished. I wouldn't know what to look
> for in the service discovery output in a machine readable manner.
>
> Also, I am not sure how this works for pubsub - what does "located at that
> JID" mean in the above text? The server that they jid belongs to? It is my
> understanding that pubsub nodes are globally named so ro...@montague.lit and
> jul...@montague.lit cannot both publish to pubsub node
> "urn:xmpp:microblog:0"
>
> If pubsub nodes ARE NOT globally named in scope, and since microblogging has
> "urn:xmpp:microblog:0" why don't we have geoloc use "urn:xmpp:geoloc:0"?
>
> How would I subscribe to a node like this? This doesn't seem legal, because
> the to jid should be the pubsub service, not the JID:
>
>     from='franci...@denmark.lit/barracks'
>    to='jul...@denmark.lit'
>    id='sub1'>
>  
>            node='urn:xmpp:geoloc:0'
>        jid='franci...@denmark.lit'/>
>  
> 
>

I think the disconnect you're having is that Pubsub isn't for IM
clients. PEP is, or at most pubsub-service-on-a-barejid is.  XMPP
isn't confined to IM use cases.  As an XMPP consultant, most of my
work is Pubsub for non-IM situations.  Pubsub isn't useful for
extending presence in an IM client outside of the concept of PEP and
other barejid implementations. It's a service for eventing,
broadcasting, synchronizing, storage, etc for services.  So when you
talk about discoverability, that's generally a service implementation
piece -- maybe they use a naming scheme, or maybe their clients are
just told because they're not using vanilla IM clients.  Microblogging
MAY be in a separate pubsub domain, but it won't be discoverable that
way to generic IM clients, and that's probably fine for a lot of
services.

I'm currently working a XEP for job-distribution (and various
supporting XEPs). I have these things being used at various companies.
Discoverability on jobs is purely an implementation detail.

-Fritzy

Re: [Standards] XEP-0080 interoperability

[Nathan Fritz]

On Thu, Apr 8, 2010 at 7:35 PM, Stephen Pendleton
 wrote:
>
>
> -Original Message-
> From: standards-boun...@xmpp.org [mailto:standards-boun...@xmpp.org] On
> Behalf Of Tuomas Koski
> Sent: Thursday, April 08, 2010 3:15 PM
> To: XMPP Standards
> Subject: Re: [Standards] XEP-0080 interoperability
>
> Hi Stephen,
>
> On 8 April 2010 17:45, Stephen Pendleton  wrote:
>
>>Like recommended in http://xmpp.org/extensions/xep-0080.html#transport
>>you can use any Publish-Subscribe service. Basically you can publish
>>the data on any node you want. It's up to the implementation.
>
> Yes, but how is that interoperable? I want my implementation to be
> interoperable with every other implementation out there.
>
>
>>Reply:
>>>   from='pam...@wagon.com/mobile'
>>   to='step...@movsoftware.com/resource-a'
>>   id='items'>
>>   
>>      >         node='/geo_loc/pam...@wagon.com'
>>         name='Geolocation of Pamela Baywatch'/>
>>   
>>
>
>
> How do I know programmatically this is the geolocation node? Imagine two
> people each in separate rooms each attempting to create a XMPP application
> that will exchange XEP-0080 geoloc data (without using PEP). How would
> implementation A know which node implementation B publishes their
> geolocation data to?
>
> Maybe I am missing something in the pubsub spec that explains how this is
> discovered.

This is why PEP was invented.  It is intended to be pubsub for each
user.  Discoverable, easy.

-Fritzy

[Standards] Minutes of the 3rd Meeting of the 9th Council (2009-10-26)

[Nathan Fritz]

Third meeting of the 9th XSF Council, Kevin Smith presiding.
Meeting logs can be found at
http://logs.jabber.org/coun...@conference.jabber.org/2009-10-26.html
Meeting minutes can also be found at
http://wiki.xmpp.org/web/Council_Meeting_2009-10-26

1) Roll call.

David Cridland, Matthew Wild, Kevin Smith, Ralph Meijer attending.
Remko Tronçon sends apologies.

2) Agenda Bashing.

None.

3) XEP-0226: Message Stanza Profiles, Issue Last Call?

A consensus is reached on issuing a last call on XEP-0226, although
Matthew Wild notes that he finds the XEP pointless.

4) Reviewing of Peter Saint-Andre's Notes.

4a) Has the roadmap been updated?

Kevin Smith agrees to update the roadmap.

4b) Would we like to set a schedule for those items?

David Cridland suggests that the new Tech Review Team reviews XEP-0227.
Peter Saint Andre has created a new list for the Tech Review Team at
http://mail.jabber.org/mailman/listinfo/techreview

4c) "We've had some discussion on the BOSH list about registering port
5280 with IANA and also defining a default path for BOSH services. I
think it would be good for the Council to discuss these matters so
that we can move forward if desired."

A general consensus is reached to register the port, but a consensus
is not reached on default paths.

4d) "The page at http://xmpp.org/protocols/ it is very likely out of
date and missing some information. Perhaps this is a task that one of
the XSF teams can complete. Let's discuss what we think is
appropriate."

It is suggested that the Tech Review Team reviews this page.

4e) "Some of the XEPs need new maintainers because I can't keep up
with them all anymore (e.g. I have asked Brian Cully to take on
maintainership of the PubSub Collections spec, and regarding XEPs 253
and 254 see ).
Does the Council think that we need a policy on maintainership of
XEPs?"

The council agrees that no policy is needed.

4) Date of next meeting?

2009-11-02 @ 19:00 UTC

5) Any other business?

None.

Kevin Smith bangs the gavel.

Re: [Standards] PDFs!

[Nathan Fritz]

On Wed, Oct 21, 2009 at 10:52 AM, Peter Saint-Andre  wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> Thanks to great work by Tobias Markmann, the XSF now publishes PDF
> versions of its specifications. You can find them here:
>
> http://xmpp.org/extensions/
>
> We're still working out a few glitches here and there, so your feedback
> is appreciated.
>
> Peter
>
> - --
> Peter Saint-Andre
> https://stpeter.im/
>
>
> -BEGIN PGP SIGNATURE-
> Version: GnuPG v1.4.8 (Darwin)
> Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
>
> iEYEARECAAYFAkrfSnkACgkQNL8k5A2w/vy47QCeNzJuVLbJIKpA3vAZb9icoc0D
> fLQAn2kQ7P0ltCPf1lWbcEiDN/9WFxCv
> =fL8p
> -END PGP SIGNATURE-
>

They look great, and smell great too!  I just noticed them yesterday
or the day before.  Are the checkbox filters new too?

-Fritzy

[Standards] Minutes of the 2nd Meeting of the 9th Council (2009-10-19)

[Nathan Fritz]

Second meeting of the 9th XSF Council, Kevin Smith presiding.
Meeting logs can be found at
http://logs.jabber.org/coun...@conference.jabber.org/2009-10-19.html
Meeting minutes can also be found at
http://wiki.xmpp.org/web/Council_Meeting_2009-10-19

1. Roll call.

David Cridland, Kevin Smith, and Matthew Wild present. Quorum achieved.

2. Agenda Bashing.

None.

3. What are this council's priorities for http://xmpp.org/xsf/roadmap.shtml ?

It is decided that items 1 and 2 on the roadmap are now
responsibilities of the IETF Working Group, but it is still the
Council's responsibility to advise. Kevin Smith suggest combining this
to just be item #1.
The Council agrees to include "MUC Cleanup" as item #2.
The roadmap now stands as:

1. Advise the IETF WG on RFC bis revisions and e2e.
2. Clean up MUC (XEP-0045).
3. Improve XMPP file transfer by transitioning to Jingle (see
XEP-0234) with SOCKS5 bytestreams (XEP-0260) and in-band bytestreams
(XEP-0261).
4. Improve the resistance of XMPP to spam, phishing, abuse, and denial
of service attacks, with a current focus on XEP-0268: Incident
Reporting.

4. ProtoXEP Linked Process Protocol - http://xmpp.org/extensions/inbox/lop.html.
Accept as a XEP?

A consensus is reached to wait for the next revision of the spec,
which is apparently in the works, before voting.

5. The following XEPs are soon to expire:
* XEP-0252: BOSH Script Syntax
* XEP-0226: Message Stanza Profiles
* XEP-0253: PubSub Chaining
* XEP-0254: PubSub Queueing

XEP-0253 and 0254 are both in active interest on the jdev list. Kevin
Smith suggests the Council votes next week on issuing a Last Call for
XEP-0226.

6. Date/Time of next meeting.

Monday the 26th of October 2009 at 19:00UTC.

7. Issue a Last Call on http://xmpp.org/extensions/xep-0227.html?

There is some concern about requiring separate files and the lack of
last activity.
All three councilmen vote in favor of issuing a last call.

7. Any other business.
None.

Kevin Smith bangs the gavel.

[Standards] Minutes of the 1st Meeting of the 9th Council (2009-10-14)

[Nathan Fritz]

First meeting of the 9th XSF Council, Kevin Smith presiding.
Meeting logs can be found at
http://logs.jabber.org/coun...@conference.jabber.org/2009-10-14.html
Meeting minutes can also be found at
http://wiki.xmpp.org/web/Council_Meeting_2009-10-14

1. Roll call.

All council is present. (David Cridland, Ralph Meijer, Kevin Smith,
Remko Tronçon, Matthew Wild)

Quorum achieved.

2. Elect a new chair.

Kevin offers to chair the next council and requests everyone
specifically say whether they want to run for the position. Everyone
declines individually.
Kevin Smith and David Cridland abstain from voting.
The other 3 vote for Kevin Smith.
Kevin Smith is the chairman of the 9th Council by majority vote.

3. Agenda bashing.

None.

4. Meeting frequency.

A general consensus is reached for continuing the tradition of weekly meetings.
Ralph Meijer suggests a half hour question and answer session "now and then."

5. Meeting times.

After much discussion of availability, Mondays at 19:00-19:30 British
Time (UTC+1 currently, soon to be UTC) is settled upon.

6. Agenda formats.

A general consensus is reached on agendas that can be viewed in a web
browser, with list email agendas the format for now.
The possibility of publishing agendas via XMPP Pubsub is suggested.

7. Having protoXEP authors present for votes.

Alexey Melnikov suggests from the floor that this is a good idea.
It is generally agreed upon that this is a good idea by council members.

8. Having XEP authors request last calls (AOB, poking the chair etc).

The council generally decides that the council's role is to issue Last
Calls and that "interested parties" should attend a council meeting or
"poke" a chairman to get a Last Call issued.

9. Radar and responsibilities.

The chairman is responsible for forming the agenda, and the councilmen
are responsible for making sure things that they think belong on the
agenda are brought to the chairman's attention.

10. http://xmpp.org/xsf/roadmap.shtml

Deferred due to lack of time, although David Cridland suggests that
the first two items on the decidedly out-of-date roadmap are the
responsibility of the new IETF working group.

11. http://xmpp.org/xsf/people/

Please get your bio updated/added.

12. Date/time of next meeting.

Monday 19:00 British Time.

13. Any other business.

A general consensus is reached that at the beginning of each meeting,
a volunteer should be found to write the meeting minutes. I, Nathan
Fritz, volunteer.

Kevin Smith bangs the gavel.

Re: [Standards] [Interop] XSF Server Test Suite

[Nathan Fritz]

On Tue, Sep 29, 2009 at 12:06 PM, Craig Kaes  wrote:
>
> Ignorant question — can something like Expect deal with multiple responses 
> from a single input where the order of those responses does not matter?  That 
> drove us away from this approach in the past but maybe things have gotten 
> better?
>

There's no reason you couldn't expect multiple possible XPath matches
at the same time.  We're not talking about the Expect language, we're
talking an Expect style.

-Fritz

Re: [Standards] XSF Server Test Suite

[Nathan Fritz]

>
> For the past 6 months, we've been discussing on creating a standardized
> test suite as a tool for XMPP Server developers, and perhaps in the future
> for further purposes.  There was discussion of having a hosted solution that
> can execute scripts from a list of
>
> ---
>
> What about using python and xmppy for the test scripts? Python is very easy
> to pick up for C programmers (and others)?
>
>
> Python is my go-to language as well, however, the point is to generate
simple expect style scripts -- the tests need to avoid doing anything more
complex than building xml, expecting, asserting, and sending.  These points
and counterpoints have been raised and hashed through already (though if you
guys want to have it again, that's fine).  Arguably, foreach and if
statements are overkill as those use cases could be tested by applying a
dtd.  A simple interpreter is all that is needed to run the suite of tests
that anyone can contribute to.

In fact, scratch my foreach/if statements.  Building stanzas, sending,
expecting with XPath, getting with XPath, and asserting with DTDs and XPath
are all that is necessary.

-Fritz

[Standards] XSF Server Test Suite

[Nathan Fritz]

I'm double posting this to standards and interop, but generally this is a
conversation for interop that I thought you should all be aware of.  Peter,
I notice the interop group is not on the discussions page.

For the past 6 months, we've been discussing on creating a standardized test
suite as a tool for XMPP Server developers, and perhaps in the future for
further purposes.  There was discussion of having a hosted solution that can
execute scripts from a list of supported language, but this plan was
scrapped at the last summit.  What we came up with instead is a simple
XPath-Expect script of our own design that we can easily build an
interpreter for.

There will be some basic commands: expect, get, send, assert, foreach_sub,
if_xpath, include, etc as well as built-in helper functions to jump the
script to the right state in the connection without having to be explicit.
There also needs to be some functions for building out stanzas and payload
element trees.  Any xml argument could be a stanza object or string.

stream = connect('u...@xmpp.org/resource', 'password');
start_session(stream); # this command gets us through all of the stream
features, authenticated, and bound. This of course, could be done with the
send/expect commands as well. There may be other such commands that get us
to the state we need.

id = unique_id();
result = send(stream, ("", id), ("[xpath statement with %s for id]",
id));
#OR
iq_roster = makeIq('get', 'xmpp.org');
query = makeElement('{jabber:iq:roster}query');
append_xml(iq_roster, query);
id = get(iq_roster, '@id');
assert(result, ([xpath], [replacement values],));

foreach_sub(result, sub, ([xpath],)) {
assert("Testing item structure", sub, ([xpath]));
group = get(sub, ([xpath],));
# do something with groups here
}

This is the direction things are heading.  The syntax is just something that
we came up with at the last summit but I've exptended it. Perhaps is over
complicated for the task.  Perhaps these test scripts should be written in
XML in order to avoid specialized parsers.  Are there any decent
C-syntax-style parsers out there already?  In any case, I'd like to hear how
people think this should be done.

Thanks,
Nathan Fritz

Re: [Standards] XMPP-0060 meta data enhancement

[Nathan Fritz]

On Sep 29, 2009, at 5:53 AM, Dave Cridland  wrote:


On Tue Sep 29 12:31:39 2009, Mads Randstoft wrote:
After some talks at the jabber dev MUC, it seems there is a need to  
be

able to add more data to a node and more data to an item than is
currently possible in a std. way.


I see priority as a valid addition to pubsub queuing. As far as  
metadata is concerned, this seems to be contextual to the service  
provider, and there is no way for a 3rd party pubsub service to  
interpret your metadata, and so it is an implementation detail. Are  
there values you need outside of the spec? Then add your own namespace  
for your values to the publish call inside the pubsub element.  If you  
think these values would be helpful to others, get them added to an  
appropriate xep or see if there is interest in a new xep


-Nathan Fritz (cellphone)


Right, specifically, we've seen developer interest in both priority  
(as some nebulous thing) and in timestamps.


I think we could reasonably have a concept of some metadata  
container element which has some stuff in - which the pubsub service  
and subscribers may or may not do things with. The metadata  
container element can be independent of the payload.


I don't know where this might fit, but I'd assume a pubsub service  
would have to support metadata, and a subscriber would have to  
request it as a subscription option.


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

Re: [Standards] Presence and components

[Nathan Fritz]

On Sep 29, 2009, at 7:06 AM, Paul Witty  wrote:


Pedro Melo wrote:

Hi,

On 2009/09/29, at 11:20, Paul Witty wrote:
As a bit of background on what I'm trying to do, I'm implementing  
a SIP to XMPP/Jingle gateway.  The gateway is connected to the  
XMPP server as a component (e.g. sipgw.xmppserver.com) and so the  
Jingle client can make a call to 1.2@sipgw.xmppserver.com,  
which then routes this to sip://1.2.3.4.  However, in the other  
direction, a SIP call to sip://p...@sipgw can be routed by the SIP  
gateway to the JID p...@xmppserver.com, but without presence  
information this is insufficient to make a Jingle call.


The two solutions to this I can see is either for the SIP gateway  
to have privileges which allow it access to presence information  
for clients registered to its server through sending a presence  
probe for any user (but which I assume is not supported), or to  
have the gateway send a presence subscription request each time a  
call comes to a previously uncalled user, and maintaining the  
roster, which is clunky both on the gateway side and for the user  
experience.


Clients that want to use the SIP gateway must register with it  
using XEP-0100. In the process, the service subscribes the user  
presence.


I think you really need the registration part, so that the SIP  
gateway knows how to map p...@sipgw to p...@xmppserver.


At the moment we just map sip://usern...@sipgw to xmpp:// 
usern...@xmppserver.com, which, for within a closed company system  
(such as those to which we sell SIP equipment), works perfectly well  
to provide SIP -> Jingle calling with zero configuration.  Requiring  
registration means that it doesn't "just work", and also means that  
the client needs to have the ability to register to the gateway, so  
that we can't just support any Jingle-capable client.


What about using the xmpp jid resource for the sip name instead of the  
user portion? xmpp:s...@xmppserver.com/1.2.3.4. This means that you  
only have to add one thing to your roster and the component can send  
presence from whatever resourse it wants. Using a username portion  
prevents clients from assuming incorrect, special behavior.



-Nathan Fritz (cellphone)

Re: [Standards] Presence and components

[Nathan Fritz]

On Sep 28, 2009, at 5:33 PM, Peter Saint-Andre   
wrote:



-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 9/25/09 8:57 AM, Nathan Fritz wrote:

On Sep 25, 2009, at 4:33 AM, Paul Witty  wrote:


Is there documented anywhere the rules of how presence information
works with components?  e.g. can components subscribe to clients'
presence information, or send presence probes etc.  Likewise, can a
component publish presence, and clients subscribe to its presence,  
but

including things like publishing presence for
component.xmppserver.com, and clients getting that presence for
addr...@component.xmppserver.com?



A component is just like a server jid.  Presence can be routed to and
from, subscriptions can be made.  Probes will likely need to be  
sent and

are likely to be recieved. There is no session management, so you'll
have to implement roster storage yourself or fake it.

And yes, you can send and recieve from any user and resource for your
component's domain.

If you look at a transport component, they do all of these things.


Right.

Granted, this kind of thing is not typically used by MUC services
(handled at the room level via directed presence) or whatever, but
nothing in the specs forbids it and IMHO it's Smart to use presence
everywhere it will solve an interesting problem. :)


Wait, why are you bringing up MUC?




-Nathan Fritz (cellphone)

Re: [Standards] Action rules in XEP-0050

[Nathan Fritz]

On Sep 25, 2009, at 3:35 AM, Fabio Forno  wrote:


2009/9/25 Remko Tronçon :

Yep, which are the same actions, confusing users.


No, they're not, which was the point of my rant. "Next" gets you on  
to

more advanced settings, whereas "Finish" just says "Skip the next
screens, the defaults are fine for me".


I'd like to see some using this behavior, since it is really bad for
users (much better a combo inside the form with "finish", "advanced
options")


I think it's a big assumption to say that it is bad behavior and to  
explicitly prevent implementations from doing it. In fact, assuming  
that a human being is using the forms is often an incorrect  
assumption. The specs are meant to facilitate. If anything, an  
implementation guideline note is all that is necessary.


-Nathan Fritz (cellphone)


--
Fabio Forno,
Bluendo srl http://www.bluendo.com
jabber id: f...@jabber.bluendo.com

Re: [Standards] Presence and components

[Nathan Fritz]

On Sep 25, 2009, at 4:33 AM, Paul Witty  wrote:

Is there documented anywhere the rules of how presence information  
works with components?  e.g. can components subscribe to clients'  
presence information, or send presence probes etc.  Likewise, can a  
component publish presence, and clients subscribe to its presence,  
but including things like publishing presence for component.xmppserver.com 
, and clients getting that presence for addr...@component.xmppserver.com 
?




A component is just like a server jid.  Presence can be routed to and  
from, subscriptions can be made.  Probes will likely need to be sent  
and are likely to be recieved. There is no session management, so  
you'll have to implement roster storage yourself or fake it.


And yes, you can send and recieve from any user and resource for your  
component's domain.


If you look at a transport component, they do all of these things.

-Nathan Fritz (cellphone)

--

Paul Witty

Re: [Standards] help pubsub filter

[Nathan Fritz]

On Thu, Sep 24, 2009 at 8:37 PM, Jason Eacott wrote:

> hi All,
>   I found this post
> http://mail.jabber.org/pipermail/standards/2008-May/018810.html
> and I need exactly this functionality. I'm wondering if anything like this
> actually progressed, I haven't really found anything that seems quite right
> in the XEPs
> did I miss something?
>
> Ideally I'd like to be able to do something like this:
> create a pubsub node.
> use something like stock market ticker stream as publisher input to the
> node.
> have each subscriber able to filter the notifications (at the/a server) by
> arbitrary payload content - ie stockname="abc" and price >x
>
> This is not my actual usecase, but its a perfect fit for what I need.
>
> Thanks
> Jason.
>

I'm not aware of any server that supports it, as the spec is specifically
vague on this issue. (http://xmpp.org/extensions/xep-0060.html#impl-content,
section 12.19).  There's probably a good case for an XPath filter
subscription option as an additional XEP.

As far as running code, you could check out Wokkel and use a node-as-code
approach -- program your own behaviors for the node classes.  SleekXMPP will
have similar features soon as well.

If you'd rather existing Pubsub implementations to use it, then starting on
a XEP and contracting one of them to implement it is always an option.

I'm available to contract for such a feature as well, but I'm perfectly
happy to advise for free.

Best of luck,
Nathan Fritz

Re: [Standards] XEP-0004 Data Forms, and Multiple Submits

[Nathan Fritz]

On Mon, Jul 27, 2009 at 10:54 PM, David Maxwell  wrote:

>
> Hi Folks,
>
> I'm new to looking at XMPP at the protocol level. I have some custom
> workflow in mind, so I was looking at XEP-0004 [Data Forms].
>
> While it's not absolutely critical, it would be nice if there was a
> way to implement a form with multiple Submit actions, and a way for
> the form processor to distinguish them. This is very similar to a
> common problem encountered in designing HTML forms - except in
> XMPP, the Submit isn't a form element, it seems to be implicit.
>
> The workflow I'm thinking of is queue processing, where you get a
> queue item - fill out the form, and then want to do either Cancel,
> Submit, or 'Submit+Next'.
>
> While the '+Next' could be implemented as a checkbox, that still makes
> it two clicks instead of one, and is a bit artificial.
>


You should check out XEP-0050 Ad-Hoc Commands.  It sounds like this spec
will cover your use case better.  It builds on XEP-0004 to provide a user
workflow for forms with actions for submit, next, cancel, prev, finish.
While not as flexible as say HTML Forms, it should cover your use case fine
and if not, just have a list field for selecting a custom action type.

Ad-Hoc Commands is in widespread use for server, component, and bot
administration as well as other uses.


>
> Someone want to tell me I've misunderstood the specs? :-)


You understood fine but didn't realize that it's very common for XEPs to
build on eachother, and XEP-0004 is used in many other extensions.

Best of luck.

>
>
> --
> David Maxwell, da...@vex.net|da...@maxwell.net --> Mastery of UNIX, like
> mastery of language, offers real freedom. The price of freedom is always
> dear,
> but there's no substitute. Personally, I'd rather pay for my freedom than
> live
> in a bitmapped, pop-up-happy dungeon like NT. - Thomas Scoville
>

-Fritzy

Re: [Standards] What's the preferred NS format?

[Nathan Fritz]

On Mon, Oct 27, 2008 at 5:24 PM, Jeff Muller <[EMAIL PROTECTED]> wrote:

> when creating a namespace, is the preferred format "urn:xxx:yyy..." or is
> it "http://mycompany.com/whatever";? Just wondering what would be best to
> use for my own intermal, experimental namespaces.
>
> Jeff
>
> Well, I believe that you have to be a namespace registrar in order to use
urn: namespaces.  Generally people use http://their-domain/whatever because
a) it's nearly guaranteed to be unique and b) it denotes ownership for the
namespace.  The XSF is a namespace registrar now, but they weren't
originally.  Also, the early spec writers didn't understand namespace
authority until jabber:client, jabber:server, and jabber:iq had been
established.  This has all been grandfathered into the final spec, but if
there were an XMPP 2.0, I would expect that to be cleaned up.

[Standards] Collection Oversights in XEP-0060

[Nathan Fritz]

Examples 216 and 219, the notification of disassociation/association are
neither a followup of the example that they show, nor does the collection
have a node reference.  The attribute "id" is mentioned as being in the
associate/disassociate element, when in fact "node" is used.

In short, the example doesn't match the text (nor does it flow with the
previous examples), and the receiving entity has no idea which collection
node is being updated just based on this notification.

Section 9.2 has a similar inconsistency between the "id" attribute being
mentioned in the text and the "node" attribute being used in the example,
however the lack "node" attribute in the collection attribute is
understandable for the root collection.

Section 9.7 is not clear whether this item subscription is recursive.  Will
it update me of collections within collections within collections?

Thanks,
Nathan Fritz

Re: [Standards] Proposed XMPP Extension: The /me Command

[Nathan Fritz]

On Tue, Jun 10, 2008 at 2:34 PM, Peter Saint-Andre <[EMAIL PROTECTED]>
wrote:

> On 06/10/2008 3:31 PM, Nathan Fritz wrote:
> > IIRC, the reason /me was never made into a XEP is because of similar
> > arguments.  It doesn't matter.  We don't need to normalize chat behavior.
> > If they see /me they'll know what it means, and if they see it rendered
> as
> > an action, great.  The XEP is just a recommendation on how you could
> > interpret the message body.  It's not worth normalizing into some sort of
> > namespace for actions.  We can always do that later if there's a demand
> for
> > it.
>
> Is that a vote in favor of documenting this in a historical XEP, or a
> vote against that documentation?
>

+1 Historical XEP

Re: [Standards] Proposed XMPP Extension: The /me Command

[Nathan Fritz]

IIRC, the reason /me was never made into a XEP is because of similar
arguments.  It doesn't matter.  We don't need to normalize chat behavior.
If they see /me they'll know what it means, and if they see it rendered as
an action, great.  The XEP is just a recommendation on how you could
interpret the message body.  It's not worth normalizing into some sort of
namespace for actions.  We can always do that later if there's a demand for
it.

Re: [Standards] XEP-0060 + "Atom over XMPP" as base for Open Twitter?

[Nathan Fritz]

Keep in mind that twitter is more than just a micro blog.  You can blog and
have it automatically directed to a person regardless of subscription, and
there is conversation tracking, etc.

On Mon, May 5, 2008 at 1:07 PM, Peter Saint-Andre <[EMAIL PROTECTED]>
wrote:

> On 05/05/2008 8:34 AM, Bob Wyman wrote:
> > In case you haven't seen it, consider reading Michael Arrington's
> TechCrunch
> > post calling for a decentralized Twitter.
> > (
> http://www.techcrunch.com/2008/05/05/twitter-can-be-liberated-heres-how/)
> > As noted by many of the commenters, and as should be obvious to anyone
> in
> > the Jabber community, the solution they are looking for is probably XMPP
> +
> > XEP-0060 + "Atom over XMPP".
>
> +1. Just had a chat with Joe Hildebrand about that. I'll start working
> on a spec about it tonight. Should be pretty straightforward.
>
> P
>
> --
> Peter Saint-Andre
> https://stpeter.im/
>
>

Re: [Standards] stream restarts

[Nathan Fritz]

I think the stream restart is necessary for TLS, however, I never understood
why we don't formally close the stream.  I think that the stream should be
ended, and wait for an end-of-stream response from the server rather than a
"proceed."  Really, with encryption, we're all going to want to start a new
"document" anyway.  However, with SASL, I could see getting rid of it
entirely.

The other "messy" point I see is all of the special cases a server needs to
account for in roster and subscribe packets.  Subscription requests would be
better served as IQ queries, with the server providing a roster entry that
can then be edited.  I haven't given this a lot of thought, however.