Re: [humanresolv] Tentative problem statement

"Pars Mutaf" <pars.mutaf@gmail.com> Wed, 31 October 2007 16:41 UTC

Return-path: <humanresolvers-bounces@ietf.org>
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1InGdC-0006Zy-Ua; Wed, 31 Oct 2007 12:41:26 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1InGdB-0006WP-E1 for humanresolvers@ietf.org; Wed, 31 Oct 2007 12:41:25 -0400
Received: from wx-out-0506.google.com ([66.249.82.232]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1InGd0-0006xh-53 for humanresolvers@ietf.org; Wed, 31 Oct 2007 12:41:21 -0400
Received: by wx-out-0506.google.com with SMTP id s8so185328wxc for <humanresolvers@ietf.org>; Wed, 31 Oct 2007 09:40:28 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:references; bh=cIbyUvB75KN8pXA3STi/fwssT/lASWgkB/zxPKF48Bo=; b=NF1xL4cf8ex5P7tI8ZWbujIz6wi94OG4NU/RFYcLzwbFcXmDBweeCk3OE25ppg4Kd/xam1ykYOs5NDxEl++BbTuhT5ps1MoQHWqsMlEmw1yk6LvxmdIgnj/0YjzJV1/cwsJ7X/1SQx7jn3PgffPkAsH6brQmSD+Dzu5rl0Ady/g=
DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:references; b=PVt8MkB5ttMwRSTSpOLNHv0Ego6/LHokA2aheOP+rKiC99tNqCB8vNbI8EpOEpKw3aizYF6nTTh4QuW9kazN2KNJQxix7bwfRSXN4BMLvBjegpERZ4gwgvHUgdI9iCAanI4u7khQ7g56/qrgvz0l6dAT9Wx/yo3f5vBX/5A64dY=
Received: by 10.70.21.4 with SMTP id 4mr14839786wxu.1193848828507; Wed, 31 Oct 2007 09:40:28 -0700 (PDT)
Received: by 10.70.117.20 with HTTP; Wed, 31 Oct 2007 09:40:28 -0700 (PDT)
Message-ID: <18a603a60710310940p7c7226edjbc9022906796bf81@mail.gmail.com>
Date: Wed, 31 Oct 2007 17:40:28 +0100
From: "Pars Mutaf" <pars.mutaf@gmail.com>
To: "Vanderveen, Michaela" <mvanderv@qualcomm.com>
Subject: Re: [humanresolv] Tentative problem statement
In-Reply-To: <4B3FE0E0367A2F4EB75EE82BC0B21EFCE23A5E@NAEX15.na.qualcomm.com>
MIME-Version: 1.0
References: <18a603a60710260508h281a126bjda7179c2b896448b@mail.gmail.com> <47220ECD.9020204@gmail.com> <18a603a60710290322n151e0650hd9f405957f67c169@mail.gmail.com> <18a603a60710301109w17a1de6k3d5984cb08a6cc0b@mail.gmail.com> <4B3FE0E0367A2F4EB75EE82BC0B21EFCE23A41@NAEX15.na.qualcomm.com> <18a603a60710301226r42c3c89bs6d406eaec4d9ad39@mail.gmail.com> <4B3FE0E0367A2F4EB75EE82BC0B21EFCE23A5E@NAEX15.na.qualcomm.com>
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 92df29fa99cf13e554b84c8374345c17
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
X-Content-Filtered-By: Mailman/MimeDel 2.1.5
Cc: humanresolvers@ietf.org
X-BeenThere: humanresolvers@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Pairing cellular hosts <humanresolvers.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/humanresolvers>, <mailto:humanresolvers-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/humanresolvers>
List-Post: <mailto:humanresolvers@ietf.org>
List-Help: <mailto:humanresolvers-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/humanresolvers>, <mailto:humanresolvers-request@ietf.org?subject=subscribe>
Errors-To: humanresolvers-bounces@ietf.org

On 10/30/07, Vanderveen, Michaela <mvanderv@qualcomm.com > wrote:
>
>
> Specifically, users should be able to turn
> undiscoverable to a particular user with whom they already shared SIP
> URIs, phone nrs, etc. Such as example is the selective user blocking and
> unblocking feature of popular Instant Messaging apps. Changing phone
> numbers is cumbersome, and made even more difficult if one wishes to
> re-instate that user.
>
> I'm not sure to understand this sounds like a requirement to me?
>
> MCV>> This is "IP host de-pairing" if you wish. Not necessarily a
> requirement, but desirable IMO. And of course we don't mean just putting an
> expiration time on shared credentials. Ideally hosts should be able to
> disable the pairing with other hosts immediately upon user action. This
> translates in not being reachable by this one other agent at the old SIP
> URI, for example.



OK I see. Maybe it is also noteworthy that SIP is probably not the only
protocol that will be used between paired hosts.
Some folks are interested in "mobile web servers". They also explain why
this is a good idea:

http://wiki.opensource.nokia.com/projects/Mobile_Web_Server

(note that in our case we don't need a special infrastructure, Mobile IPv6
takes care of routing)

Using IP pairing:
-Alice and Bob share their SIP URIs.
-Alice also offers an Web URL to allowing Bob access her photos stored in
her phone for example.

All exchanges are secured by IPsec.

Bob is authorized to call Alice. He can also look at photos taken by Alice
using a standard web
browser. Later Alice can cancel the HTML access to her phone. Bob can still
make a SIP call, but
no longer look at photos or other files.

What do you think?

pars
_______________________________________________
humanresolvers mailing list
humanresolvers@ietf.org
https://www1.ietf.org/mailman/listinfo/humanresolvers