[Standards-JIG] JEP-0060: 1.8pre14

Peter Saint-Andre stpeter at jabber.org
Fri Apr 14 20:31:26 UTC 2006

Hash: SHA1

Ralph Meijer wrote:
> 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.

We had some discussion about this in relation to another protocol
recently. The point made (by pgmillard IIRC) was that forms are best
wrapped in other namespaces, rather than sent as free-floating forms.
I'll try to dig out the reference.

> 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.

Yes, I found that odd on re-reading it, too. We'd have to ask pgm about it.

> 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,
>   though.

I think the current wording allows that.

> - 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.

Yes, I pulled out some of those references and probably need to do more.

>   Maybe the PEP specific stuff, like additional access models, should be
>   defined in the profile itself. 

In general I think that's a good idea.

> New config fields can be added to the
>   registry.
>   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.

/me adds to .plan

> - There are some cut/paste errors in managing subscribers mentioning
>   element names that concern /affiliates/.

I was in a hurry when I did that, so I thought probably I missed some
instances. Thanks for the validation. :-)

> - %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.

That is better. I think I pasted from the wrong vi register...

>   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).



- --
Peter Saint-Andre
Jabber Software Foundation

Version: GnuPG v1.4.1 (Darwin)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 3641 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://mail.jabber.org/pipermail/standards/attachments/20060414/b2271a9c/attachment.bin>

More information about the Standards mailing list