Subject: [sixpac] FW: New Version Notification for draft-veikkolainen-sip-xmpp-coex-reqs-02

From: <[email-masked]>
Date: Wed, 26 Jan 2011 20:20:19 +0000

You're right, we should get some discussion going on.

I have just uploaded a new version of draft-veikkolainen-sip-xmpp-coex-reqs, which can be found at http://www.ietf.org/internet-drafts/draft-veikkolainen-sip-xmpp-coex-reqs-02.txt 

The changes in this version address the comments made by Peter Musgrave (mainly clarifications):

In REQ-1: “SIP contact” changed to “SIP address”

In REQ-3: "It must be possible to include SIP real-time media related contact and status in XMPP presence information." changed to "It must be possible to include SIP address and status information in XMPP presence."

And a couple of typos.

One further comment made by Peter might merit a bit more discussion, namely saying something about cases where two SIP devices are registered to the same AOR and two XMPP clients are logged in. This is related to the discussion we had an correlation, and whether or not it should be mentioned in the charter or not. 

Opinions on this would be helpful.

Also, please take a fresh look at the draft and express your opinions on whether the approach in general makes sense, do you agree with the use cases and requirements, is something missing etc.

Thanks
Simo

-----Original Message-----
From: ext IETF I-D Submission Tool [mailto:[email-masked]] 
Sent: 26 January, 2011 22:05
To: Veikkolainen Simo (Nokia-MS/Helsinki)
Cc: Isomaki Markus (Nokia-CIC/Espoo)
Subject: New Version Notification for draft-veikkolainen-sip-xmpp-coex-reqs-02 

A new version of I-D, draft-veikkolainen-sip-xmpp-coex-reqs-02.txt has been successfully submitted by Simo Veikkolainen and posted to the IETF repository.

Filename:	 draft-veikkolainen-sip-xmpp-coex-reqs
Revision:	 02
Title:		 Requirements and Use Cases for Combining SIP Based Real-time Media Sessions With XMPP Based Instant Messaging and Presence Service.
Creation_date:	 2011-01-26
WG ID:		 Independent Submission
Number_of_pages: 8

Abstract:
This memo defines use cases and requirements for combining Session
Initiation Protocol (SIP) based real-time media sessions with
Extensible Messaging and Presence Protocol (XMPP) based instant
messaging and presence services in a seamless manner.

The IETF Secretariat.

---

From: "Elwell, John" <[email-masked]>
Date: Thu, 27 Jan 2011 11:08:39 +0100

The requirements look reasonable. I would like to see some solution proposals, to help gauge whether the requirements are reasonable and sufficient.

Just a few minor comments:
1. "Offering overlapping services (e.g.
   presence) via both SIP and XMPP is out of scope of this document."
The term "overlapping" is not entirely clear on its own. Perhaps it might be better to say:
"Offering the same service (e.g., presence) via both SIP and XMPP....". 

2. "We assume that the user initially only needs to know the contact
   address of the other user in one protocol space.  The contact address
   for the other protocol must be learned by some means."
The second sentence doesn't make it clear that this discovery is within the scope of SIXPAC. I would suggest:
"Discovering the contact address for the other protocol is within the scope of this work."

3. "When
   an integrated endpoint communicates with a separated endpoint, normal
   SIP and XMPP procedures apply and no extensions defined in this memo
   are used."
In fact the integrated endpoint might attempt to use SIXPAC extensions, but would fall back to using basic SIP/XMPP. Also "this memo" does not define extensions, only requirements.
I would suggest:
"When an integrated endpoint communicates with a separated endpoint, they should fall back to using normal SIP and XMPP procedures."

4. " A user who has obtained another user's SIP URI is able to discover
      the other user's XMPP URI so that she can send the other user XMPP
      IM or subscribe to the other user's presence, or just populate her
      address book for futher use.  The user is able to do this without
      bothering the other user, provided the other user has pre-
      authorized the operation."
Should this be a 4th bullet, rather than an ordinary paragraph extending the 3rd bullet?

5. "REQ-4:  It must be possible for a user, who only knows another user's
           SIP URI, to learn the other user's XMPP URI."
Is there a particular reason this is asymmetrical? Should there also be a requirement for a user who knows another user's XMPP URI to learn that user's SIP URI?

John

> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of 
> [email-masked]
> Sent: 26 January 2011 20:20
> To: [email-masked]
> Subject: [sixpac] FW: New Version Notification for 
> draft-veikkolainen-sip-xmpp-coex-reqs-02
> 
> I have just uploaded a new version of 
> draft-veikkolainen-sip-xmpp-coex-reqs, which can be found at 
> http://www.ietf.org/internet-drafts/draft-veikkolainen-sip-xmp
> p-coex-reqs-02.txt 
> 
> In REQ-1: "SIP contact" changed to "SIP address"
> 
> In REQ-3: "It must be possible to include SIP real-time media 
> related contact and status in XMPP presence information." 
> changed to "It must be possible to include SIP address and 
> status information in XMPP presence."
> 
> And a couple of typos.
> 
> One further comment made by Peter might merit a bit more 
> discussion, namely saying something about cases where two SIP 
> devices are registered to the same AOR and two XMPP clients 
> are logged in. This is related to the discussion we had an 
> correlation, and whether or not it should be mentioned in the 
> charter or not. 
> 
> Also, please take a fresh look at the draft and express your 
> opinions on whether the approach in general makes sense, do 
> you agree with the use cases and requirements, is something 
> missing etc.
> 
> Thanks
> Simo
> 
>  
> A new version of I-D, 
> draft-veikkolainen-sip-xmpp-coex-reqs-02.txt has been 
> successfully submitted by Simo Veikkolainen and posted to the 
> IETF repository.
> 
> Title:		 Requirements and Use Cases for 
> Combining SIP Based Real-time Media Sessions With XMPP Based 
> Instant Messaging and Presence Service.
> _______________________________________________
> sixpac mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/sixpac
>

---

From: <[email-masked]>
Date: Fri, 28 Jan 2011 07:30:33 +0000

Thanks for the comments John! See below.

> From: ext Elwell, John [mailto:[email-masked]]
> Sent: 27 January, 2011 12:09
> To: Veikkolainen Simo (Nokia-MS/Helsinki); [email-masked]
> Subject: RE: [sixpac] FW: New Version Notification for draft-
> veikkolainen-sip-xmpp-coex-reqs-02
> 
> The requirements look reasonable. I would like to see some solution
> proposals, to help gauge whether the requirements are reasonable and
> sufficient.
> 

Changed.
 
> "Discovering the contact address for the other protocol is within the

Changed.
 
> In fact the integrated endpoint might attempt to use SIXPAC extensions,
> but would fall back to using basic SIP/XMPP. Also "this memo" does not
> define extensions, only requirements.
> I would suggest:
> "When an integrated endpoint communicates with a separated endpoint,
> they should fall back to using normal SIP and XMPP procedures."

Agree your text captures the point better. Now looking at the text, I'm not sure the "integrated" vs. "separated" endpoint was a very good choice. Might need to think of a better alternative.

> extending the 3rd bullet?

Changed.

> Is there a particular reason this is asymmetrical? Should there also be
> a requirement for a user who knows another user's XMPP URI to learn
> that user's SIP URI?

You're right, probably there is no reason for this to be asymmetrical. Added simply "and vice versa." to this requirement.

Simo