[Standards-JIG] [Fwd: I-D ACTION:draft-saintandre-jabberid-01.txt]
dave at cridland.net
Thu Jul 20 13:07:41 UTC 2006
On Thu Jul 20 13:42:29 2006, Hal Rottenberg wrote:
> 5. Security Considerations
> "A forged Jabber-ID
> header may break automated processing; therefore the Jabber-ID
> SHOULD NOT be depended upon to indicate the authenticity of the
> message or the identity of the sender."
> Should you mention here that the JID could be validated out-of-band
> using xmpp?
Probably not - you can validate that the JID's domain exists, but I'm
not sure you can do much more automatically anyway, can you? Even if
you could validate that the user exists, I'm not convinced this gains
The draft has a lot of normative references, many of which are only
referenced in informative ways. I think only RFC2822, XMPP-URI, and
RFC4234 are actually needed to implement, RFC2119 is only needed
because of two uses of MUST and SHOULD NOT, one of which is actually
in text that's really informative. (Many other specifications are
needed in practise, but are required only for RFC2822 and XMPP-URI).
For example, I don't like the use of the UNICODE and US-ASCII
references - they're embedded in informative text and really aren't
relevant beyond the discussion of why Jabber-Id uses rules from the
URI spec. To put it another way, the entire second paragraph could be
stripped from section 2, and it'd still be a valid spec, so it's at
best an informative reference.
That leaves you with just the SHOULD NOT in the security
considerations - a slight rewording will leave you without any
RFC2119 language at all, which is, I think, a sign of a very clear
specification. (I only know of one other recently, RFC4469).
Dave Cridland - mailto:dave at cridland.net - xmpp:dwd at jabber.org
Infotrope Polymer - ACAP, IMAP, ESMTP, and Lemonade
More information about the Standards