Re: [dispatch] Charter Proposal: SIP-XMPP Mapping

["Ross, Christopher [USA]" <[e-mail]>]

Continuing this work and making it official would help to solve a lot of the interoperability challenges and mapping issues we see between products today. 

I hope the community can work together to push this work forward.

-----Original Message-----
From: [e-mail] [mailto:[e-mail]] On Behalf Of [e-mail]
Sent: Wednesday, February 20, 2013 9:28 PM
To: [e-mail]
Subject: [External] dispatch Digest, Vol 47, Issue 15

If you have received this digest without all the individual message attachments you will need to update your digest options in your list subscription.  To do so, go to 

https://www.ietf.org/mailman/listinfo/dispatch

Click the 'Unsubscribe or edit options' button, log in, and set "Get MIME or Plain Text Digests?" to MIME.  You can set this option globally for all the list digests you receive at this point.



Send dispatch mailing list submissions to
	[e-mail]

To subscribe or unsubscribe via the World Wide Web, visit
	https://www.ietf.org/mailman/listinfo/dispatch
or, via email, send a message with subject or body 'help' to
	[e-mail]

You can reach the person managing the list at
	[e-mail]

When replying, please edit your Subject line so it is more specific than "Re: Contents of dispatch digest..."


Today's Topics:

   1. Re: Charter Proposal: SIP-XMPP Mapping (Salvatore Loreto)
   2. Re: Charter Proposal: SIP-XMPP Mapping (Emil Ivov)
   3. Re: Charter Proposal: SIP-XMPP Mapping (Michael Lundberg)
   4. Re: Charter Proposal: SIP-XMPP Mapping (Sa?l Ibarra Corretg?)
   5. Re: URI schemes in P-Asserted-Identity (Peter Saint-Andre)


----------------------------------------------------------------------

Message: 1
Date: Wed, 20 Feb 2013 22:42:44 +0200
From: Salvatore Loreto <[e-mail]>
To: [e-mail]
Subject: Re: [dispatch] Charter Proposal: SIP-XMPP Mapping
Message-ID: <[e-mail]>
Content-Type: text/plain; charset="ISO-8859-1"; format=flowed

I do support this proposal


/Sal

On 2/16/13 12:37 AM, Peter Saint-Andre wrote:
> Charter Proposal: SIP-XMPP Mapping
> DISPATCH WG
> IETF 86, Orlando
>
> Problem Statement
>
> The IETF has defined two signalling technologies that can be used for 
> multimedia session negotiation, instant messaging, presence, file 
> transfer, capabilities discovery, notifications, and other types of 
> real-time functionality:
>
> o  The Session Initiation Protocol (SIP), along with various SIP
>     extensions developed within the SIP for Instant Messaging and
>     Presence Leveraging Extensions (SIMPLE) Working Group.
>
> o  The Extensible Messaging and Presence Protocol (XMPP), along
>     with various XMPP extensions developed by the IETF as well as by
>     the XMPP Standards Foundation.
>
> SIP has been focused primarily on media session negotiation (e.g. 
> audio and video), whereas XMPP has been focused primarily on messaging 
> and presence.  As a result, the technologies are mostly complementary.
> However, there is also some overlap between SIP and XMPP, since there 
> are SIP extensions for messaging, presence, groupchat, file transfer
> (etc.) and there are XMPP extensions for multimedia session negotiation.
> This overlap has practical implications, since some deployed services 
> use SIP for both media and (broadly) messaging, whereas other deployed 
> services use XMPP for both messaging and media.  When such services 
> wish to exchange information, they often need to translate their 
> native protocol (either SIP or XMPP) to the other protocol (either 
> XMPP or SIP).
>
> Implementers needing to perform such protocol mappings have often 
> worked out their own heuristics for doing so.  Unfortunately, these 
> heuristics are not always consistent, which can lead to interoperability problems.
>
> Objectives
>
> To make it easier for implementers to enable interworking between 
> SIP-based systems and XMPP-based systems, several Internet-Drafts have 
> defined guidelines for protocol mapping between SIP and XMPP, starting 
> with draft-saintandre-xmpp-simple-00 in early 2004.  The current 
> documents are:
>
> draft-saintandre-sip-xmpp-core
> draft-saintandre-sip-xmpp-presence
> draft-saintandre-sip-xmpp-im
> draft-saintandre-sip-xmpp-chat
> draft-saintandre-sip-xmpp-groupchat
>
> These documents are quite stable and the authors have received 
> feedback from a number of implementers over the years.  However, 
> implementers do not always know about these documents because they are 
> Internet-Drafts and sometimes have expired.  Thus it would be helpful 
> to polish them off and publish them as RFCs (and perhaps other 
> documents in the same series, covering topics like media signalling, 
> capabilities discovery, and file transfer).
>
> Deliverables
>
> 1. Address mapping and error handling
> 2. Presence mapping
> 3. Mapping for single instant messages 4. Mapping for one-to-one text 
> chat sessions 5. Mapping for multi-user text chat sessions
>
> Any additional work would require a recharter.
>
> Milestones
>
> To be determined.
>
> ###
>
> _______________________________________________
> dispatch mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/dispatch


