Subject: [Simple] Inter-domain Requirements for SIMPLE

From: "Orit Levin" <[email-masked]>
Date: Mon, 23 Feb 2004 15:33:32 -0800

Guys!
We have submitted a requirements document for secure and efficient
transfer of presence information over inter-domain links.
Please, take a look at our thoughts and suggestions:
 
http://www.ietf.org/internet-drafts/draft-levin-simple-interdomain-reqs-
00.txt
<http://www.ietf.org/internet-drafts/draft-levin-simple-interdomain-reqs
-00.txt> 
 
We look forward to your feedbacks on how we can enhance SIMPLE to
support these directions.
 
Thanks,
Orit.

---

From: "Orit Levin" <[email-masked]>
Date: Wed, 25 Feb 2004 22:58:13 -0800

This requirement attempts to say:

A potential watcher asks a presentity to grant access to presentity's
presence information, but the watcher (or more precisely, its PS) is not
interested in the presence information being pushed on individual basis
from this point on. In other words, it can be implemented by just adding
the watcher to presentity's ACL. Or in case of groups, adding the
requesting watcher to a specific group.

Orit.

-----Original Message-----
From: Robert Sparks [mailto:[email-masked]] 
Sent: Wednesday, February 25, 2004 8:48 AM
To: Orit Levin
Cc: IETF SIMPLE WG; Avshalom Houri
Subject: Re: [Simple] Inter-domain Requirements for SIMPLE

Orit, Avshalom -

Thanks for submitting this draft. You've captured some
important thoughts around deploying presence systems that
deserve attention. I particularly look forward to the
discussions we'll have around section 7.3 (Grouping of
Watchers for SHARING of Presence Info).

One quick question: I don't understand what you're looking
for with the first requirement of 7.1:

   o  Presence access: It MUST be possible to request continuous
      access to the status of a remote presentity without
      "subscribing" to it.

Could you explain this a little more?

RjS

> support these directions.

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

---

From: "Orit Levin" <[email-masked]>
Date: Thu, 26 Feb 2004 15:00:30 -0800

The connection between the watcher (the real end user) to the PS of the
presentity can be comprised of two logical hops.
The access hop (between the watcher and its PS) is using SUBSCRIBE as is
but the PS actually terminates the SUBSCRIBE dialog.
The interdomain hop (between the PSs) needs to use extended/modified
SIMPLE mechanisms (pending requirements validity).
 
I hope it clarifies one of the possible "architectures" to achieve the
optimizations.
Orit.

________________________________

From: Alex Audu [mailto:[email-masked]] 
Sent: Thursday, February 26, 2004 8:22 AM
To: Orit Levin
Cc: Robert Sparks; IETF SIMPLE WG; Avshalom Houri
Subject: Re: [Simple] Inter-domain Requirements for SIMPLE

Orit,

This seems like a mechanism to optimize information trasnfer between a
watcher's PS and 
the remote PS containing the presesnce information of interest.  But the
requirement is 
specifying the possibility of "requesting" access to information
"without subscribing " to it.
The common understanding in SIMPLE is you can't request for presence
information without
subscribing to the presentity.   If you request for it, you must have
subscribed to it. But you
don't want to be  transfering information to an endpoint that didn't
subscribe to that information
just because you want to optimize bandwidth utilization or something
like that.  Or am I missing
something?

Regards,
Alex.

Orit Levin wrote:

	A potential watcher asks a presentity to grant access to
presentity's
	presence information, but the watcher (or more precisely, its
PS) is not
	interested in the presence information being pushed on
individual basis
	from this point on. In other words, it can be implemented by
just adding
	the watcher to presentity's ACL. Or in case of groups, adding
the
	requesting watcher to a specific group.
	
	Orit.
	
	-----Original Message-----
	From: Robert Sparks [mailto:[email-masked]] 
	Sent: Wednesday, February 25, 2004 8:48 AM
	To: Orit Levin
	Cc: IETF SIMPLE WG; Avshalom Houri
	Subject: Re: [Simple] Inter-domain Requirements for SIMPLE
	
	Orit, Avshalom -

	

	RjS

		Guys!
		We have submitted a requirements document for secure and
efficient
		transfer of presence information over inter-domain
links.
		Please, take a look at our thoughts and suggestions:

		 
		We look forward to your feedbacks on how we can enhance
SIMPLE to
		support these directions.
		 
		Thanks,
		Orit.

---

From: "Orit Levin" <[email-masked]>
Date: Thu, 26 Feb 2004 15:00:30 -0800

Orit,

Regards,
Alex.

Orit Levin wrote:

	
	Orit.
	
	-----Original Message-----
	From: Robert Sparks [mailto:[email-masked]] 
	Sent: Wednesday, February 25, 2004 8:48 AM
	To: Orit Levin
	Cc: IETF SIMPLE WG; Avshalom Houri
	Subject: Re: [Simple] Inter-domain Requirements for SIMPLE
	
	Orit, Avshalom -

	

	RjS

		Guys!

		 
		 
		Thanks,
		Orit.

