Subject: RE: [Speermint] Fw: I-DACTION:draft-houri-speermint-usecase-presence-00.txt

From: "Jean-Francois Mule" <[email-masked]>
Date: Thu, 19 Oct 2006 10:32:56 -0600

Avshalom,

   Thank you for writing this draft.

   In your draft, there are a few examples that just point to different types of session descriptors in the session establishment (page mode, MSRP-based session): in those examples, can you point to specific requirements that would be new or different than for the ones for voip?

   There are other examples however (like 3.1.) which provide new requirements: users from different domains subscribing to each other's presence info.
Could you provide more specific examples of this kind of use cases using common presence/simple/xmpp terminology and well-known URI schemes for presence? 
The reason I'm asking is that I'm looking at this wanting to capture beyond "VoIP" requirements and it is hard to figure out what you think is missing or should be done to allow inter-domain presence info retrieval (if anything).

--- proposal (with poor wording):
Based on a well-known URI (for e.g. pres:), it SHOULD be possible to determine whether the domain servicing the URI (VSP/ASP) allows session peering, and if it does, it SHOULD be possible to locate the domain's policy and signaling functions?
i.e.
Given that I know Bob's presence URI (e.g. pres:[email-masked]?), my client application should be able to query example.com with my own domain's credentials and figure out whether example.com allows me to see/retrieve Bob's presence, and if so, where I need to subscribe to get it?

Excuse my lack of knowledge here but:
	- is there an equivalent of RFC3263 to locate presence servers? 
	- are things like sip identity in play in here: what are the holes?

Jean-Francois.
________________________________________
From: Avshalom Houri [mailto:[email-masked]] 
Sent: Tuesday, October 17, 2006 6:26 AM
To: [email-masked]
Subject: [Speermint] Fw: I-DACTION:draft-houri-speermint-usecase-presence-00.txt

FYI. Title should have been "Presence and IM use cases" 

--Avshalom
Real Time Collaboration Standards

----- Forwarded by Avshalom Houri/Haifa/IBM on 17/10/2006 14:22 ----- 
[email-masked] 
17/10/2006 00:50 
Please respond to
[email-masked]

To
[email-masked] 
cc

Subject
I-D ACTION:draft-houri-speermint-usecase-presence-00.txt

A New Internet-Draft is available from the on-line Internet-Drafts 
directories.

                Title                                  : RTC Provisioning Requirements
                Author(s)                 : A. Houri, et al.
                Filename                 : draft-houri-speermint-usecase-presence-00.txt
                Pages                                  : 12
                Date                                  : 2006-10-16
                
  The document describes several use cases for peering between two or
  more communities that provide real time communications services and
  presence and IM in particular.  The communities create a peering
  relationship between themselves thus enabling their users to
  collaborate with users on other communities.  The target of the
  document is to help understanding the requirements for peering
  between domains with regard to real time services

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-houri-speermint-usecase-presence-00.txt

To remove yourself from the I-D Announcement list, send a message to 
[email-masked] with the word unsubscribe in the body of 
the message. 
You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce 
to change your subscription settings.

Internet-Drafts are also available by anonymous FTP. Login with the 
username "anonymous" and a password of your e-mail address. After 
logging in, type "cd internet-drafts" and then 
"get draft-houri-speermint-usecase-presence-00.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html 
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

Internet-Drafts can also be obtained by e-mail.

Send a message to:
                [email-masked].
In the body type:
                "FILE /internet-drafts/draft-houri-speermint-usecase-presence-00.txt".
                
NOTE:                 The mail server at ietf.org can return the document in
                MIME-encoded form by using the "mpack" utility.  To use this
                feature, insert the command "ENCODING mime" before the "FILE"
                command.  To decode the response(s), you will need "munpack" or
                a MIME-compliant mail reader.  Different MIME-compliant mail readers
                exhibit different behavior, especially when dealing with
                "multipart" MIME messages (i.e. documents which have been split
                up into multiple messages), so check your local documentation on
                how to manipulate these messages.

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.
ftp://[email-masked]/internet-drafts/draft-houri-speermint-usecase-presence-00.txt_______________________________________________
I-D-Announce mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/i-d-announce

_______________________________________________
Speermint mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/speermint

---

From: Avshalom Houri <[email-masked]>
Date: Tue, 24 Oct 2006 20:27:06 +0200

Jean-Francois,,

Sorry for the late answer was busy with another draft for SIMPLE (problem 
statement)

