[Council] [Fwd: [Standards-JIG] JEP-0060: open issues]

[Peter Saint-Andre]

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

FYI to be discussed in the Council meeting on Wednesday...

/psa

- -------- Original Message --------
Subject: [Standards-JIG] JEP-0060: open issues
Date: Mon, 12 Jun 2006 14:45:08 -0600
From: Peter Saint-Andre <stpeter at jabber.org>
Reply-To: Jabber protocol discussion list <standards-jig at jabber.org>
To: standards-jig at jabber.org

In the interest of gaining consensus and moving JEP-0060 along, here is
a summary of the open issues regarding version 1.8 of JEP-0060. Let me
know if I've missed anything.

Oh, and one "meta-issue" is whether to address these open issues in 1.8
or in 1.9:

http://mail.jabber.org/pipermail/council/2006-June/001874.html

******

1. Data Forms

Get rid of 'access' attribute on <configure/> element?

Also get rid of 'type' attribute on <create/> element?

Force use of node configuration data form in both cases or just for
access model (create 'type' was in 1.7)?

http://mail.jabber.org/pipermail/standards-jig/2006-June/011496.html

******

2. 'node' attribute for <items/> element

What should the value of the 'node' attribute be for <items/> elements
in event notifications received from collection nodes? Specifically,
should it be the NodeID of the collection node (current policy) or
sometimes (in the case of transient, notification-only nodes as the
generator of the notification) the NodeID of the generating node?

http://mail.jabber.org/pipermail/standards-jig/2006-June/011497.html

******

3. Handling of configuration-required subscriptions

When a subscription to a node must be configured in order to take
effect, should we return (1) a success-with-configuration-request
(current policy) or (2) a <not-acceptable/> error?

Should we recommend (1) but allow (2)?

http://mail.jabber.org/pipermail/standards-jig/2006-June/011546.html

******

4. Subscription retrieval

Should we define a way to retrieve all subscriptions (with full
configuration information) in one request?

http://mail.jabber.org/pipermail/standards-jig/2006-June/011546.html

******

5. Ordered nodes

Should we define a way to enforce order on the items published at a node?

http://mail.jabber.org/pipermail/standards-jig/2006-June/011509.html
http://mail.jabber.org/pipermail/standards-jig/2006-June/011547.html

(And also, it seems, to enforce order on the nodes within a collection,
though what that means is unclear to me.)

******

6. Configuration inheritance

Should we define a way to enforce inheritance of node configuration options?

http://mail.jabber.org/pipermail/standards-jig/2006-June/011557.html

******

7. Paging through published items

Should we define a way to set the "start item" for items retrieval?

http://mail.jabber.org/pipermail/standards-jig/2006-June/011558.html

And further, should we get rid of 'max_items' attribute and do "paging"
using JEP-0059?

http://mail.jabber.org/pipermail/standards-jig/2006-June/011563.html

******

Peter


- --
Peter Saint-Andre
Jabber Software Foundation
http://www.jabber.org/people/stpeter.shtml

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

iD8DBQFEjdKXNF1RSzyt3NURAkFGAJ9UBTBxmG53MYeosexGCcEJx09Y0gCeIoa2
a9ZUBS20QG78uh3Fbfq4tCY=
=YvQ/
-----END PGP SIGNATURE-----
-------------- 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/council/attachments/20060612/d5c6cb35/smime.bin