Re: Gateway use case

Thanks, Peter!

I think the email variant will do for my purposes here, particularly if
the forwarding is invisible to the sender.  In fact, it would seem
there's no way at all for the sender to know this is happening, unlike
the gateway case, where (I believe) one could tell from the destination
address.

So in the case Peter describes

    * How many instances of the one-way MEP are there?
    * Who are the senders and receivers?
    * What bindings are used and how?


Peter Saint-Andre wrote:
> David Hull wrote:
>   
>> I like Jabber.  My friend uses BorgIM.  I can still send my friend a
>> message by sending a jabber message to a specially-constructed jabber
>> id.  This is transparent to me using my favorite jabber client.  I
>> believe it's also transparent at the API level.
>>     
>
> Gateways are evil. They act as client proxies. So you give the gateway
> your credentials on BorgIM and it logs in as you on BorgIM.
>
>   
>> Now suppose I send a SOAP envelope to my friend's jabber id.  My friend
>> receives it and executes the SOAP processing model on it.  
>>     
>
> Does BorgIM have the ability to transmit SOAP envelopes? Typically, the
> legacy IM services know about plaintext and maybe HTML (or RTF) only.
> They don't know anything about SOAP payloads or XML. That's a special
> Jabber thing since we have a pure XML transport and we've defined a SOAP
> binding: http://www.xmpp.org/extensions/xep-0072.html
>
>   
>> The
>> ImmediateDestination will be my friend's BorgIM id, rendered as a jabber id.
>>
>>     * How many instances of the one-way MEP are there?  Who are the
>>       senders and receivers?
>>     * What bindings are used, and how?
>>     
>
> I don't see that BorgIM has a SOAP binding. Until and unless there is
> such a binding, I don't think it's worth speculating.
>
> Now, here's a potentially more realistic scenario:
>
> 1. I send a SOAP envelope to you via the XMPP binding.
>
> 2. You're offline and you've configured your XMPP service to not store
> messages offline for later delivery but instead to forward the message
> to an email inbox (e.g., you can do that in Google Talk).
>
> 3. Now you receive the message via the SMTP binding. You reply via SMTP
> and the message is sent to my email inbox.
>
> I haven't tracked the whole MEP conversation well enough (sorry!) to
> elucidate how many senders and receivers there are in that kind of scenario.
>
> Peter
>
>