--
Salvatore Loreto, PhD
www.sloreto.com



------------------------------

Message: 2
Date: Wed, 20 Feb 2013 21:46:32 +0100
From: Emil Ivov <[e-mail]>
To: Peter Saint-Andre <[e-mail]>
Cc: DISPATCH <[e-mail]>
Subject: Re: [dispatch] Charter Proposal: SIP-XMPP Mapping
Message-ID: <[e-mail]>
Content-Type: text/plain; charset=ISO-8859-1

Mapping SIP to XMPP is something I personally view as very important and
this proposal seems very reasonable and well targeted at addressing the
issue.

Emil

On 15.02.13, 23:37, Peter Saint-Andre wrote:
> Charter Proposal: SIP-XMPP Mapping
> DISPATCH WG
> IETF 86, Orlando
> 
> Problem Statement
> 
> The IETF has defined two signalling technologies that can be used
> for multimedia session negotiation, instant messaging, presence,
> file transfer, capabilities discovery, notifications, and other types of
> real-time functionality:
> 
> o  The Session Initiation Protocol (SIP), along with various SIP
>    extensions developed within the SIP for Instant Messaging and
>    Presence Leveraging Extensions (SIMPLE) Working Group.
> 
> o  The Extensible Messaging and Presence Protocol (XMPP), along
>    with various XMPP extensions developed by the IETF as well as by
>    the XMPP Standards Foundation.
> 
> SIP has been focused primarily on media session negotiation (e.g. audio
> and video), whereas XMPP has been focused primarily on messaging and
> presence.  As a result, the technologies are mostly complementary.
> However, there is also some overlap between SIP and XMPP, since there
> are SIP extensions for messaging, presence, groupchat, file transfer
> (etc.) and there are XMPP extensions for multimedia session negotiation.
> This overlap has practical implications, since some deployed services
> use SIP for both media and (broadly) messaging, whereas other deployed
> services use XMPP for both messaging and media.  When such services wish
> to exchange information, they often need to translate their native
> protocol (either SIP or XMPP) to the other protocol (either XMPP or
> SIP).
> 
> Implementers needing to perform such protocol mappings have often worked
> out their own heuristics for doing so.  Unfortunately, these heuristics
> are not always consistent, which can lead to interoperability problems.
> 
> Objectives
> 
> To make it easier for implementers to enable interworking between
> SIP-based systems and XMPP-based systems, several Internet-Drafts have
> defined guidelines for protocol mapping between SIP and XMPP, starting
> with draft-saintandre-xmpp-simple-00 in early 2004.  The current
> documents are:
> 
> draft-saintandre-sip-xmpp-core
> draft-saintandre-sip-xmpp-presence
> draft-saintandre-sip-xmpp-im
> draft-saintandre-sip-xmpp-chat
> draft-saintandre-sip-xmpp-groupchat
> 
> These documents are quite stable and the authors have received feedback
> from a number of implementers over the years.  However, implementers do
> not always know about these documents because they are Internet-Drafts
> and sometimes have expired.  Thus it would be helpful to polish them off
> and publish them as RFCs (and perhaps other documents in the same series,
> covering topics like media signalling, capabilities discovery, and file
> transfer).
> 
> Deliverables
> 
> 1. Address mapping and error handling
> 2. Presence mapping
> 3. Mapping for single instant messages
> 4. Mapping for one-to-one text chat sessions
> 5. Mapping for multi-user text chat sessions
> 
> Any additional work would require a recharter.
> 
> Milestones
> 
> To be determined.
> 
> ###
> 
> _______________________________________________
> dispatch mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/dispatch
> 

