From ldapext-bounces@ietf.org Mon Oct 01 09:45:46 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IcLYJ-00078G-Sp; Mon, 01 Oct 2007 09:43:15 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IcLYI-00070u-A7 for ldapext@ietf.org; Mon, 01 Oct 2007 09:43:14 -0400 Received: from nf-out-0910.google.com ([64.233.182.184]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IcLYB-0002EB-V2 for ldapext@ietf.org; Mon, 01 Oct 2007 09:43:14 -0400 Received: by nf-out-0910.google.com with SMTP id d21so2455642nfb for ; Mon, 01 Oct 2007 06:42:53 -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:mime-version:content-type; bh=Tqd2B7VL+B11NfibDKvptxNcRQ2AMCxdMSGUfe4dQ4o=; b=ktW6xLRXxYHHXY2+u7jpBgWfHCfmv+oMLRQmNfT8/87UkyQsbvXZ/byWGutY+SbdgLkVMFzDJY1bEIuc0yKdV6/XgvLF+h5EEdZArn0Y9hDlqsHIt4hKRWvSAki1kqhhGIZCPiZERq60W0mSBBeMqwtf0lsuirIYgyaXQ37+ImQ= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:to:subject:mime-version:content-type; b=Sa3LSQR3u8NK0aecqZ6Glf6zTKFxbp6mrJrL/f5TCtQntahXwoGnA+hkP2gXiCYUfOjcW7GGA6am97VpF+D2d0Y9m17doJ986EXDJG95rcMV8fkQqMDIfT6o+IR5gpvn33m1EytAzuFD2wzkLfEaWo0az2OcX75T2mDi5PWASGI= Received: by 10.78.157.19 with SMTP id f19mr6371860hue.1191246172358; Mon, 01 Oct 2007 06:42:52 -0700 (PDT) Received: by 10.70.22.4 with HTTP; Mon, 1 Oct 2007 06:42:52 -0700 (PDT) Message-ID: <18a603a60710010642u16753518sd71f3b291626aa54@mail.gmail.com> Date: Mon, 1 Oct 2007 15:42:52 +0200 From: "Pars Mutaf" To: ldapext@ietf.org MIME-Version: 1.0 X-Spam-Score: 0.0 (/) X-Scan-Signature: 825e642946eda55cd9bc654a36dab8c2 Subject: [ldapext] IETF solution for pairing cellular hosts X-BeenThere: ldapext@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: LDAP Extension Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0085660986==" Errors-To: ldapext-bounces@ietf.org --===============0085660986== Content-Type: multipart/alternative; boundary="----=_Part_7665_30429845.1191246172294" ------=_Part_7665_30429845.1191246172294 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline Interested folks are welcome to the following mailing list for an eventual working group. The idea has similarities with the phone number directory approach. Your contributions would be very much welcome (We are in the problem statement phase for the moment.) Regards, pars mutaf Pairing Cellular Hosts https://www1.ietf.org/mailman/listinfo/humanresolvers Currently there are two approaches for obtaining contact information for a target cell phone: (i) consulting a phonebook, (ii) manually exchanging phone numbers upon face-to-face user contact. Both approaches have their own limitations. The following is a new abstract solution, a third alternative, a protocol for "pairing" two cellular hosts: Model of operation 1. The querier user types the target user's "human name" (as if he were consulting a phonebook), or a pseudoynm. 2. The pairing request is forwarded to the target phone. 3. The query, along with the querier user's name, are displayed on the target phone's screen. 4. The target user approves the request in real-time by pushing on the YES button of the phone. 5. The two phones exchange their Mobile IPv6 home addresses, SIP URIs, and establish an IPsec security association (using IKEv2). The target user does not need to publish his/her private SIP URI and home address (as recommended in [1] in SIP context). Cell phone users do not publish their phone numbers today. The users do not need to manually exchange their SIP URIs and home addresses which are too long (an IPv6 address is 16 bytes long and random looking, a SIP URI can be very long e.g. up to 30 characters and even more with a random part for privacy). The protocol also works in the absence of user contact, for example when the target user's SIP URI is lost (loss of state, new phone), or this is the user's first phone, and hence his/her contact list is initially empty. Thousands of cell phones are sold everyday.. [1] Peterson, J., "A Privacy Mechanism for the Session Initiation Protocol", RFC3323, November 2002. ======================= Interested folks could you please subscribe to the mailing list created for this discussion: https://www1.ietf.org/mailman/listinfo/humanresolvers We already had some discussions on the IETF list recently. You may want to take a look at the archives for an introduction: http://www1.ietf.org/mail-archive/web/ietf/current/msg48129.html There is also a side discussion on CAPTCHAs: http://www1.ietf.org/mail-archive/web/ietf/current/msg48172.html ------=_Part_7665_30429845.1191246172294 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline Interested folks are welcome to the following mailing list
for an eventual working group.

The idea has similarities with the phone number directory
approach. Your contributions would be very much welcome
(We are in the problem statement phase for the moment.)

Regards,
pars mutaf


Pairing Cellular Hosts

https://www1.ietf.org/mailman/listinfo/humanresolvers

Currently there are two approaches for obtaining contact information for a
target cell phone: (i) consulting a phonebook, (ii) manually exchanging
phone numbers upon face-to-face user contact. Both approaches have
their own limitations.

The following is a new abstract solution, a third alternative, a protocol
for "pairing" two cellular hosts:

Model of operation

1. The querier user types the target user's "human name" (as if he were
   consulting a phonebook), or a pseudoynm.
