Re: [sixpac] charter proposal

["Shekh-Yusef, Rifaat (Rifaat)" <[e-mail]>]

Hi,

I too think that this group should avoid dealing with the configuration issue.

> 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.

I do not see how statements like "should use..." will help, as these types of statements are most of the time ignored anyway.

Regards,
 Rifaat


-----Original Message-----
From: [e-mail] [mailto:[e-mail]] On Behalf Of Emil Ivov
Sent: Thursday, November 11, 2010 12:23 PM
To: [e-mail]
Cc: [e-mail]
Subject: Re: [sixpac] charter proposal

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: [phone] http://sip-communicator.org
>> FAX:   [phone]
>> 
>> _______________________________________________ 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: [phone]
http://sip-communicator.org                    FAX:   [phone]

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