[Standards-JIG] JEP-0060: 1.8pre14
jabber.org at ralphm.ik.nu
Fri Apr 14 13:29:23 UTC 2006
On Thu, Apr 13, 2006 at 10:30:39AM -0600, Peter Saint-Andre wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> While flying from Denver to Nashville last night I re-read the entire
> JEP-0060 and completed another edit. Most of the changes are editorial
> nits. The most significant change is that I added a wrapper element to
> the data form used by owners to approve pending subscription requests.
Hmm, I must have missed the discussion on this, but why? This makes it
harder to generically process incoming forms in clients, doesn't it?
Also, if this will be kept, I think there's no reason for having a
FORM_TYPE, or even JEP-0004 for that matter.
Reading further in that section, I suppose it is because of handling
pending subscriptions after getting a list of them. If handling
approvals is implemented stateless, there is no need for a wrapper
The suggestion of a body element in the message would be nice, too.
I want to note here that I find it odd to use JEP-0050 here, while
defining custom protocol for everything else. Note that I'm not
suggesting replacing other protocol with JEP-0050 use.
> Also I incorporated all feedback received on this list before I got on
> the plane (i.e., not Ralph's latest message about subscriber management;
> what I have in 1.8pre14 on that score is a little different and we'll
> need to fix a few things, I think).
> In any case, 1.8pre14 is here:
New batch of comments, not strictly about the changes in this revision:
- In table 5, the transient/notification case, I would make it implicit
that the <items/> wrapper is empty.
- I wouldn't speak of 'Subscriptions not supported'. Rather, the
protocol for having entities subscribe/unsubscribe is not implemented.
This might be true for systems that do use the publishing/notification
parts, but have fixed subscriptions, or manage them out-of-band.
- Some of the authorization checking is fairly rigid. For example, in
the current wording, you couldn't have special users do an unsubscribe
of another entity. Surely it is good to define common sense defaults,
- I'm not sure about needing to reference PEP throughout the
specification. When other profiles will appear, I assume we won't
either, and also PEP might not even make it.
Maybe the PEP specific stuff, like additional access models, should be
defined in the profile itself. New config fields can be added to the
What might be useful is some automagic generation of a list of all
specifications that depend on the current one (not only for JEP-0060)
upon rendering to HTML.
- There are some cut/paste errors in managing subscribers mentioning
element names that concern /affiliates/.
- %s/late published/last published/
- For notification of unsubscription ('impl-unsub') it might be better
to just use <subscription ... subscription='none'/>. This is more
consistent with what is returned upon a subscription request and also
allows for relaying the fact that a pending request has been approved.
I'm not sure if it belongs in the implementation section, though, as
it is new (or better: another use of) protocol.
- %s/The leasinThe/The/
That's it (for now).
More information about the Standards