-- 
https://jitsi.org


------------------------------

Message: 3
Date: Wed, 20 Feb 2013 15:55:23 -0500
From: Michael Lundberg <[e-mail]>
To: [e-mail]
Subject: Re: [dispatch] Charter Proposal: SIP-XMPP Mapping
Message-ID:
	<[e-mail]>
Content-Type: text/plain; charset=ISO-8859-1

I strongly support this proposal!

Michael

On Wed, Feb 20, 2013 at 3:42 PM, Salvatore Loreto
<[e-mail]> wrote:
> I do support this proposal
>
>
> /Sal
>
> On 2/16/13 12:37 AM, Peter Saint-Andre wrote:
>>
>> Charter Proposal: SIP-XMPP Mapping
>> DISPATCH WG
>> IETF 86, Orlando
>>
>> Problem Statement
>>
>> The IETF has defined two signalling technologies that can be used
>> for multimedia session negotiation, instant messaging, presence,
>> file transfer, capabilities discovery, notifications, and other types of
>> real-time functionality:
>>
>> o  The Session Initiation Protocol (SIP), along with various SIP
>>     extensions developed within the SIP for Instant Messaging and
>>     Presence Leveraging Extensions (SIMPLE) Working Group.
>>
>> o  The Extensible Messaging and Presence Protocol (XMPP), along
>>     with various XMPP extensions developed by the IETF as well as by
>>     the XMPP Standards Foundation.
>>
>> SIP has been focused primarily on media session negotiation (e.g. audio
>> and video), whereas XMPP has been focused primarily on messaging and
>> presence.  As a result, the technologies are mostly complementary.
>> However, there is also some overlap between SIP and XMPP, since there
>> are SIP extensions for messaging, presence, groupchat, file transfer
>> (etc.) and there are XMPP extensions for multimedia session negotiation.
>> This overlap has practical implications, since some deployed services
>> use SIP for both media and (broadly) messaging, whereas other deployed
>> services use XMPP for both messaging and media.  When such services wish
>> to exchange information, they often need to translate their native
>> protocol (either SIP or XMPP) to the other protocol (either XMPP or
>> SIP).
>>
>> Implementers needing to perform such protocol mappings have often worked
>> out their own heuristics for doing so.  Unfortunately, these heuristics
>> are not always consistent, which can lead to interoperability problems.
>>
>> Objectives
>>
>> To make it easier for implementers to enable interworking between
>> SIP-based systems and XMPP-based systems, several Internet-Drafts have
>> defined guidelines for protocol mapping between SIP and XMPP, starting
>> with draft-saintandre-xmpp-simple-00 in early 2004.  The current
>> documents are:
>>
>> draft-saintandre-sip-xmpp-core
>> draft-saintandre-sip-xmpp-presence
>> draft-saintandre-sip-xmpp-im
>> draft-saintandre-sip-xmpp-chat
>> draft-saintandre-sip-xmpp-groupchat
>>
>> These documents are quite stable and the authors have received feedback
>> from a number of implementers over the years.  However, implementers do
>> not always know about these documents because they are Internet-Drafts
>> and sometimes have expired.  Thus it would be helpful to polish them off
>> and publish them as RFCs (and perhaps other documents in the same series,
>> covering topics like media signalling, capabilities discovery, and file
>> transfer).
>>
>> Deliverables
>>
>> 1. Address mapping and error handling
>> 2. Presence mapping
>> 3. Mapping for single instant messages
>> 4. Mapping for one-to-one text chat sessions
>> 5. Mapping for multi-user text chat sessions
>>
>> Any additional work would require a recharter.
>>
>> Milestones
>>
>> To be determined.
>>
>> ###
>>
>> _______________________________________________
>> dispatch mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/dispatch
>
>
>
> --
> Salvatore Loreto, PhD
> www.sloreto.com
>
> _______________________________________________
> dispatch mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/dispatch