I think that you are right and other then some sessions details as MSRP 
vs. page-mode, rate
of re-subscribes that is expected etc. the requirements for VOIP should 
enable also presence
and IM peering given that there will be enough flexibility to define 
different parameters for the session.

For name resolution I do not see much difference between VOIP systems and 
presence/IM systems.
RFC 3263 and RFC 3861 that you mention in another note will be used.

I am seeing the presence and IM operations between domains done on the 
domain level and not on the client level. Doing this on the client level 
will require additional mechanisms to make sure that the client was 
authorized by the domain it claims that is coming from. There may be also 
a need for protocol translations that are better done in the GW level of 
the domain of the client and not in the client to the other domain basis.

There is an emerging issue that may be quite different for presence and 
not relevant for VOIP. Assume that we have a domain that subscribes to 
many users on other domains. In the many users that the domain is 
subscribing to there are many duplicates and actually the other domain can 
subscribe to e.g. 2000 users instead of 10000 users. The issue that 
prevents doing this optimizations is privacy. The domain that receives 
that subscriptions need to know exactly which user is subscribing. On the 
other hand being able to do consolidates subscriptions may save a LOT in 
inter-domain traffic for presence. I assume that after the very heated 
debate that I am almost sure will happen in SIMPLE we may need a new 
requirement here on whether consolidates subscriptions are possible and 
how.

--Avshalom

"Jean-Francois Mule" <[email-masked]> 
19/10/2006 18:32

To
Avshalom Houri/Haifa/IBM@IBMIL
cc
<[email-masked]>
Subject
RE: [Speermint] Fw: 
I-DACTION:draft-houri-speermint-usecase-presence-00.txt

Avshalom,

   In your draft, there are a few examples that just point to different 
types of session descriptors in the session establishment (page mode, 
MSRP-based session): in those examples, can you point to specific 
requirements that would be new or different than for the ones for voip?

   There are other examples however (like 3.1.) which provide new 
requirements: users from different domains subscribing to each other's 
presence info.
Could you provide more specific examples of this kind of use cases using 
common presence/simple/xmpp terminology and well-known URI schemes for 
presence? 
The reason I'm asking is that I'm looking at this wanting to capture 
beyond "VoIP" requirements and it is hard to figure out what you think is 
missing or should be done to allow inter-domain presence info retrieval 
(if anything).

--- proposal (with poor wording):
Based on a well-known URI (for e.g. pres:), it SHOULD be possible to 
determine whether the domain servicing the URI (VSP/ASP) allows session 
peering, and if it does, it SHOULD be possible to locate the domain's 
policy and signaling functions?
i.e.
Given that I know Bob's presence URI (e.g. pres:[email-masked]?), my 
client application should be able to query example.com with my own 
domain's credentials and figure out whether example.com allows me to 
see/retrieve Bob's presence, and if so, where I need to subscribe to get 
it?

Excuse my lack of knowledge here but:
                 - is there an equivalent of RFC3263 to locate presence 
servers? 
                 - are things like sip identity in play in here: what are 
the holes?

Jean-Francois.
________________________________________
From: Avshalom Houri [mailto:[email-masked]] 
Sent: Tuesday, October 17, 2006 6:26 AM
To: [email-masked]
Subject: [Speermint] Fw: 
I-DACTION:draft-houri-speermint-usecase-presence-00.txt

--Avshalom

----- Forwarded by Avshalom Houri/Haifa/IBM on 17/10/2006 14:22 ----- 
[email-masked] 
17/10/2006 00:50 
Please respond to
[email-masked]

To
[email-masked] 
cc

Subject

                Title                                  : RTC Provisioning 
Requirements
                Author(s)                 : A. Houri, et al.
                Filename                 : 
draft-houri-speermint-usecase-presence-00.txt
                Pages                                  : 12
                Date                                  : 2006-10-16

Send a message to:
                [email-masked].
In the body type:
                "FILE 
/internet-drafts/draft-houri-speermint-usecase-presence-00.txt".
                
NOTE:                 The mail server at ietf.org can return the document 
in
                MIME-encoded form by using the "mpack" utility.  To use 
this
                feature, insert the command "ENCODING mime" before the 
"FILE"
                command.  To decode the response(s), you will need 
"munpack" or
                a MIME-compliant mail reader.  Different MIME-compliant 
mail readers
                exhibit different behavior, especially when dealing with
                "multipart" MIME messages (i.e. documents which have been 
split
                up into multiple messages), so check your local 
documentation on
                how to manipulate these messages.