Subject: FW: [Sipping] draft-schulzrinne-sipping-id-relationships

From: "MARJOU Xavier RD-MAPS-LAN" <[email-masked]>
Date: Fri, 5 Aug 2005 19:06:04 +0200

-----Original Message-----
From: MARJOU Xavier RD-MAPS-LAN 
Sent: vendredi 5 août 2005 19:05
To: 'Henning Schulzrinne'
Subject: RE: [Sipping] draft-schulzrinne-sipping-id-relationships

I think the draft mandates wise recommendations.

However, I come back to the suggestion to use Presence, in order not to discard it too quickly.

I think that the Presence framework can be used for:
A - getting presence information about a buddy B - retrieving all the various communication URI schemes a buddy can have.

"B" is a hidden feature of the Presence document, provided that various aliases can be used to fecth the document of a presentity. 

For Presence use-cases, having "A" and "B" is a must. However for many other use-cases, having only "B" is enough. These use-cases typically "only" need to retrieve the different SIP, TEL, or email addresses associated to a given buddy, but do not need presence data (like "status", "sphere") associated to him.

I guess this needs more investigation within the SIMPLE WG. For example, to study whether a filter could enable to only retrieve those "B" data (ie: URIs), and not those specific to Presence.

Xavier

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Henning Schulzrinne
Sent: vendredi 5 août 2005 10:30
To: sipping
Subject: [Sipping] draft-schulzrinne-sipping-id-relationships

One additional remark on the spam issue and the draft in general:

It was suggested that one would use presence for admitting IMs and calls. While this is useful for some cases, I don't think this is a replacement in all cases:

- My address book of people that I have sent email to (and would be willing to receive calls from) contains several thousand addresses. I'm unlikely to subscribe to all of these or have all of these subscribe to me - I'm not interested in revealing my availability status to all of them in real time (and almost none of them would care, given that they may most likely never call me).

- There's the bootstrap problem: If somebody subscribes to me, how would I recognize them? Given no other context or other external "this is a good guy" cert, I'd look at their name and SIP AOR. Since I haven't seen their SIP identifier, I'd likely say "oh, this is [email-masked]; that's the same alice that I have sent email to/received email from".

This equivalency is never perfect, but this is all about improving the odds, not perfection.

In a separate context, Hannes mentioned some general security multi-path techniques that use a variation of this idea. (There's a technical term for this that escapes me here.)

A number of people indicated support for this type of specification as being useful as a tool to convince local admins to "do the right thing". 
Apparently, some admins have pulled the "joe's VoIP contract has expired, so let me re-assign that ID [even though it's still a valid email address". Having a clue-by-four likely won't be a cure-all for these, but I've found that pointing to a neutral third party does carry weight with local admins.

I'd appreciate advice on how to proceed. There are probably at least three meta-issues:

- Is the information in the draft wrong or shouldn't be recommended?

- Should there be an RFC recommending them?

- If yes, is an individual+WG review draft a viable approach, given the low complexity of the draft?

Henning

_______________________________________________
Sipping mailing list  https://www1.ietf.org/mailman/listinfo/sipping
This list is for NEW development of the application of SIP Use [email-masked] for questions on current sip Use [email-masked] for new developments of core SIP

_______________________________________________
Sipping mailing list  https://www1.ietf.org/mailman/listinfo/sipping
This list is for NEW development of the application of SIP
Use [email-masked] for questions on current sip
Use [email-masked] for new developments of core SIP

---

From: Henning Schulzrinne <[email-masked]>
Date: Sat, 06 Aug 2005 17:57:59 -0400

I agree that you could use presence to only get the various addresses, 
with a bit of extra spec work (*), but the spam problem remains:

If I were to send you a SUBSCRIBE, even for this filtered information 
(just URLs), you wouldn't just hand it to me, since I might just as well 
be a spam address collection robot. You would manually recognize my 
email address, in all likelihood.

Another issue came up in the SIMPLE discussion on common policy: Without 
an equivalency across protocols (email is less important, but across 
multiple IM domains), having policy files gets very frustrating for 
users. Try explaining to a subscriber of a service that does 
multiprotocol IM/presence why they have to add each user several times 
to their "allowed to watch" file and why, each time the service adds a 
new protocol, they have to do it yet again. Not the kind of user 
experience I'd like to foist on users - particularly since there is no 
technical necessity to do that.

Obviously, today, most people have collections of email addresses, in 
various electronic and paper (businesscard) formats. Finding out a 
reasonable presence address to subscribe to has no good solution without 
the equivalency. Thus, finding an email address from a presence address 
is probably solvable; the converse is hard.

(For those of you who were in the IETF IAB plenary: this is indeed part 
of making the user experience less frustrating, on average.)

Henning

(*) I suspect our current SIMPLE policy draft would already allow 
including only addresses, but I don't think it allows excluding status 
information.

MARJOU Xavier RD-MAPS-LAN wrote:

> I think that the Presence framework can be used for: A - getting
> presence information about a buddy B - retrieving all the various
> communication URI schemes a buddy can have.
> 
> "B" is a hidden feature of the Presence document, provided that
> various aliases can be used to fecth the document of a presentity.
> 
> For Presence use-cases, having "A" and "B" is a must. However for
> many other use-cases, having only "B" is enough. These use-cases
> typically "only" need to retrieve the different SIP, TEL, or email
> addresses associated to a given buddy, but do not need presence data
> (like "status", "sphere") associated to him.
> 
> I guess this needs more investigation within the SIMPLE WG. For
> example, to study whether a filter could enable to only retrieve
> those "B" data (ie: URIs), and not those specific to Presence.
> 
> Xavier
>