------------------------------

Message: 4
Date: Wed, 20 Feb 2013 22:03:25 +0100
From: Sa?l Ibarra Corretg? <[e-mail]>
To: Emil Ivov <[e-mail]>
Cc: DISPATCH <[e-mail]>
Subject: Re: [dispatch] Charter Proposal: SIP-XMPP Mapping
Message-ID: <[e-mail]>
Content-Type: text/plain; charset=iso-8859-1


On Feb 20, 2013, at 9:46 PM, Emil Ivov wrote:

> Mapping SIP to XMPP is something I personally view as very important and
> this proposal seems very reasonable and well targeted at addressing the
> issue.
> 

+1.

> Emil
> 
> On 15.02.13, 23:37, Peter Saint-Andre wrote:
>> Charter Proposal: SIP-XMPP Mapping
>> DISPATCH WG
>> IETF 86, Orlando
>> 
>> Problem Statement
>> 
>> The IETF has defined two signalling technologies that can be used
>> for multimedia session negotiation, instant messaging, presence,
>> file transfer, capabilities discovery, notifications, and other types of
>> real-time functionality:
>> 
>> o  The Session Initiation Protocol (SIP), along with various SIP
>>   extensions developed within the SIP for Instant Messaging and
>>   Presence Leveraging Extensions (SIMPLE) Working Group.
>> 
>> o  The Extensible Messaging and Presence Protocol (XMPP), along
>>   with various XMPP extensions developed by the IETF as well as by
>>   the XMPP Standards Foundation.
>> 
>> SIP has been focused primarily on media session negotiation (e.g. audio
>> and video), whereas XMPP has been focused primarily on messaging and
>> presence.  As a result, the technologies are mostly complementary.
>> However, there is also some overlap between SIP and XMPP, since there
>> are SIP extensions for messaging, presence, groupchat, file transfer
>> (etc.) and there are XMPP extensions for multimedia session negotiation.
>> This overlap has practical implications, since some deployed services
>> use SIP for both media and (broadly) messaging, whereas other deployed
>> services use XMPP for both messaging and media.  When such services wish
>> to exchange information, they often need to translate their native
>> protocol (either SIP or XMPP) to the other protocol (either XMPP or
>> SIP).
>> 
>> Implementers needing to perform such protocol mappings have often worked
>> out their own heuristics for doing so.  Unfortunately, these heuristics
>> are not always consistent, which can lead to interoperability problems.
>> 
>> Objectives
>> 
>> To make it easier for implementers to enable interworking between
>> SIP-based systems and XMPP-based systems, several Internet-Drafts have
>> defined guidelines for protocol mapping between SIP and XMPP, starting
>> with draft-saintandre-xmpp-simple-00 in early 2004.  The current
>> documents are:
>> 
>> draft-saintandre-sip-xmpp-core
>> draft-saintandre-sip-xmpp-presence
>> draft-saintandre-sip-xmpp-im
>> draft-saintandre-sip-xmpp-chat
>> draft-saintandre-sip-xmpp-groupchat
>> 
>> These documents are quite stable and the authors have received feedback
>> from a number of implementers over the years.  However, implementers do
>> not always know about these documents because they are Internet-Drafts
>> and sometimes have expired.  Thus it would be helpful to polish them off
>> and publish them as RFCs (and perhaps other documents in the same series,
>> covering topics like media signalling, capabilities discovery, and file
>> transfer).
>> 
>> Deliverables
>> 
>> 1. Address mapping and error handling
>> 2. Presence mapping
>> 3. Mapping for single instant messages
>> 4. Mapping for one-to-one text chat sessions
>> 5. Mapping for multi-user text chat sessions
>> 
>> Any additional work would require a recharter.
>> 
>> Milestones
>> 
>> To be determined.
>> 
>> ###
>> 
>> _______________________________________________
>> dispatch mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/dispatch
>> 
> 
> -- 
> https://jitsi.org
> _______________________________________________
> dispatch mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/dispatch

--
Sa?l Ibarra Corretg?
AG Projects





------------------------------

