[standards-jig] UPDATED: Commands (JEP-0050)

David Sutton jabber at dsutton.legend.uk.com
Thu Jan 23 13:40:27 UTC 2003


How about 'strongly suggested'? :)

David

On Tue, Jan 21, 2003 at 11:55:48AM -0800, Matthew A. Miller wrote:
> On Tue, 2003-01-21 at 11:35, Casey Crabb wrote:
> > -----BEGIN PGP SIGNED MESSAGE-----
> > Hash: SHA1
> > 
> > A few comments:
> > When getting information on a command using disco the jep has the
> > following protocol:
> > 
> > <iq type='get'
> > ~    from='requester at domain'
> > ~    to='responder at domain'>
> > ~  <query xmlns='http://jabber.org/protocol/disco#info'
> > ~      node='config'/>
> > </iq>
> > 
> > The part I have problems with is node='config'. Since this request isn't
> > namespaced to commands its not obvious that we're trying to get
> > information about a command and not information about client
> > configuration or something else. My recommendation is that all command
> > nodes are named as a sub-namespace of the command namespace.
> > Example:
> > 
> > config would become http://jabber.org/protocol/commands#config
> > 
> > So the full new request would look like:
> > 
> > <iq type='get'
> > ~    from='requester at domain'
> > ~    to='responder at domain'>
> > ~  <query xmlns='http://jabber.org/protocol/disco#info'
> > ~      node='http://jabber.org/protocol/commands#config'/>
> > </iq>
> > 
> > This will prevent help collision and confusion with other nodes in
> > disco. The response with the list of commands will have to be changed as
> > well to match.
> 
> I have no problem with this, provided there's more consensus/agreement. 
> I had originally contemplated this, but a Council member or two thought
> it was too confusing.  Any opinions from the disco authors would be
> greatly appreciated.
> 
> Regardless, I still want to have the fixed "parent" node
> (http://jabber.org/protocol/commands).  I want command lists to be
> quickly retrievable, and any safe assumptions that can be made with
> respect to this should be. IMO, this a pretty safe assumption to make.
> 
> > 
> > Secondly in Example 6, "the responder MUST respond with a 403
> > 'Forbidden' error."  -while I agree that it should be this way for
> > compliance, implementations should not rely on getting any response from
> > the other side.
> 
> That MUST can be changed to SHOULD.  On this one, I wish there was
> something stronger than SHOULD but milder than MUST (-:
> 
> > questions, comments?
> > 
> > - --
> > Casey
> > 
> > -----BEGIN PGP SIGNATURE-----
> > Version: GnuPG v1.2.0 (MingW32)
> > Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
> > 
> > iD4DBQE+LaDsUidG/HUEju8RAqjhAKCpDHf8ch89C87Ef8f8NoYf6DV9hwCVGhgD
> > mjoBCmou0dllQSuJZcsmJQ==
> > =Ai6W
> > -----END PGP SIGNATURE-----
> > 
> > _______________________________________________
> > Standards-JIG mailing list
> > Standards-JIG at jabber.org
> > http://mailman.jabber.org/listinfo/standards-jig
> -- 
> 
> Matt "linuxwolf" Miller
> JID:	linuxwolf at outer-planes.net
> E-MAIL:	linuxwolf at outer-planes.net
> 
> - Got "JABBER"? (http://www.jabber.org/)
> 
> _______________________________________________
> Standards-JIG mailing list
> Standards-JIG at jabber.org
> http://mailman.jabber.org/listinfo/standards-jig

-- 
David Sutton
Email: dsutton at legend.co.uk
Jabber: peregrine at legend.net.uk
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 232 bytes
Desc: not available
URL: <http://mail.jabber.org/pipermail/standards/attachments/20030123/da4bb28c/attachment.sig>


More information about the Standards mailing list