[jdev] When to use extended service discovery vs jabber search

2010-09-21 Thread Michael McCarthy
First post to the list - hi everyone!

We develop the 'community' area of an online gaming site - basically using MUC 
with 20+ rooms ranging from almost empty to sometimes up to 500 odd occupants. 
The 'chat hosts' in these rooms are people with the moderator role. Where 
possible we follow the protocols rather than implement our own.

I need to return a packet to the end user that contains a brief summary of the 
rooms, consisting of basic room information (name, description) plus room 
occupancy and which moderators are currently in the room. I'm stumped for her 
to do this, as no XEP seems to fit the bill:

Basic Service Discovery (0030) - In order to retrieve full information about an 
entity and its associated items, the requesting application needs to "walk the 
tree" of items. Naturally, this can result in a large number of requests and 
responses. The requesting application SHOULD NOT send follow-up requests to all 
items associated with an entity if the list of such items is long (e.g., more 
than twenty items).
Problem - There will likely be more than 20 rooms to query individually.

Extended Service Discovery (0128) - An entity MUST NOT supply extended 
information about associated children communicated via the 
'http://jabber.org/protocol/disco#items' namespace, since a core principle of 
Service Discovery is that an entity must define its own identity only and must 
not define the identity of any children associated with the entity. 
Problem - As the entity being queried here (I imagine) is the MUC service 
itself, am I breaking protocol by asking for a lot of information about it's 
children?

Jabber search doesn't seem quite right as it doesn't feel like a search - I 
always query for the same information so service discovery seems the natural 
fit.

Any help would be greatly appreciated : )

Michael 

___
JDev mailing list
Forum: http://www.jabberforum.org/forumdisplay.php?f=20
Info: http://mail.jabber.org/mailman/listinfo/jdev
Unsubscribe: jdev-unsubscr...@jabber.org
___


[jdev] Fwd: RFP: Requirements Development for Community Draft Tracking Tool

2010-09-21 Thread Dave Cridland

Thought this may be of interest to people.

I'd imagine that such a tool, carefully crafted, would be of use to  
the XSF if licensing allowed.


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
--- Begin Message ---
The IETF Administrative Oversight Committee (IAOC), on behalf of the IETF,
announces this Request for Proposal to develop the requirements for a
community draft tracking tool.  The successful bidder will enter into a
contract with the Internet Society.

The primary goal of this project is to develop consensus on a set of
requirements for extending the Data Tracker to give individual IETF
community members, including IETF leadership, easy methods for tracking
the progress of the Internet Drafts (I-Ds) of interest to them. The tools
that will eventually be provided to individuals in the community include
the ability to create one or more (possibly large) lists of I-Ds that they
want to follow; the ability to get notifications when individual drafts
from a list changes state; the ability to see all of the state changes
that have occurred on all the drafts in a list over a specified range of
dates; the ability to set the granularity of the changes (such as "every
change", "just approvals and publication", and so on); the ability to
organize their views of a list in many fashions that would be useful to
different types of community members; and the ability to share and merge
lists with other community members.

Because there many different types of community members, there needs to
be a significant amount of outreach when creating these requirements. This
outreach includes a separate mailing list for discussion, a face-to-face
BoF at IETF 79 in Beijing, virtual meetings after IETF 79, and directed
communications with specific communities such as the I* groups, WG chairs,
and SDOs with whom the IETF has liaison relationships. The expected
outcome is requirements for multiple methods for an individual to interact
with the system that will eventually be deployed.

The RFP can be found at: http://iaoc.ietf.org/rfpsrfis.html.

Proposals must be received via email at rpellet...@isoc.org no later than
October 11, 2010, 5:00 P.M. EDT. All questions/inquiries must be submitted
in writing and must be received no later than midnight, EDT, September 27,
2010. Responses to questions and inquiries shall be posted on the IAOC
website, iaoc.ietf.org/rfpsrfis.html by midnight, EDT, October 4, 2010.

The point of contact regarding this RFP is the IETF Administrative
Director, Ray Pelletier.

Ray Pelletier
IETF Administrative Director
___
Ietf mailing list
i...@ietf.org
https://www.ietf.org/mailman/listinfo/ietf
--- End Message ---
___
JDev mailing list
Forum: http://www.jabberforum.org/forumdisplay.php?f=20
Info: http://mail.jabber.org/mailman/listinfo/jdev
Unsubscribe: jdev-unsubscr...@jabber.org
___


Re: [jdev] Best ways for a JID to advertise what services it uses?

2010-09-21 Thread Justin Karneges
On Tuesday 21 September 2010 07:15:40 Dave Cridland wrote:
> On Tue Sep 21 14:34:54 2010, Stephen Pendleton wrote:
> > The answer to this is key to interoperability for pubsub. If I can't
> > discover the location your nodes I cannot interoperate with you.
> 
> Right, and the ideal answer is to use PEP - or rather,
> pubsub-onna-jid.
> 
> But in some cases you don't want to (because your PEP service is
> minimal) or can't (because you have no PEP at all).
> 
> It's not yet clear to me that a solution is possible.