---

From: Adam Roach <[email-masked]>
Date: Fri, 27 Feb 2004 21:36:23 -0600

I think you would get the information that Viklas
is describing using the conference event package.

[see draft-ietf-sipping-conference-package-03.txt]

/a

> From: Ted Hardie [mailto:[email-masked]]
> Sent: Friday, February 27, 2004 10:13
> To: Vikas Tandon; [email-masked]; 'Orit Levin'
> Cc: 'Robert Sparks'; 'IETF SIMPLE WG'; 'Avshalom Houri'
> Subject: RE: [Simple] Inter-domain Requirements for SIMPLE
> 
> 
> At 12:50 PM +0530 02/27/2004, Vikas Tandon wrote:
> >Hi Hardie/ Group,
> >I'm taking  a case where in A &C are in a group chat (like 
> the millions
> >of rooms on any commercial chat service today), now both of 
> them can see
> >each other (say in the sidebar) as available but are not 
> subscribed to
> >each other.
> >I might be talking non-SIMPLE but this can be a user case as per my
> >understanding, would appreciate correction if my line of thinking is
> >deviating from scope of SIMPLE.
> >Regards,
> >Vikas
> 
> Ah, I see.  In some cases you can even have a private sidebar 
> conversation
> using something like "[email-masked]/nickname"
> without having any other contact data for them.  Thanks for the
> clarification.
> 
> I don't personally think providing such a facility would be outside 
> the scope of the
> group at first reading (falling pretty much into the group 
> chat scope),
> but I would be interested to hear the group's thoughts on 
> whether it would
> be a first-pass piece of functionality.
> 			regards,
> 				Ted
>

---

From: Adam Roach <[email-masked]>
Date: Fri, 27 Feb 2004 21:36:23 -0600

/a

---

From: [email-masked]
Date: Sun, 29 Feb 2004 15:16:38 +0200

Hi Orit and Avshalom,
 
I have several questions on this draft:
 
- The draft seems to propose an architecture, where presence SUBSCRIBEs from one domain to another do not simply get routed via a SIP proxy network, but somehow traverse a "presence server" already in the originating domain. This "presence server" acts as some sort of B2BUA. Is this correct?
- I undertood that one motivation for this would be somehow to aggregate the presence subscriptions between the domains so that certain presentity's presence needs only subscribed once from each domain, even if there would be more than one subscriber in this domain. Is this the intention? If yes, the next question would be how to handle authorization, since the presentity might want to reveal his presence in a different way to different watchers, even if they were in the same domain.
- Some security requirements indeed discuss about PS-to-PS security. Would inter-domain security not be best handled generally between SIP proxies (using TLS or VPNs), not specifically for presence application?
- Robert Sparks already asked about this requirement:
o Presence access: It MUST be possible to request continuous access to the status of a remote presentity without "subscribing" to it.

I saw your answer but I still want to clarify. Is this same as sending a request: "Please add me to your presence allow list", so that the subscription would be allowed in the future when needed?

In general I support the idea of groups for authorizations etc. I guess this is addressed in the XCAP presence authorization policy rule work. However in there I find it unfortunate that referencing to external resource lists is now disallowed. I know this was done for some GEOPRIV considerations. However, within controlled domains, such as within an enterprise or a single operator network, they should be allowed, so that user could use his groups in general-purpose fashion. Although I'm not sure if this kind of thing was in the scope of your draft at all.

Markus 

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]On Behalf Of ext Orit Levin
Sent: 24 February, 2004 01:34
To: IETF SIMPLE WG
Cc: Avshalom Houri
Subject: [Simple] Inter-domain Requirements for SIMPLE

Guys!
We have submitted a requirements document for secure and efficient transfer of presence information over inter-domain links.
Please, take a look at our thoughts and suggestions:
 
 <http://www.ietf.org/internet-drafts/draft-levin-simple-interdomain-reqs-00.txt> http://www.ietf.org/internet-drafts/draft-levin-simple-interdomain-reqs-00.txt
 
We look forward to your feedbacks on how we can enhance SIMPLE to support these directions.
 
Thanks,
Orit.

---

From: [email-masked]
Date: Sun, 29 Feb 2004 15:16:38 +0200

Hi Orit and Avshalom,

Markus 

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]On Behalf Of ext Orit Levin
Sent: 24 February, 2004 01:34
To: IETF SIMPLE WG
Cc: Avshalom Houri
Subject: [Simple] Inter-domain Requirements for SIMPLE

Guys!

 
Thanks,
Orit.

---

From: "Orit Levin" <[email-masked]>
Date: Sun, 29 Feb 2004 16:09:16 -0800

Inline.

Orit.

-----Original Message-----
From: Jonathan Rosenberg [mailto:[email-masked]] 
Sent: Saturday, February 28, 2004 7:59 PM
To: Orit Levin
Cc: IETF SIMPLE WG; Avshalom Houri
Subject: Re: [Simple] Inter-domain Requirements for SIMPLE

Orit,