Message: 5
Date: Wed, 20 Feb 2013 19:27:47 -0700
From: Peter Saint-Andre <[e-mail]>
To: "Dale R. Worley" <[e-mail]>
Cc: [e-mail]
Subject: Re: [dispatch] URI schemes in P-Asserted-Identity
Message-ID: <[e-mail]>
Content-Type: text/plain; charset=UTF-8

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 2/13/13 6:45 AM, Dale R. Worley wrote:
>> From: Dean Willis <[e-mail]>
>> 
>> IIRC, we meant to use Contact: for alt-protocol references.
>> 
>> RFC 3261 11.2 shows the use of a Contact: field in a response to
>> an Options request to indicate an alternate protocol contact:
>> 
>> "Contact header fields MAY be present in a 200 (OK)  response
>> and have the same semantics as in a 3xx response.  That is,  they
>> may list a set of alternative names and methods of reaching the
>> user."
> 
>> I suspect that RFC 3261 12.1.2 is overstrict in its restriction
>> of Contact in an dialog-initiating request to encode exactly one
>> URI which must be SIP or SIPS.  I'm thinking it should say
>> "Exactly one SIP or SIPS URI" without restricting additional URIs
>> that might be present.
> 
> I agree with Paul here.
> 
> The difficulty with Contact is that it has two distinctly
> different uses.  One use is to indicate "You can contact this AOR
> here."  That's its purpose in 3xx responses and 2xx responses to
> OPTIONS.  The other use is, "This is the routing address for this
> endpoint, for this dialog."  That's its purpose in INVITE and 2xx
> responses to INVITEs.
> 
> As far as I can tell, this unspoken distinction was
> well-established by the time RFC 3261 was approved.

Revisiting this topic, I understand the distinction here, but that
leaves me wondering how to include an XMPP address in a SIP INVITE.
Apparently both P-Asserted-Identity (or P-Preferred-Identity) and
Contact are inappropriate. And defining a new SIP header seems to be a
non-starter. However, I suppose the Contact header could be included
in non-INVITE messages, such as OPTIONS.

Peter

- -- 
Peter Saint-Andre
https://stpeter.im/


-----BEGIN PGP SIGNATURE-----
Version: GnuPG/MacGPG2 v2.0.18 (Darwin)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQIcBAEBAgAGBQJRJYYjAAoJEOoGpJErxa2pcH8P/ArcB3Kwki7ZDf+fB4jNQoY+
X6rK/1UqGzBsn5usraenL/zwr5Q7asOTGZOpEt6KPfszyKa7+AhQGfFWNji9ifj5
KTZqfeDO2VXXVDr2nTQJffxMXHt6q6Ate1KhrYfctyjYW0wZMF08el9kZtLMKFwc
qiRASCcrA0nv6oqOFO6vRQ99BfP94TGII4TqNU41pBphDwyX/61Ln9yMzfpEuh/2
VlO5+kZoV1auyawBYb5wHakioFc2bqGR3wwAVPrpqhs6DZtRY/jArMaa/MUHdBhL
k8Aw799RN55MaIePtdq4AjlgpCYmpKy4kYkfl8TBQ1hQSjoAtU5dZwhcpgEt27YY
mqe23aXegT/O0hhEcl2L/rmgm7CDYTKgjZ+t/0N6yg/FzE8PnUJl8JOPXs4+J3NC
2kpOnpnTUKhC7nD6IzRTrud2uHU5UFJWodsubzVDF1nUD/F/m/b2Sg/8twZW+P/Z
W3fY3gi374+ZiEzZqh9+Eumvda/12UGKjYcSGDuYDD403ONvW24aURAMD9N3WtWY
HXzio+foM5YKB1Zu3FImDbAmu7EIogGpAyhF6fazGOk0Ytyr000URfI/pj8gPYQi
BYJV5klSdq6U7QVXAry+5cMJjfCAD24V4ia7H6C3chRQXMRZDCY6yCrBtbfXsYAm
MF+//A+qeyD4x/i5Q96c
=z5X3
-----END PGP SIGNATURE-----


------------------------------

_______________________________________________
dispatch mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/dispatch


End of dispatch Digest, Vol 47, Issue 15
****************************************