And maybe you're not always looking for a pubsub service.  There's all sorts 
of additional metadata and application logic that one might want to associate 
with a user account.  However, it's not practical that every XMPP user account 
server in the world implement every extension.  And having to limit your 
application to only those user accounts with special baked-in extensions 
sucks.

At Livefyre, we've attempted to solve this problem by introducing the idea of 
delegate services.  Instead of adding extensions to the user accounts 
themselves, any arbitrary user account is able associate itself with a 
delegate service which provides the extensions.  The problem with this, of 
course, is the same as that of the pubsub problem: given a user account JID 
alone there is currently no way to know what or where the delegated services 
for that JID are.

Something like this might help:


  http://jabber.org/protocol/delegate"/>



  http://jabber.org/protocol/delegate";>


  


Just tossing it out as a rough idea to start from.

-Justin
___
JDev mailing list
Forum: http://www.jabberforum.org/forumdisplay.php?f=20
Info: http://mail.jabber.org/mailman/listinfo/jdev
Unsubscribe: jdev-unsubscr...@jabber.org
___


Re: [jdev] Best ways for a JID to advertise what services it uses?

2010-09-21 Thread Tuomas Koski
Hi,

On 21 September 2010 17:07, Dave Cridland  wrote:
> On Tue Sep 21 15:56:09 2010, Tuomas Koski wrote:
>>
>> Hi,
>>
>> On 21 September 2010 16:15, Dave Cridland  wrote:
>> > On Tue Sep 21 14:34:54 2010, Stephen Pendleton wrote:
>> >>
>> >> The answer to this is key to interoperability for pubsub. If I can't
>> >> discover the location your nodes I cannot interoperate with you.
>> >
>> > Right, and the ideal answer is to use PEP - or rather, pubsub-onna-jid.
>>
>>  Yes ... but ...
>>
>>
>> On 21 September 2010 16:15, Dave Cridland  wrote:
>> > But in some cases you don't want to (because your PEP service is
>> > minimal) or
>> > can't (because you have no PEP at all).
>>
>> Exactly. The above is my limitation.
>>
>>
>> On 21 September 2010 16:15, Dave Cridland  wrote:
>> > It's not yet clear to me that a solution is possible.
>>
>> Yeah. I will do a demo using the LRDD. It will not be beautiful but I
>> think it'll get us started.
>
> What we need is a case of fallbacks.
>
> So we expect to find a microblog in the pubsub service rooted at the user's
> bare jid.
>
> Failing that, we expect to find a pointer advertised over PEP (Not ideal,
> since this would mean every time I come online, I'll get a copy of your
> advertisment).

Yes, and the publisher of the "microblog notices" does not always want
the microblog subscriber to be "associated with an instant messaging
and presence account".


On 21 September 2010 17:07, Dave Cridland  wrote:
> Failing that, we try webfinger/LRDD.
>
> Failing that, we see if the user's client(s) support some discovery method,
> and use that. (A special disco node?). This is really not ideal, as we need
> to catch the user online.
>
> Failing that, we assume that the user has no microblog unless configured.

Thanks Dave! Great! That's way better than what I was about to offer.
I'll do that. I think I can set up a demo pretty quickly.

To be continued ...


