Re: [sixpac] charter proposal

[Emil Ivov <[e-mail]>]

На 11.11.10 18:18, Peter Musgrave написа:
> Hi,
> 
> I agree avoiding configuration is good.

Just so that we are clear there is no misunderstanding: we aren't
talking about generic client configuration or provisioning. I guess
discovery is probably a better term.

SIP and XMPP have discovery mechanisms and I simply don't see why SIXPAC
shouldn't, especially given that it could entirely reuse the other two.
We just need to state that this how things should happen.

> The email analogy does not ring true for me. You need to ask about
> POP, IMAP etc. because these are different protocols.

The analogy was mostly between SMTP and POP or SMTP and IMAP. From a
user perspective there is absolutely no good reason to have to configure
one protocol for sending and another one for receiving mails since they
are only using a single service: e-mail.

> We do not have
> that issue here...both have AORs intended to be globally reachable.

The issue is: user A wants to connect to example.com using SIXPAC. A's
user agent needs to know what addresses it should connect to. As a
matter of fact it would almost go without saying that the most
reasonable way of doing so is to use each protocol's default mechanism.

What we are talking about is a mere reminder and possibly a suggestion
of using the same credentials. The whole thing is so natural that I am
at a complete loss as to why people are so worried about it.

Emil
> (Ok, I'm not an XMPP wizard - does it get called an AOR?)
> 
> Regards,
> 
> Peter Musgrave
> 
> On 2010-11-12, at 1:23 AM, Emil Ivov wrote:
> 
>> Hey Markus,
>> 
>> На 11.11.10 11:54, [e-mail] написа:
>>> Hi Emil,
>>> 
>>> We have discussed about the configuration a couple of times this 
>>> week. The problem was that no-one here could anymore explain what
>>> we actually meant by that statement in the charter proposal. Both
>>> SIP and XMPP clients have ways to get their configs
>>> automatically. In SIP there is no widely supported standard for
>>> this instead a number of proprietary solutions are used. > Now we
>>> do have the SIP Forum work as basis, of course.
>> 
>> OK, well it seems to me that people are interpreting this as
>> something far scarier that it actually needs to be. We are
>> absolutely _not_ talking about creating a provisioning framework
>> here. This is simply about explaining how to look up the SIP and
>> XMPP server of a sixpac account.
>> 
>> I thought we could achieve this by simply stating that sixpac
>> clients should use 3263 and 3920[bis] for the sixpac domain in
>> order to discover the SIP part of the service.
>> 
>> We could also advise service maintainers to make sure that clients
>> would be able to authorize users against the SIP and XMPP sever
>> with the same set of credentials, so that it would be safe for
>> clients to actually try this. Of course clients would need to be
>> prepared to also handle the the case where credentials turn out to
>> be different.
>> 
>> This is probably all there is to it ...
>> 
>>> But when it comes to SIXPAC clients, what it is that we could do 
>>> beyond saying that for the SIP config they use whatever is used
>>> for SIP and for XMPP whatever is used for XMPP? It may be
>>> problematic but is it a bigger problem that say configuring two
>>> separate SIP and XMPP clients?
>> 
>> The point is that users won't know what SIP is, what XMPP is and
>> why it is that they need to configure two accounts for (what
>> appears to them as) a single service.
>> 
>> Email has been crippled by this very problem for years. Of course
>> no one really knows what SMTP, and IMAP, and POP are which is why
>> when configuring your e-mail client you very often get presented
>> with a list of providers to choose from. Of course, while this
>> works to some extent for GMail and Yahoo! it does nothing to
>> address the issue for all the other providers out there.
>> 
>> Cheers, Emil
>>> 
>>> Markus
>>> 
>>> 
>>>> -----Original Message----- From: [e-mail] 
>>>> [mailto:[e-mail]] On Behalf Of ext Emil Ivov
>>>> Sent: 11 November, 2010 18:47 To: Peter Saint-Andre Cc:
>>>> [e-mail] Subject: Re: [sixpac] charter proposal
>>>> 
>>>> Hey Peter,
>>>> 
>>>> На 11.11.10 02:42, Peter Saint-Andre написа:
>>>>> To kick off discussion, here is the charter as I sent it to
>>>>> the [e-mail] list a while back, with removal of a
>>>>> clause about working on user configuration, which I think is
>>>>> a large rathole.
>>>> 
>>>> Well, I thought we had agreed on this and was quite surprised
>>>> to find out that for some unknown reason it was once again
>>>> _the_ issue with the sixpac charter :).
>>>> 
>>>> Frankly, I never really understood what people were so worried 
>>>> about. What harm could it cause to have a statement that
>>>> advises implementors how to lookup the SIP and XMPP services
>>>> for a sixpac account?
>>>> 
>>>> Besides, how else would you make this work in generic clients? 
>>>> Should users always manually configure the XMPP server address
>>>> and the SIP proxy address, port and transport?
>>>> 
>>>> Cheers, Emil
>>>>> 
>>>>> Let's discuss and get busy!
>>>>> 
>>>>> /psa
>>>>> 
>>>>> 
>>>> ========================================================================
>>>>
>>>>
>>
>>>> 
=
>>>>> SIXPAC (SIP Integration with XMPP in Presence Aware Clients)
>>>>> 
>>>> ========================================================================
>>>>
>>>>
>>
>>>> 
=
>>>>> 
>>>>> Problem Statement
>>>>> 
>>>>> Both the Session Initiation Protocol (SIP) and the
>>>>> Extensible
>>>> Messaging
>>>>> and Presence Protocol (XMPP) are widely deployed
>>>>> technologies for real-time communication over the Internet.
>>>>> In order to offer a
>>>> complete
>>>>> suite of features as well as communication across multiple 
>>>>> networks, several user-oriented software applications
>>>>> support both SIP and XMPP, and more software developers have
>>>>> expressed interest in building such "dual-stack" solutions.
>>>>> Unfortunately, it is difficult to provide a good end-user
>>>>> experience in such applications because SIP and XMPP are not
>>>>> "aware" of each other. For example:
>>>>> 
>>>>> - XMPP presence does not include availability states related
>>>>> to a SIP voice call or video call (e.g., "on the phone"),
>>>>> thus preventing an a dual-stack endpoint from showing
>>>>> presence-based communication
>>>> hints
>>>>> 
>>>>> - There is no correlation between an XMPP IM session and a
>>>>> SIP voice or video session, thus preventing a dual-stack
>>>>> endpoint from
>>>> providing
>>>>> integrated user interfaces and communications history
>>>>> 
>>>>> - SIP accounts and XMPP accounts are not directly correlated
>>>>> in
>>>> contact
>>>>> lists or vCards (and not all deployed services support
>>>>> storage of
>>>> such
>>>>> information), thus preventing a dual-stack endpoint from
>>>>> knowing
>>>> that
>>>>> a contact has both SIP and XMPP capabilities
>>>>> 
>>>>> Although some proprietary solutions exist to the foregoing 
>>>>> problems,
>>>> it
>>>>> would be preferable to define standardized solutions for the
>>>>> sake of improved interoperability.
>>>>> 
>>>>> Objectives
>>>>> 
>>>>> Because both SIP and XMPP are easily extended through new
>>>>> SIP headers and XMPP elements, it should be possible to
>>>>> provide tighter
>>>> integration
>>>>> within dual-stack SIP/XMPP user agents to improve the user 
>>>>> experience.
>>>>> 
>>>>> Any such extensions should meet the following criteria:
>>>>> 
>>>>> - Be completely optional and backwards-compatible for all 
>>>>> endpoints
>>>>> 
>>>>> - Work without changes to deployed infrastructure such as 
>>>>> existing SIP and XMPP servers, B2BUAs, firewalls, etc.
>>>>> 
>>>>> The SIXPAC WG will define a small number of SIP and XMPP 
>>>>> extensions to solve the following use cases in dual-stack 
>>>>> endpoints:
>>>>> 
>>>>> - Including SIP-based availability states in XMPP presence 
>>>>> (limited to basic presence and availability states only, not
>>>>> the full range of PIDF extensions)
>>>>> 
>>>>> - Correlating an XMPP IM session with a SIP voice/video
>>>>> session, and vice-versa
>>>>> 
>>>>> - Advertising a SIP account address over XMPP and an XMPP 
>>>>> account address over SIP
>>>>> 
>>>>> Additional use cases are out of scope, including anything
>>>>> related to
>>>> or
>>>>> requiring server integration, multiparty communication,
>>>>> SIP-based IM
>>>> and
>>>>> presence, XMPP-based voice and video, file transfer,
>>>>> generalized
>>>> service
>>>>> discovery and capabilities exchange, full protocol
>>>>> translation in communication gateways, shared credentials
>>>>> across both SIP and XMPP accounts, rich presence extensions
>>>>> for features such as geolocation, etc. Although such topics
>>>>> are important and interesting, they are out
>>>> of
>>>>> scope for this group.
>>>>> 
>>>>> However, in addition to the protocol extensions explicitly 
>>>>> mentioned above, the group may also define best practices
>>>>> related to the implementation and deployment of dual-stack
>>>>> SIP/XMPP endpoints.
>>>>> 
>>>>> Deliverables
>>>>> 
>>>>> - Use cases and protocol requirements
>>>>> 
>>>>> - XMPP presence extension for SIP-based availability states
>>>>> 
>>>>> - Media session correlation extensions for SIP and XMPP
>>>>> 
>>>>> - Contact address advertisement extensions for SIP and XMPP
>>>>> 
>>>>> - Best practices for implementation and deployment of
>>>>> dual-stack endpoints
>>>>> 
>>>>> Milestones
>>>>> 
>>>>> Feb 2011  Submit use cases and protocol requirements document
>>>>> to IESG (Informational)
>>>>> 
>>>>> Oct 2011  Submit XMPP presence extension document to IESG 
>>>>> (Standards Track)
>>>>> 
>>>>> Oct 2011  Submit media session correlation extensions
>>>>> document to IESG (Standards Track)
>>>>> 
>>>>> Oct 2011  Submit contact address advertisement extension
>>>>> document to IESG (Standards Track)
>>>>> 
>>>>> Oct 2011  Submit best practices document to IESG
>>>>> (Informational)
>>>>> 
>>>>> 
>>>>> 
>>>>> 
>>>>> 
>>>>> _______________________________________________ sixpac
>>>>> mailing list [e-mail] 
>>>>> https://www.ietf.org/mailman/listinfo/sixpac
>>>> 
>>>> -- Emil Ivov, Ph.D.                               67000 
>>>> Strasbourg, Project Lead
>>>> France SIP Communicator [e-mail] PHONE:
>>>> +33.1.77.62.43.30 http://sip-communicator.org FAX:
>>>> +33.1.77.62.47.31