Re: [Standards] XEP-0175: Contact Addresses
Carlo v. Loesch wrote: > Peter Saint-Andre typeth: > | vCard is not very extensible on this point -- we can include a JabberID > | via our hack of vcard-xml and I suppose that's OK. Perhaps we can even > | include multiple JabberIDs. :) > > What about a list of URIs, so you can put all xmpp:jids, OpenID, > and ahum URIs of other protocols in there next to each other. > Possibly in the order of preference, which otherwise would be missing. The vCard XML format does include a element, but I think that was intended only for http URLs. Or something. IMHO vCard was never very well specified... > Also I ran into a problem parsing this format, as it isn't semantically > equivalent to vCard: > > 303-555-1212 > > I can't access it using an XPath-kind of approach as I could if it > were written like this: > > 303-555-1212 > > Regular vCard syntax is TEL;VOICE;HOME which gives me a clear hierarchy > and at the same time a simple string to access. I miss that simplicity > in XEP-0054. > > I decided not to handle this special case and simply return anything > that has in , which may randomly turn out to be a voice > or fax number out of 5 possibly provided numbers. Not a nice solution. > > It's probably too late to fix this, but I can try to ask anyway. It's too late to fix this. Peter -- Peter Saint-Andre https://stpeter.im/ smime.p7s Description: S/MIME Cryptographic Signature
Re: [Standards] XEP-0175: Contact Addresses
Peter Saint-Andre typeth: | vCard is not very extensible on this point -- we can include a JabberID | via our hack of vcard-xml and I suppose that's OK. Perhaps we can even | include multiple JabberIDs. :) What about a list of URIs, so you can put all xmpp:jids, OpenID, and ahum URIs of other protocols in there next to each other. Possibly in the order of preference, which otherwise would be missing. Also I ran into a problem parsing this format, as it isn't semantically equivalent to vCard: 303-555-1212 I can't access it using an XPath-kind of approach as I could if it were written like this: 303-555-1212 Regular vCard syntax is TEL;VOICE;HOME which gives me a clear hierarchy and at the same time a simple string to access. I miss that simplicity in XEP-0054. I decided not to handle this special case and simply return anything that has in , which may randomly turn out to be a voice or fax number out of 5 possibly provided numbers. Not a nice solution. It's probably too late to fix this, but I can try to ask anyway.
Re: [Standards] XEP-0175: Contact Addresses
Pedro Melo wrote: > Hi, > > On Mar 18, 2008, at 4:37 AM, Peter Saint-Andre wrote: >> Pedro Melo wrote: >>> Hi, >>> >>> during the latest DevCon, one of the issues about deployment was contact >>> addresses. The current XEP for that is 0157. >>> >>> I think that 157 breaks the current disco#info usage pattern. We use >>> disco#info to discover which protocols an entity supports, not the get >>> the information directly (exception for basic ). So >>> receiving the entire contact information in the disco#info reply seems >>> wrong, because on most requests, we don't need it. >>> >>> I think we should use a pubsub node instead. This would give us all the >>> benefits of pubsub, and we could probably implement this faster, given >>> that pubsub and pep are starting to get deployed in latest releases of >>> some servers like Openfire and Ejabberd. >>> >>> The schema for the information could be reused from XEP-0157 or >>> XEP-0154 if that one comes back from the dead. >> >> Why not just put this in one of the following? >> >> 1. server vCard (XEP-0054) >> >> 2. server profile (XEP-0154) > > I'm ok with either, and I think any of them is better than xep-0157. > > Profiles seem to be in limbo right now, and vCards are widely deployed, > so I think that server vCard is the best one right now. vCard is not very extensible on this point -- we can include a JabberID via our hack of vcard-xml and I suppose that's OK. Perhaps we can even include multiple JabberIDs. :) Profiles are in limbo only because they've received less attention than technologies on which they depend (e.g., PEP). But now that work is done on the preliminaries, perhaps we can revisit profiles. Peter -- Peter Saint-Andre https://stpeter.im/ smime.p7s Description: S/MIME Cryptographic Signature
Re: [Standards] XEP-0175: Contact Addresses
Hi, On Mar 18, 2008, at 4:37 AM, Peter Saint-Andre wrote: Pedro Melo wrote: Hi, during the latest DevCon, one of the issues about deployment was contact addresses. The current XEP for that is 0157. I think that 157 breaks the current disco#info usage pattern. We use disco#info to discover which protocols an entity supports, not the get the information directly (exception for basic ). So receiving the entire contact information in the disco#info reply seems wrong, because on most requests, we don't need it. I think we should use a pubsub node instead. This would give us all the benefits of pubsub, and we could probably implement this faster, given that pubsub and pep are starting to get deployed in latest releases of some servers like Openfire and Ejabberd. The schema for the information could be reused from XEP-0157 or XEP-0154 if that one comes back from the dead. Why not just put this in one of the following? 1. server vCard (XEP-0054) 2. server profile (XEP-0154) I'm ok with either, and I think any of them is better than xep-0157. Profiles seem to be in limbo right now, and vCards are widely deployed, so I think that server vCard is the best one right now. Best regards, -- Pedro Melo Blog: http://www.simplicidade.org/notes/ XMPP ID: [EMAIL PROTECTED] Use XMPP!
Re: [Standards] XEP-0175: Contact Addresses
Sorry for the slow reply... Pedro Melo wrote: > Hi, > > during the latest DevCon, one of the issues about deployment was contact > addresses. The current XEP for that is 0157. > > I think that 157 breaks the current disco#info usage pattern. We use > disco#info to discover which protocols an entity supports, not the get > the information directly (exception for basic ). So > receiving the entire contact information in the disco#info reply seems > wrong, because on most requests, we don't need it. > > I think we should use a pubsub node instead. This would give us all the > benefits of pubsub, and we could probably implement this faster, given > that pubsub and pep are starting to get deployed in latest releases of > some servers like Openfire and Ejabberd. > > The schema for the information could be reused from XEP-0157 or > XEP-0154 if that one comes back from the dead. Why not just put this in one of the following? 1. server vCard (XEP-0054) 2. server profile (XEP-0154) Peter -- Peter Saint-Andre https://stpeter.im/ smime.p7s Description: S/MIME Cryptographic Signature
Re: [Standards] XEP-0175: Contact Addresses
On Feb 27, 2008, at 10:06 PM, Tomasz Sterna wrote: Dnia 2008-02-26, Wt o godzinie 16:05 +0100, Maciek Niedzielski pisze: If I remember well, disco + data forms were choosen to make this very easy to implement (using basic XEPs), because this information was considered very important. This is _the_ point. Pedro, have you read the Standards-JIG archives on the topic? This could answer many of your concerns. No, I think I missed. I'll search trough the archives and read it. Thanks for the reminder. Best regards, -- Pedro Melo Blog: http://www.simplicidade.org/notes/ XMPP ID: [EMAIL PROTECTED] Use XMPP!
Re: [Standards] XEP-0175: Contact Addresses
Dnia 2008-02-26, Wt o godzinie 16:05 +0100, Maciek Niedzielski pisze: > If I remember well, disco + data forms were choosen to make this very > easy to implement (using basic XEPs), because this information was > considered very important. This is _the_ point. Pedro, have you read the Standards-JIG archives on the topic? This could answer many of your concerns. -- /\_./o__ Tomasz Sterna (/^/(_^^' http://www.xiaoka.com/ ._.(_.)_ im:[EMAIL PROTECTED]
Re: [Standards] XEP-0175: Contact Addresses
Hi, On Feb 27, 2008, at 3:47 PM, Maciek Niedzielski wrote: Pedro Melo pisze: On Feb 26, 2008, at 3:05 PM, Maciek Niedzielski wrote: Pedro Melo pisze: during the latest DevCon, one of the issues about deployment was contact addresses. The current XEP for that is 0157. I think that 157 breaks the current disco#info usage pattern. Now, if you go with pubsub, we run into "where is that node?" problem again. And for PEP you'd need to subscribe to server's presence.. The node is the namespace presented in 157 for example. So there is no issue with the node name. But now you need to know (from where?) that info about jabber.org is stored in pubsub.jabber.org. Sorry, my mistake. Replace pubsub.shakespeare.lit with shakespeare.lit. As with PEP, we use the domain as the pubsub "server". Best regards, -- Pedro Melo Blog: http://www.simplicidade.org/notes/ XMPP ID: [EMAIL PROTECTED] Use XMPP!
Re: [Standards] XEP-0175: Contact Addresses
Hi, On Feb 26, 2008, at 3:15 PM, Joe Hildebrand wrote: What about section 6.3 of the new version of XEP-115? Then you don't even have to do the disco, except the first time. Yes, that would cut down the number of disco's in everything we do, but I still think putting this information in there is wrong. If we do this for 157, why not slap the jabber:id:time in there? The pattern has been: use disco#info to discover support, then use a IQ GET or something similar to retrieve the information. And I don't see any reason to break the pattern. Best regards, On Feb 26, 2008, at 7:24 AM, Pedro Melo wrote: Hi, during the latest DevCon, one of the issues about deployment was contact addresses. The current XEP for that is 0157. I think that 157 breaks the current disco#info usage pattern. We use disco#info to discover which protocols an entity supports, not the get the information directly (exception for basic >). So receiving the entire contact information in the disco#info reply seems wrong, because on most requests, we don't need it. I think we should use a pubsub node instead. This would give us all the benefits of pubsub, and we could probably implement this faster, given that pubsub and pep are starting to get deployed in latest releases of some servers like Openfire and Ejabberd. The schema for the information could be reused from XEP-0157 or XEP-0154 if that one comes back from the dead. Best regards, -- Pedro Melo Blog: http://www.simplicidade.org/notes/ XMPP ID: [EMAIL PROTECTED] Use XMPP! -- Joe Hildebrand -- Pedro Melo Blog: http://www.simplicidade.org/notes/ XMPP ID: [EMAIL PROTECTED] Use XMPP!
Re: [Standards] XEP-0175: Contact Addresses
Pedro Melo pisze: On Feb 26, 2008, at 3:05 PM, Maciek Niedzielski wrote: Pedro Melo pisze: during the latest DevCon, one of the issues about deployment was contact addresses. The current XEP for that is 0157. I think that 157 breaks the current disco#info usage pattern. Now, if you go with pubsub, we run into "where is that node?" problem again. And for PEP you'd need to subscribe to server's presence.. The node is the namespace presented in 157 for example. So there is no issue with the node name. But now you need to know (from where?) that info about jabber.org is stored in pubsub.jabber.org. -- Maciek xmpp:[EMAIL PROTECTED]
Re: [Standards] XEP-0175: Contact Addresses
On Feb 26, 2008, at 3:05 PM, Maciek Niedzielski wrote: Pedro Melo pisze: during the latest DevCon, one of the issues about deployment was contact addresses. The current XEP for that is 0157. I think that 157 breaks the current disco#info usage pattern. We use disco#info to discover which protocols an entity supports, not the get the information directly (exception for basic >). So receiving the entire contact information in the disco#info reply seems wrong, because on most requests, we don't need it. I think we should use a pubsub node instead. If I remember well, disco + data forms were choosen to make this very easy to implement (using basic XEPs), because this information was considered very important. The information is important but not to everyone, nor on every request of disco. Now, if you go with pubsub, we run into "where is that node?" problem again. And for PEP you'd need to subscribe to server's presence.. The node is the namespace presented in 157 for example. So there is no issue with the node name. And you don't need PEP, just basic pubsub. Best regards, -- Pedro Melo Blog: http://www.simplicidade.org/notes/ XMPP ID: [EMAIL PROTECTED] Use XMPP!
Re: [Standards] XEP-0175: Contact Addresses
What about section 6.3 of the new version of XEP-115? Then you don't even have to do the disco, except the first time. On Feb 26, 2008, at 7:24 AM, Pedro Melo wrote: Hi, during the latest DevCon, one of the issues about deployment was contact addresses. The current XEP for that is 0157. I think that 157 breaks the current disco#info usage pattern. We use disco#info to discover which protocols an entity supports, not the get the information directly (exception for basic ). So receiving the entire contact information in the disco#info reply seems wrong, because on most requests, we don't need it. I think we should use a pubsub node instead. This would give us all the benefits of pubsub, and we could probably implement this faster, given that pubsub and pep are starting to get deployed in latest releases of some servers like Openfire and Ejabberd. The schema for the information could be reused from XEP-0157 or XEP-0154 if that one comes back from the dead. Best regards, -- Pedro Melo Blog: http://www.simplicidade.org/notes/ XMPP ID: [EMAIL PROTECTED] Use XMPP! -- Joe Hildebrand
Re: [Standards] XEP-0175: Contact Addresses
Pedro Melo <[EMAIL PROTECTED]> writes: > I think that 157 breaks the current disco#info usage pattern. We use > disco#info to discover which protocols an entity supports, not the > get the information directly (exception for basic ). So > receiving the entire contact information in the disco#info reply > seems wrong, because on most requests, we don't need it. That could be fixed by using a special node for the contact info request, couldn't it? -- Magnus JID: [EMAIL PROTECTED]
Re: [Standards] XEP-0175: Contact Addresses
Pedro Melo pisze: I think that 157 breaks the current disco#info usage pattern. We use disco#info to discover which protocols an entity supports, not the get the information directly (exception for basic ). So receiving the entire contact information in the disco#info reply seems wrong, because on most requests, we don't need it. Maybe we could use disco with a well-know node? -- Maciek xmpp:[EMAIL PROTECTED]
Re: [Standards] XEP-0175: Contact Addresses
Pedro Melo pisze: during the latest DevCon, one of the issues about deployment was contact addresses. The current XEP for that is 0157. I think that 157 breaks the current disco#info usage pattern. We use disco#info to discover which protocols an entity supports, not the get the information directly (exception for basic ). So receiving the entire contact information in the disco#info reply seems wrong, because on most requests, we don't need it. I think we should use a pubsub node instead. If I remember well, disco + data forms were choosen to make this very easy to implement (using basic XEPs), because this information was considered very important. Now, if you go with pubsub, we run into "where is that node?" problem again. And for PEP you'd need to subscribe to server's presence.. -- Maciek xmpp:[EMAIL PROTECTED]