First, thanks for working on these. This is a topic that many of us have 
been thinking about for some time, and as our current batch of work is 
finishing up, I think now is a good time to start visiting this topic 
seriously.

OL: Thanks for supporting the effort. :-)

I think many of the requirements are met by existing SIP/SIMPLE 
capabilities, if you treat PS-A and PS-B as "state agents", in the sense 
that they would terminate presence subscriptions from users in their own 
domains, and generate their own subscriptions to the peer servers to 
obtain presence information. There are some naming and identification 
issues associated with that, which we can deal with when it comes time 
to mechnanism. But, with that model, many of your requirements are met.

OL: I agree that this is the most reasonable model. We wanted to get the support on this exact point from the WG before diving into the mechanism.

I didnt understand a few of them, however. In particular:

> User-to-User Requirements
>    o  Explicit Domain Identifier: It MUST be possible to unambiguously
>       determine which domain the user belongs to from the userÆs
>       identifier (without requiring complicated lookups).

I dont understand this. Doesnt the sip URI have this property?

OL: Yes, SIP does. We hope that non-SIP IM will be able to plug into this model as well and we want them to be aware of this assumption.

>    o  Meaningful User Identifier: The user name MUST be meaningful to
>       the end-users (e.g. not a random global identifier).

I dont think its our job to mandate the format or conventions of names 
allocated in a domain. I.e., we cannot force domains to allocate user 
parts of the form [email-masked]. If example.com wants 
to assign me [email-masked], that's their business.

We do have to be able to carry display names suitable for human 
consumption, which is met by SIP already.

OL: I agree. MUST is too strong here.

Regarding these:

>  A user to all users in other domain: A user in one domain MUST be
>       able to allow and disallow its presence visibility to all users in
>       a specific other domain.
>    o  Per user granularity: A user in one domain MUST be able to allow
>       and disallow its presence visibility to a specific user in a
>       remote domain.
>    o  Asymmetric user relationships: Users in different domains MUST be
>       able to allow or disallow their presence visibility to each other
>       independently for each direction.

they are already met by the presence rules XML format that we have been 
working on for some time, AFAIK.

OL: Regarding the above: The reason for stating these requirements was to ensure that after the proposed optimizations on the inter-domain interface are implemented, we don't loose these already existing properties. We will add clarification along these lines.

Regarding these:

>  o  Peer-to-peer authentication in federation scenario: Users MAY be
>       able to authenticate each other.
>    o  Peer-to-peer authentication in open public interconnection
>       scenario:  Users SHOULD be able to authenticate each other.

Are you talking about authenticating subscriptions? Notifications? 
Presence documents?

OL: I would say - nice to have all of the above, but it may be impossible to achieve except for the presence documents. The rest will most probably end up hop-by-hop.

Generally, I think the main part of the problem here, in terms of whats 
not currently solved, are these "optimizations" for reducing traffic 
between domains.

OL: Yes, I agree with this observation. (Although, the rest needs to be clarified for out-of-box interoperability.)

Thanks,
Jonathan R.

Orit Levin wrote:

> /http://www.ietf.org/internet-drafts/draft-levin-simple-interdomain-reqs-00.txt/
>  

-- 
Jonathan D. Rosenberg, Ph.D.                600 Lanidex Plaza
Chief Technology Officer                    Parsippany, NJ 07054-2711
dynamicsoft
[email-masked]                     FAX:   (973) 952-5050
http://www.jdrosen.net                      PHONE: (973) 952-5000
http://www.dynamicsoft.com

---

From: "Orit Levin" <[email-masked]>
Date: Sun, 29 Feb 2004 16:09:15 -0800

The requirement is for the case where a subscription to a group exists
(i.e. the present information is available at the watchers' domain
already). Upon getting the permission, a new watcher is added to the
group and the presence information is delivered to it from its PS
locally.

Hope it clarifies the case,
Orit.

-----Original Message-----
From: Jonathan Rosenberg [mailto:[email-masked]] 
Sent: Saturday, February 28, 2004 7:11 AM
To: Orit Levin
Cc: Robert Sparks; IETF SIMPLE WG; Avshalom Houri
Subject: Re: [Simple] Inter-domain Requirements for SIMPLE

Orit,

I am still confused on this requirement.

It sounds like what you want is for the watcher to find out if he has 
permission to subscribe or fetch presence from the presentity, without 
actually subscribing or fetching? In other words, it would be a request 
from the watcher to the presentity to ask the presentity to set an 
authorization policy for the watcher, in absence of any specific 
subscription. Is that right?

If so, what is the motivating use case here?

THanks,
Jonathan R.

---

From: "Orit Levin" <[email-masked]>
Date: Sun, 29 Feb 2004 16:09:16 -0800

Inline.

Orit.

-----Original Message-----
From: Jonathan Rosenberg [mailto:[email-masked]] 
Sent: Saturday, February 28, 2004 7:59 PM
To: Orit Levin
Cc: IETF SIMPLE WG; Avshalom Houri
Subject: Re: [Simple] Inter-domain Requirements for SIMPLE

Orit,

Thanks,
Jonathan R.