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: Robert Sparks <[email-masked]>
Date: Wed, 25 Feb 2004 10:47:37 -0600

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

On Mon, 2004-02-23 at 17:33, Orit Levin wrote:
> http://www.ietf.org/internet-drafts/draft-levin-simple-interdomain-reqs-00.txt
>  

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

---

From: Robert Sparks <[email-masked]>
Date: Wed, 25 Feb 2004 10:47:37 -0600

Orit, Avshalom -

RjS

---

From: Jonathan Rosenberg <[email-masked]>
Date: Sat, 28 Feb 2004 22:58:44 -0500

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.

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.

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?

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

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.

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?

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.

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: Jonathan Rosenberg <[email-masked]>
Date: Sat, 28 Feb 2004 22:58:44 -0500

Orit,

Thanks,
Jonathan R.