[Standards-JIG] JEP-163 (SPPS) comments

Peter Saint-Andre stpeter at jabber.org
Mon Jan 30 22:02:18 UTC 2006

Hash: SHA1

Kevin Smith wrote:
> On 30 Jan 2006, at 21:20, Joe Hildebrand wrote:
>>>> For all three of these, I think the "MUST allow" should be "SHOULD
>>>> allow", to account for other potential access controls that the
>>>> server may know.  One example might be ethical boundaries enforced
>>>> by a policy engine.
>>> Can you give an example? I'm keen on spps staying as simple and well
>>> defined as possible and only allowing doubt where absolutely necessary.
>> Hal nailed it in his reply.
> In the case of government agencies restricting the flow of data, we're
> not really talking about avatars and user tunes are we? I'd argue that
> more complex access rules for more complex use cases are into the domain
> of full pub-sub and that the simple pubsub jep should be kept
> uncomplicated :)

Well, an XMPP server with SPPS support could enforce additional security
policies that are outside the realm of SPPS. What if the user is the CEO
of a company, a four-star general, or (more prosaically) a UAV or robot,
and access policies need to be applied before allowing another entity to
see the geolocation of that user? I have no objections to saying that a
servers MAY enforce such security policies (since they're going to no
matter what we say in the spec), as long as that complexity is specific
to an implementation or deployment and does not change the SPPS spec
itself. From the end-user perspective, all this means is that you may
get a forbidden error if you try to subscribe to or request certain
kinds of information from that user.


- --
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/20060130/57fd87f8/attachment.bin>

More information about the Standards mailing list