2. The pairing request is forwarded to the target phone.
3. The query, along with the querier user's name, are displayed on the
   target phone's screen.
4. The target user approves the request in real-time by pushing on the YES
   button of the phone.
5. The two phones exchange their Mobile IPv6 home addresses, SIP URIs, and
   establish an IPsec security association (using IKEv2).

The target user does not need to publish his/her private SIP URI and home
address (as recommended in [1] in SIP context). Cell phone users do not
publish their phone numbers today.

The users do not need to manually exchange their SIP URIs and home
addresses which are too long (an IPv6 address is 16 bytes long and random
looking, a SIP URI can be very long e.g. up to 30 characters and even more
with a random part for privacy).

The protocol also works in the absence of user contact, for example when
the target user's SIP URI is lost (loss of state, new phone), or this is
the user's first phone, and hence his/her contact list is initially empty.
Thousands of cell phones are sold everyday..

[1] Peterson, J., "A Privacy Mechanism for the Session Initiation Protocol",
    RFC3323, November 2002.


=======================

Interested folks could you please subscribe to the mailing list created
for this discussion:

https://www1.ietf.org/mailman/listinfo/humanresolvers



We already had some discussions on the IETF list recently.
You may want to take a look at the archives for an introduction:

http://www1.ietf.org/mail-archive/web/ietf/current/msg48129.html

There is also a side discussion on CAPTCHAs:

