[Standards-JIG] JEP-0158 + JEP-0159: feedback
stpeter at jabber.org
Wed May 10 02:34:11 UTC 2006
-----BEGIN PGP SIGNED MESSAGE-----
Ian Paterson and I recently discussed both JEP-0158 and JEP-0159 so I
figured I would re-read them. Here is some feedback...
The terminology of entity and client is a bit confusing (at least it
confused me). I think it would be easier to understand if we used the
terms sender and recipient or challenger and challengee (if that's a
It's a good idea to define a field type for media in data forms but
specifying that the JEP-0004 'type' attribute shall be "text-single" and
then putting a <media/> element inside seems a bit counter-intuitive.
Would type='fixed' make more sense perhaps? Or even a new value for the
'type' attribute (it's really type='xml' in this case).
I'd prefer the namespace to be 'http://jabber.org/protocol/mediafield'
or something like that so people don't think the 'media' namespace
provides more functionality than it does.
In the text before examples 7 and 8, I think we mean MUST, not SHOULD.
I think the JEP needs a section on Internationalization Considerations
(e.g., to show localized versions of the text in Table 1).
IMHO the 'from' attributes in Section 7 are problematic, since they leak
presence. Is the scenario here that the challenger's server does not
support robot challenges so it sends the challenge directly? That
doesn't seem like a legacy client to me. :-)
I think Section 13 (open issues) belongs in Section 2 under the heading
of non-requirements (or somewhere else in the body of the text).
Note 16 should refer to JEP-0161.
I think note 17 needs to say that protocols for enabling a client to ask
its server to complete a hashcash challenge are explicitly outside the
scope of this JEP.
It would be helpful for this JEP to explain the rationale further, and
also explain that defining a different fall-through action for privacy
lists (RFC 3921) would have been preferable except it's not subject to
change. Or is it? Could we perhaps define a "challenge" action in the
revisions to RFC 3921, or even define a registry for privacy list
actions? The method currently defined in JEP-0159 is creative but a bit
hard to discover (or at least discovery is not really well defined right
now, e.g., the order of discovery and then setting privacy list; also is
a privacy list client to assume that "challenge" is the fall-through if
the server advertises support for the "spim-control" feature?).
Jabber Software Foundation
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (Darwin)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
-----END PGP SIGNATURE-----
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 3641 bytes
Desc: S/MIME Cryptographic Signature
More information about the Standards