[standards-jig] comments on JEP-0060
jabber.org at ralphm.ik.nu
Sat Jan 18 23:32:41 UTC 2003
On Sat, Jan 18, 2003 at 03:42:53PM +0100, Tijl Houtbeckers wrote:
> ... snip ...
> Ralph Meijer proprosed that we should use x:data for in-band only, and
> that we agree on wich var names to use in them. (wether both points are
> mandatory or a recommandation is not entirely clear).
Hmm, I see I was a bit vague here. After reading all the comments more
carefully my opinion has shifted a bit.
For human <-> machine interaction x:data is perfect. Because the forms
are presented to a human anyway, there is no need for stardardizing the
fields / options. So, a pubsub component that interacts with a human, in
band, SHOULD at least implement x:data for configuration. I also see
no problem with this kind of configuration being in the JEP.
However, since the contents of the <configure/> element is namespaced
seperately (in this case with jabber:x:data), I don't see a problem in
letting implementations, especially those to be used in applications that
don't directly involve humans, use another means of configuring nodes. So,
an implementation MAY use the <configure/> element to configure a node, iff
properly namespaced. Such a namespace is probably implementation specific,
or could be documented in a new JEP.
Out of band configuration should be permitted in any case.
Something else that I wanted to note is that all configuration mentioned in
the JEP is for interaction with the node owner only. Maybe it should also be
possible for subscribers to configure their subscription. If I think of
mailinglists, there are options like digest mode. Maybe you also want to
only receive notifications depending on your presence or time of day.
I can think of more things that an implementation might provide, and think
subscription configuration should be in the
http://jabber.org/protocol/pubsub namespace, just like node configuration
(with use of x:data, but also with properly namespaced data for in band
configuration for machine<->machine configuration of subscriptions).
The last point I want to make is that the messages used for letting an owner
approve subscriptions are not marked in any way as such. It is just another
form. It would be good to mark it as such in some way (maybe a mandatory
field?). Also there should be a way for machines to do this authorising in
band. I think without x:data, OR a standardized form, but why use x:data
More information about the Standards