Br,
--
Tuomas
___
JDev mailing list
Forum: http://www.jabberforum.org/forumdisplay.php?f=20
Info: http://mail.jabber.org/mailman/listinfo/jdev
Unsubscribe: jdev-unsubscr...@jabber.org
___


Re: [jdev] Best ways for a JID to advertise what services it uses?

2010-09-21 Thread Dave Cridland

On Tue Sep 21 15:56:09 2010, Tuomas Koski wrote:

Hi,

On 21 September 2010 16:15, Dave Cridland  wrote:
> On Tue Sep 21 14:34:54 2010, Stephen Pendleton wrote:
>>
>> The answer to this is key to interoperability for pubsub. If I  
can't

>> discover the location your nodes I cannot interoperate with you.
>
> Right, and the ideal answer is to use PEP - or rather,  
pubsub-onna-jid.


 Yes ... but ...


On 21 September 2010 16:15, Dave Cridland  wrote:
> But in some cases you don't want to (because your PEP service is  
minimal) or

> can't (because you have no PEP at all).

Exactly. The above is my limitation.


On 21 September 2010 16:15, Dave Cridland  wrote:
> It's not yet clear to me that a solution is possible.

Yeah. I will do a demo using the LRDD. It will not be beautiful but  
I

think it'll get us started.


What we need is a case of fallbacks.

So we expect to find a microblog in the pubsub service rooted at the  
user's bare jid.


Failing that, we expect to find a pointer advertised over PEP (Not  
ideal, since this would mean every time I come online, I'll get a  
copy of your advertisment).


Failing that, we try webfinger/LRDD.

Failing that, we see if the user's client(s) support some discovery  
method, and use that. (A special disco node?). This is really not  
ideal, as we need to catch the user online.


Failing that, we assume that the user has no microblog unless  
configured.


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
___
JDev mailing list
Forum: http://www.jabberforum.org/forumdisplay.php?f=20
Info: http://mail.jabber.org/mailman/listinfo/jdev
Unsubscribe: jdev-unsubscr...@jabber.org
___


Re: [jdev] Best ways for a JID to advertise what services it uses?

2010-09-21 Thread Tuomas Koski
Hi,

On 21 September 2010 16:15, Dave Cridland  wrote:
> On Tue Sep 21 14:34:54 2010, Stephen Pendleton wrote:
>>
>> The answer to this is key to interoperability for pubsub. If I can't
>> discover the location your nodes I cannot interoperate with you.
>
> Right, and the ideal answer is to use PEP - or rather, pubsub-onna-jid.

 Yes ... but ...


On 21 September 2010 16:15, Dave Cridland  wrote:
> But in some cases you don't want to (because your PEP service is minimal) or
> can't (because you have no PEP at all).

Exactly. The above is my limitation.


On 21 September 2010 16:15, Dave Cridland  wrote:
> It's not yet clear to me that a solution is possible.

Yeah. I will do a demo using the LRDD. It will not be beautiful but I
think it'll get us started.


Cheers,
--
Tuomas
___
JDev mailing list
Forum: http://www.jabberforum.org/forumdisplay.php?f=20
Info: http://mail.jabber.org/mailman/listinfo/jdev
Unsubscribe: jdev-unsubscr...@jabber.org
___


Re: [jdev] Best ways for a JID to advertise what services it uses?

2010-09-21 Thread Dave Cridland

On Tue Sep 21 14:34:54 2010, Stephen Pendleton wrote:

The answer to this is key to interoperability for pubsub. If I can't
discover the location your nodes I cannot interoperate with you.


Right, and the ideal answer is to use PEP - or rather,  
pubsub-onna-jid.


But in some cases you don't want to (because your PEP service is  
minimal) or can't (because you have no PEP at all).


It's not yet clear to me that a solution is possible.

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
___
JDev mailing list
Forum: http://www.jabberforum.org/forumdisplay.php?f=20
Info: http://mail.jabber.org/mailman/listinfo/jdev
Unsubscribe: jdev-unsubscr...@jabber.org
___


Re: [jdev] Best ways for a JID to advertise what services it uses?

2010-09-21 Thread Stephen Pendleton