http://www1.ietf.org/mail-archive/web/ietf/current/msg48172.html
------=_Part_7665_30429845.1191246172294-- --===============0085660986== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Ldapext mailing list Ldapext@ietf.org https://www1.ietf.org/mailman/listinfo/ldapext --===============0085660986==-- From ldapext-bounces@ietf.org Thu Oct 25 10:53:45 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Il42y-0000Ga-7q; Thu, 25 Oct 2007 10:50:56 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Il42w-0000DR-WA for ldapext@ietf.org; Thu, 25 Oct 2007 10:50:55 -0400 Received: from gmp-eb-mail-2.sun.com ([192.18.6.24]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1Il42w-0000zf-9j for ldapext@ietf.org; Thu, 25 Oct 2007 10:50:54 -0400 Received: from fe-emea-09.sun.com (gmp-eb-lb-2-fe2.eu.sun.com [192.18.6.11]) by gmp-eb-mail-2.sun.com (8.13.7+Sun/8.12.9) with ESMTP id l9PEongt014481 for ; Thu, 25 Oct 2007 14:50:51 GMT Received: from conversion-daemon.fe-emea-09.sun.com by fe-emea-09.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) id <0JQH00B012AA2I00@fe-emea-09.sun.com> (original mail from Ludovic.Poitou@Sun.COM) for ldapext@ietf.org; Thu, 25 Oct 2007 15:50:49 +0100 (BST) Received: from [10.0.10.226] ([83.145.97.43]) by fe-emea-09.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTPSA id <0JQH008UK2JXX930@fe-emea-09.sun.com>; Thu, 25 Oct 2007 15:50:38 +0100 (BST) Date: Thu, 25 Oct 2007 16:50:09 +0200 From: Ludovic Poitou To: Kurt Zeilenga Message-id: <225A5F2F-913C-4B2B-8B3A-376F7D3D3C89@sun.com> MIME-version: 1.0 X-Mailer: Apple Mail (2.752.3) X-Spam-Score: 0.0 (/) X-Scan-Signature: 5ebbf074524e58e662bc8209a6235027 Cc: LDAP Extensions list Subject: [ldapext] About draft-zeilenga-ldap-txn-10 X-BeenThere: ldapext@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: LDAP Extension Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0071499418==" Errors-To: ldapext-bounces@ietf.org --===============0071499418== Content-type: multipart/alternative; boundary="Boundary_(ID_sNRGyVZPLOtm0PnyaKoFnw)" --Boundary_(ID_sNRGyVZPLOtm0PnyaKoFnw) Content-type: text/plain; format=flowed; delsp=yes; charset=US-ASCII Content-transfer-encoding: 7BIT Hi Kurt, I was reviewing the LDAP transaction I-D and have the following questions and comments. - End Transaction Request and Response. Says: The responseValue when present contains a BER-encoded MessageID. What does this MessageID correspond to ? I have a customer interested in the LDAP Transaction draft, but would prefer for auditing purpose and for a better clarity of the code to separate the end transaction into 2 requests: one Commit Transaction and one Abort Transaction. By having 2 separate extended operations, it is easier to distinguished from Logs or traces when a transaction has been committed vs aborted. Also on the client application point of view, it is cleaner to have 2 different API mapping to separate extended operations. Ludo Ludovic Poitou Sun Microsystems Inc. Software Architect Directory Services http://blogs.sun.com/Ludo/ Grenoble Engineering Center - France Sun Microsystems requires the following notice: ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ NOTICE: This email message is for the sole use of the intended recipient(s) and may contain confidential and privileged information. Any unauthorized review, use, disclosure or distribution is prohibited. If you are not the intended recipient, please contact the sender by reply email and destroy all copies of the original message. ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ --Boundary_(ID_sNRGyVZPLOtm0PnyaKoFnw) Content-type: text/html; charset=ISO-8859-1 Content-transfer-encoding: QUOTED-PRINTABLE Hi Kurt,

I was= reviewing the LDAP transaction I-D and have the following questions = and comments.

=
- End Transaction Request and Response.
Says:=A0=A0The= =A0=A0responseValue when present contains a BER-encoded MessageID.
What =A0does this= MessageID correspond to ?

I have a customer= interested in the LDAP Transaction draft, but would prefer for audit= ing purpose and for a better clarity of the code to separate the end = transaction into 2 requests: one Commit Transaction and one Abort Tra= nsaction.
By having 2 separate extended operations, it is e= asier to distinguished from Logs or traces when a transaction has bee= n committed vs aborted.
Also on the client application poin= t of view, it is cleaner to have 2 different API mapping to separate = extended operations.

Ludo



Ludovic Poitou=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0=A0Sun Microsystems Inc.
Sof= tware Architect=A0=A0 = =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0=A0Directory Services
http://blogs= .sun.com/Ludo/=A0= =A0 =A0 =A0 =A0=A0Grenob= le Engineering Center - France

