[Standards-JIG] JEP-0060: 1.8pre14

Ralph Meijer 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:
> 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 mailing list