-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 6/30/09 6:20 PM, Brian Cully wrote:
>     As the spec stands today, there's no place in subscription
> authorization requests to store subscription options[1]. I believe these
> subscription options are required to be sent to the node owners so they
> can make informed decisions about authorization, particularly with
> regards to the pubsub#expire option and filters for content based
> subscriptions.

Does anyone currently use subscription authorization requests?

>     Theoretically, an owner can query the pending subscription by subid
> when it gets the authorization request, but this breaks when options are
> updated post-subscription, since owners aren't informed of any new
> options and can no longer approve or deny the request based on them.
> 
>     I propose two things:
> 
>     1) Subscription approval events are sent to owners when subscribing
> or when updating options after a subscription, and
> 
>     2) Options are included in the approval request somehow.
> 
>     Regarding the last option, I see basically two approaches:
> 
>     1) Nest the options XForm in the approval request XForm, or
> 
>     2) Normalize the approval XForm with the subscription option XForm.
> 
>     The first would likely be very forward-compatible, as you're
> guaranteed not to have slot conflicts between the approval form and the
> options form, but may have many repercussions for client and server
> developers for what may be no benefit. The second has the advantage of
> easier implementations with the possibility of future conflicts. As
> things stand now, I do not believe there are any conflicts between the
> forms, so normalization would probably be the easiest path all around.
> 
>     What do y'all think?

Option 2.2 seems preferable. Could you sketch out what you mean
normalization?

Peter

- --
Peter Saint-Andre
https://stpeter.im/


-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.8 (Darwin)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAkqxa3AACgkQNL8k5A2w/vxSgACfdh0s8ItZwtV6epyG6e4D7q7j
epEAoJZWfQDNZVoIEuowcvceb/OjiF6+
=9WEr
-----END PGP SIGNATURE-----

Reply via email to