[Standards-JIG] JEP-0158 + JEP-0159: feedback

Peter Saint-Andre stpeter at jabber.org
Wed May 10 02:34:11 UTC 2006

Hash: SHA1

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
word ;-).

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?).



- --
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/20060509/f23c9455/attachment.bin>

More information about the Standards mailing list