[Standards] [E2E] Why we need a <body> element

Dave Cridland dave at cridland.net
Tue Sep 30 17:21:56 UTC 2008


On Tue Sep 30 17:42:58 2008, Jonathan Schleifer wrote:
> Am 30.09.2008 um 17:33 schrieb Dave Cridland:
> 
>> And to cover our coversation elsewhere (through that funny  
>> "Instant  Messaging" thing), a downside of including <body> is  
>> that a client  might assume it's a reasonable alternative, whereas  
>> otherwise it  could bounce the message (type="error") which would  
>> cause the sender  to re-initiate the session.
> 
> Messages with unknown stuff are simply ignored, the RFC says so  
> IIRC.
> 
> 
Hmmm. I wonder if we could move toward changing that. Messages  
without any known stuff feel like they should result in an error.


>> So yes, JS's problem is real, but the proposed cure of adding  
>> <body>  to IBB is worse than the disease, and I'll cheerfully  
>> admit I hadn't  thought this one through - sorry for jumping in  
>> like that.
> 
> It solves the problem with clients that don't know IBB, thus will  
> just  throw away the stanza and not warn - the user never knows he  
> lost a  message.
> 
> 
It's certainly no worse than without encrypted streams.


>> Incidentally, both ends can check the session by using XEP-0199   
>> inside the P2P XML stream. And XEP-0198 is also applicable here,  
>> and  much more useful than XEP-0184 on the IBB packets.
> 
> Think about small clients that only support the really necessary  
> stuff  to use XMPP.

But then they wouldn't have E2E encryption anyway.

I suppose the point is that if you want to have a highly reliable  
stream, you use XEP-0198 on it, and this applies whether you're  
referring to a C2S or P2P stream.

Dave.
-- 
Dave Cridland - mailto:dave at cridland.net - xmpp:dwd at dave.cridland.net
  - acap://acap.dave.cridland.net/byowner/user/dwd/bookmarks/
  - http://dave.cridland.net/
Infotrope Polymer - ACAP, IMAP, ESMTP, and Lemonade



More information about the Standards mailing list