Sun Microsystems requires the fo= llowing notice:
~~~~~~~~~~~~~~~~~~~~~~~~~~~= ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
=A0This emai= l message is for the sole use of the intended
Any unauthorized review, use, disclosur= e or distribution is prohibited.
If you are= not the intended recipient, please contact the sender by
reply email and destroy all copies of the original mes= sage.
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~= ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~



--Boundary_(ID_sNRGyVZPLOtm0PnyaKoFnw)-- --===============0071499418== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Ldapext mailing list Ldapext@ietf.org https://www1.ietf.org/mailman/listinfo/ldapext --===============0071499418==-- From ldapext-bounces@ietf.org Thu Oct 25 12:59:52 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Il626-0004ii-FV; Thu, 25 Oct 2007 12:58:10 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Il624-0004ib-Qc for ldapext@ietf.org; Thu, 25 Oct 2007 12:58:08 -0400 Received: from boole.openldap.org ([204.152.186.50]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1Il624-0006Ad-9g for ldapext@ietf.org; Thu, 25 Oct 2007 12:58:08 -0400 Received: from [192.168.1.198] ([75.141.229.206]) (authenticated bits=0) by boole.openldap.org (8.13.8/8.13.8) with ESMTP id l9PGw6b0080284 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Thu, 25 Oct 2007 16:58:07 GMT (envelope-from Kurt.Zeilenga@Isode.com) In-Reply-To: <225A5F2F-913C-4B2B-8B3A-376F7D3D3C89@sun.com> References: <225A5F2F-913C-4B2B-8B3A-376F7D3D3C89@sun.com> Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Kurt Zeilenga Date: Thu, 25 Oct 2007 09:57:27 -0700 To: Ludovic Poitou X-Mailer: Apple Mail (2.752.3) X-Spam-Score: 0.0 (/) X-Scan-Signature: 769a46790fb42fbb0b0cc700c82f7081 Cc: LDAP Extensions list Subject: [ldapext] Re: About draft-zeilenga-ldap-txn-10 X-BeenThere: ldapext@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: LDAP Extension Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ldapext-bounces@ietf.org On Oct 25, 2007, at 7:50 AM, Ludovic Poitou wrote: > Hi Kurt, > > I was reviewing the LDAP transaction I-D and have the following > questions and comments. > > - End Transaction Request and Response. > Says: The responseValue when present contains a BER-encoded > MessageID. > > What does this MessageID correspond to ? It indicates, when present, the update request to which the non- success resultCode is attributed to (see 3rd paragraph of 3.4). I note that I do intended to modify the end-transaction response data to support pre-/post- read controls, and other controls on update requests. I'm considering changing the response data will end up being the BER-encoding of something like: endResValue ::= SEQUENCE { messageID MessageID OPTIONAL, -- msgid associated with resultCode updatesControls SEQUENCE OF updateControls SEQUENCE { messageID messageID, -- msgid controls are associated with controls Controls } OPTIONAL } -- where MessageID and Controls as are specified in RFC 4511. > I have a customer interested in the LDAP Transaction draft, but > would prefer for auditing purpose and for a better clarity of the > code to separate the end transaction into 2 requests: one Commit > Transaction and one Abort Transaction. By having 2 separate > extended operations, it is easier to distinguished from Logs or > traces when a transaction has been committed vs aborted. > Also on the client application point of view, it is cleaner to have > 2 different API mapping to separate extended operations. I have to think about this some. Off hand, I can see how somethings might be easier if there were two separate extended operations to settle the transaction, but can also see how somethings might be easier when there is one extended operation to settle the transaction. Seems 'easier' here is fairly dependent on implementation details of the client, server, network analyzer, etc. -- Kurt _______________________________________________ Ldapext mailing list Ldapext@ietf.org https://www1.ietf.org/mailman/listinfo/ldapext