-Original Message-
From: jdev-boun...@jabber.org [mailto:jdev-boun...@jabber.org] On Behalf Of
Tuomas Koski
Sent: Tuesday, September 21, 2010 7:16 AM
To: Jabber/XMPP software development list
Subject: [jdev] Best ways for a JID to advertise what services it uses?
>...
>what are the best ways for a JID to advertise what services it uses ?
>...
>So, what would be the best way to archive the same using XMPP?

I had this discussion a while ago on the same subject here:
http://www.mail-archive.com/standa...@xmpp.org/msg07797.html

The answer to this is key to interoperability for pubsub. If I can't
discover the location your nodes I cannot interoperate with you.



___
JDev mailing list
Forum: http://www.jabberforum.org/forumdisplay.php?f=20
Info: http://mail.jabber.org/mailman/listinfo/jdev
Unsubscribe: jdev-unsubscr...@jabber.org
___


[jdev] Best ways for a JID to advertise what services it uses?

2010-09-21 Thread Tuomas Koski
Hi all,

(I have been thinking about this quite a while now and I think it's
better to ask from the smarter men)

what are the best ways for a JID to advertise what services it uses ?

Let's take an example:

User mis...@gmail.com wants the whole wild XMPP world to be able to
discover that her "microblog" can be found from URI
"xmpp:pubsub.microblog.com.?;node=tech_lady", her global avatar can be
found from "http://en.gravatar.com/12365432151321351.png"; and her
"magic-public-key" is "just_an_example_magic-public-key".

In the HTTP world this could be achieved by using for example
http://code.google.com/p/webfinger/ . In short it works in a way that
if one would like to discover ko...@lobstermonste.org's info, one
would first query http://lobstermonster.org/.well-known/host-meta and
then discover the LRDD of the user, in this case using the url
http://www.lobstermonster.org/lrdd?uri=ko...@lobstermonster.org .

So, what would be the best way to archive the same using XMPP?


Cheers,
--
Tuomas
___
JDev mailing list
Forum: http://www.jabberforum.org/forumdisplay.php?f=20
Info: http://mail.jabber.org/mailman/listinfo/jdev
Unsubscribe: jdev-unsubscr...@jabber.org
___


Re: [jdev] XEP-0115 Caps Verification

2010-09-21 Thread Will Thompson

Also, here's a patch to fix the HTML generated by capscan.

--
Will
# HG changeset patch
# User w...@willthompson.co.uk
# Date 1285060950 -3600
# Node ID db500386b9c4a4ff5b91367da2230f0c520a2f36
# Parent  9a4a18d111661f052a470883ee5e6c46f4d233af
Correctly close  tag in report.html

diff -r 9a4a18d11166 -r db500386b9c4 capscan.lua
--- a/capscan.lua	Sat Sep 18 18:57:41 2010 +0100
+++ b/capscan.lua	Tue Sep 21 10:22:30 2010 +0100
@@ -89,7 +89,8 @@
 
 	]];
 report:write("Entity capabilities validity for contacts of ", jid);
-report:write[[
+report:write[[
+
 
 ]];
 


___
JDev mailing list
Forum: http://www.jabberforum.org/forumdisplay.php?f=20
Info: http://mail.jabber.org/mailman/listinfo/jdev
Unsubscribe: jdev-unsubscr...@jabber.org
___


Re: [jdev] XEP-0115 Caps Verification

2010-09-21 Thread Will Thompson

On 20/09/10 21:02, Matthew Wild wrote:

2 had invalid caps. Of those with invalid caps,
one was a bot (mine, using gloox), the other was an N900 - but it may
be that it returned an error or empty disco result rather than an
invalid hash as such.


Oh dear. :/ Any more details on the N900 failure? I briefly broke the 
hash generation there (when making it identify as a phone, not a pc) but 
re-tested at the time pretty thoroughly. Also, I ran your tool (nice!) 
and all the N900s on my roster check out fine.


(Though I do wonder why the client name isn't showing up.)

Cheers,
--
Will
___
JDev mailing list
Forum: http://www.jabberforum.org/forumdisplay.php?f=20
Info: http://mail.jabber.org/mailman/listinfo/jdev
Unsubscribe: jdev-unsubscr...@jabber.org
___