Re: [Standards] Generic name attribute for XEP-0147
On Tuesday 10 July 2007 06:18, Peter Saint-Andre wrote: > Daniel Aleksandersen wrote: > > Hi, > > > > There should be a generic name attribute to all actions. > > > > Currently you can only specify a name to the rooster action: > > xmpp:[EMAIL PROTECTED];name=Romeo%20Montague > > Does the 'name' translate into XMPP syntax or it merely presented to a > human user? If the latter, what is the difference between the following? > > addme > > addme In the former case, the client can determine a default name for the contact without implementing a parser for the English language. Daniel pgpeCVASI9BMm.pgp Description: PGP signature
[Standards] Generic name attribute for XEP-0147
On Monday 09. July 2007 22:18:36 Peter Saint-Andre wrote: > Daniel Aleksandersen wrote: > > Hi, > > > > There should be a generic name attribute to all actions. > > > > Currently you can only specify a name to the rooster action: > > xmpp:[EMAIL PROTECTED];name=Romeo%20Montague > > Does the 'name' translate into XMPP syntax or it merely presented to a > human user? If the latter, what is the difference between the following? > > addme > > addme > > Peter The name should be used to humanly represent the person in the client. Either in the message window or in the roster, or whatever is appropriate. It's a better experience for most users to chat to "Carry" than to chat with "[EMAIL PROTECTED]" for instance. -- Daniel Aleksandersen <[EMAIL PROTECTED]>
Re: [Standards] Generic name attribute for XEP-0147
Daniel Aleksandersen wrote: > Hi, > > There should be a generic name attribute to all actions. > > Currently you can only specify a name to the rooster action: > xmpp:[EMAIL PROTECTED];name=Romeo%20Montague Does the 'name' translate into XMPP syntax or it merely presented to a human user? If the latter, what is the difference between the following? addme addme Peter -- Peter Saint-Andre http://stpeter.im/ smime.p7s Description: S/MIME Cryptographic Signature
Re: [Standards] XEP-0004: Data Forms - Open Issues
Tobias Markmann wrote: >1. Seems that list-single and list-multi are implemented in most > clients that the end user isn't allowed to add new items to the > list, just select one or in the list-multi case more. This seems > to be okay for me and might even go without saying but I suggest > to explain it more clearly in the XEP. That's correct -- the submitting entity can only choose from among the items provided in the list. >2. Jid-single and jid-multi field types on the other hand seem to be > editable by the end user but there isn't described how to supply > default values for these field types. A default value is provided in the form by including a element. I'm not sure how helpful a default JID is, but we can specify this more fully. >3. XEP-0004 should describe that for list-single and list-multi > fields labels and values have to be unique. There MUST NOT be an > option with a label or value which already has been used in that > field. If not and you have a list-single you might run into cases > where the default value describes two options selected. This may > sounds stupid but the protocol doesn't say anything about it. Good point. Thanks for the bug reports! Peter -- Peter Saint-Andre http://stpeter.im/ smime.p7s Description: S/MIME Cryptographic Signature
Re: [Standards] private storage revisited
Ian Paterson wrote: > Peter Saint-Andre wrote: >> So we'd have something like this: >> >> >> >> >> >> >> >> >> >> My nurse's birthday! >> >> >> >> >> >> >> http://jabber.org/protocol/pubsub#node_config >> >> >> whitelist >> >> >> >> >> >> >> If the node exists and the precondition is not met (in this case, if the >> access model is something other than "whitelist"), then the publish >> fails with a suitable error condition (probably along with >> some pubsub-specific condition). >> >> If the node exists and the precondition is met, then the publish >> succeeds. >> >> If the node does not exist, then the service auto-creates the node with >> default configuration in all respects except those specified in the >> preconditions (in this case, the node would be created with an access >> model of "whitelist") and the publish succeeds. >> >> Correct? >> > > Correct. +1 > > Thank you Ralph, Peter. > > Wow! consensus on Personal Publishing! I'm off to celebrate :-) :-) So I suppose you can update XEP-0189 now, which will break the logjam for XEP-0136 too. ;-) Wasn't there another feature you needed for XEP-0189? Peter -- Peter Saint-Andre XMPP Standards Foundation http://www.xmpp.org/xsf/people/stpeter.shtml smime.p7s Description: S/MIME Cryptographic Signature
[Standards] Generic name attribute for XEP-0147
Hi, There should be a generic name attribute to all actions. Currently you can only specify a name to the rooster action: xmpp:[EMAIL PROTECTED];name=Romeo%20Montague However there should be possible to add it to other actions as well. Especially message and subscribe. This would be useful for instance when I wanted to contact consumer support from some online store: xmpp:[EMAIL PROTECTED];name=Store.com%20Consumer%20support&body=Hi, %20I%20need%20help%20with%20productnumber# I really cannot see why the specification did not include a name attribute for the subscribe action either. It is so similar to roster, only with added status subscription... PS: Above URIs may brake up into multiple lines, due to email formatting done by my email client. -- Daniel Aleksandersen <[EMAIL PROTECTED]>
Re: [Standards] private storage revisited
Ian Paterson wrote:
> Peter Saint-Andre wrote:
>> We already have one such solution/hack in PEP: the +notify
>> namespaces used in entity capabilities to signal that a subscriber wants
>> to receive notifications related to a given namespace. Your suggestion
>> of +whitelist (etc.) is in the same spirit, but +notify does not force
>> semantic structure on NodeIds, which +{access_model} does (and the
>> objections may arise because NodeIds are supposed to lack semantic
>> structure).
>>
> Yes, there is a significant difference between "+notify" (where the var
> attribute of the element continues to specify only the
> functionality that the client supports), and "+{access_model}" (where
> the 'node' attribute of the element no longer simply
> identifies a node, i.e. it is overloaded to also specify the
> configuration of the server).
>
> That said, we still might want to consider defining a new notify='true'
> attribute for disco#info elements. Disco is "Final", but this
> change would be 100% backwards compatible, and is therefore permitted.
> What do people think?
I don't have a particular problem with the +notify stuff, myself. And it
makes the PEP notification filtering go quite smoothly.
/psa
smime.p7s
Description: S/MIME Cryptographic Signature
[Standards] XEP-0004: Data Forms - Open Issues
Hi, During my coding on the Data Form Designer Suite for XMPP[1] some questions on XEP-0004[2] raised and I tried finding answers. I think the XEP is still pretty vague in some points. So here they are: 1. Seems that list-single and list-multi are implemented in most clients that the end user isn't allowed to add new items to the list, just select one or in the list-multi case more. This seems to be okay for me and might even go without saying but I suggest to explain it more clearly in the XEP. 2. Jid-single and jid-multi field types on the other hand seem to be editable by the end user but there isn't described how to supply default values for these field types. 3. XEP-0004 should describe that for list-single and list-multi fields labels and values have to be unique. There MUST NOT be an option with a label or value which already has been used in that field. If not and you have a list-single you might run into cases where the default value describes two options selected. This may sounds stupid but the protocol doesn't say anything about it. Most of these issues may be easy to solve through some better and more precise description and a better example so all field types are shown in usage. cheers, Tobias Markmann [1] http://ayena.de [2] http://www.xmpp.org/extensions/xep-0004.html
Re: [Standards] private storage revisited
Peter Saint-Andre wrote:
We already have one such solution/hack in PEP: the +notify
namespaces used in entity capabilities to signal that a subscriber wants
to receive notifications related to a given namespace. Your suggestion
of +whitelist (etc.) is in the same spirit, but +notify does not force
semantic structure on NodeIds, which +{access_model} does (and the
objections may arise because NodeIds are supposed to lack semantic
structure).
Yes, there is a significant difference between "+notify" (where the var attribute of the
element continues to specify only the functionality that the client supports), and
"+{access_model}" (where the 'node' attribute of the element no longer simply
identifies a node, i.e. it is overloaded to also specify the configuration of the server).
That said, we still might want to consider defining a new notify='true' attribute for
disco#info elements. Disco is "Final", but this change would be 100%
backwards compatible, and is therefore permitted. What do people think?
- Ian
