Summary of RE: [Sip] Comment, SIP Privacy draft

--------------

I=20 don't completely disagree. In fact, I'm arguing the=20 requirements.

The=20 point I'm trying to make is that To and From are USER supplied = information.=20 The Service Provider doesn't insert them, inspect them, or have any = responsibility for them. Insisting that the service provider change them = is just=20 like insisting that the service provider change any other = user-supplied=20 information, such as the words I'm typing now. Anything I put = in my To=20 or from field is deliberately and explicitly intended to be delivered to = the=20 terminating side of the dialog, and if as a service provider you FAIL to = do=20 that, then you have DAMAGED my data, and my lawyers will be in=20 touch!

&nbs= p;

The=20 calling-party-identity presentation infromation (CLIP or RPID) is NOT = inserted=20 by the user. It is inserted by the network, WITHOUT THE CONSENT of the = user. As=20 such, the operator is responsible for the protection of that information = in a=20 manner consistent with regulation and the expressed wishes of the=20 user.

&nbs= p;

The=20 calling-line-identity-restriction information (CLIR or Privacy) is a = means by=20 which the user expresses wishes with respect to the handling of NETWORK = provided=20 information.

&nbs= p;

This=20 divides data into three = classes:

&nbs= p;

1) Data inserted by a user's = system, under=20 the control of a user, and intended to be delivered to the = termination of=20 the dialog

2) Data inserted by a user's = system, under=20 the control of a user, intended to be delivered to an intermediate = system=20 and not beyond

3) Data=20 inserted by the network, without the awareness of a user, intended = to be=20 delievred to an intermediary or terminal=20 point.

&nbs= p;

Service=20 providers are by regulation in reasonable nations required to prevent = class 2=20 information from being leaked, and to respect the user's preferences for = delivery of class 3 data. =

&nbs= p;

The problem=20 is, the "normal" telephone network doesn't obviously HAVE = user-provided=20 information in the signaling path which is intended to be delivered to = the other=20 end, so telco people start by assuming that all signaling is the = responsibility=20 of the service provider. But there really is something analogous. = Consider=20 Q.SIG, user signaling at the ISDN level generally used for PBX-to-PBX = work. What=20 Mark has been arguing is essentially like arguing that a service = provider must=20 PREVENT the delivery of Q.SIG data because it MIGHT compromise Data = Privacy. Of=20 course it does! It's SUPPOSED to! The operator's responsibility is to = limit the=20 delivery of the data to the intended party (as opposed to deliverying it = to=20 somebody else), not to keep the user from communicating with the = intended=20 party.

&nbs= p;

That's=20 right, kids -- SIP by definition is an enhanced service channel. It does = MORE=20 than plain-old-telephone-service. If you use it carefully, you can = emulate=20 POTS.

&nbs= p;

So, what=20 are these "anoymizer" services we keep talking about? Are they = consistent with=20 my data class division? Notice that class #1 says "to the termination of = the=20 dialog". In using such a service, I'm requesting that my dialog = terminate=20 at an intermediate point which implements the service of generating a = second=20 related but anonymized dialog. In other words, the behavior is = explicitly=20 requested by the user, and is therefore "ok with=20 me".

&nbs= p;

Dean=

------=_NextPart_000_002D_01C1E210.211E9110-- _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@ns.ietf.org Fri Apr 12 13:23:03 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA22363 for ; Fri, 12 Apr 2002 13:23:02 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id NAA29483 for sip-archive@odin.ietf.org; Fri, 12 Apr 2002 13:23:03 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA23600; Fri, 12 Apr 2002 11:44:42 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA23569 for ; Fri, 12 Apr 2002 11:44:38 -0400 (EDT) Received: from zctfs063.nortelnetworks.com (zctfs063.nortelnetworks.com [47.164.128.120]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA07748 for ; Fri, 12 Apr 2002 11:44:02 -0400 (EDT) Received: from zwcwc012.europe.nortel.com (zwcwc012.europe.nortel.com [47.73.112.187]) by zctfs063.nortelnetworks.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id g3CFgZo08509; Fri, 12 Apr 2002 17:42:35 +0200 (MEST) Received: by zwcwc012.europe.nortel.com with Internet Mail Service (5.5.2653.19) id ; Fri, 12 Apr 2002 16:42:39 +0100 Message-ID: From: "Mark Watson" To: "'Mpierce1@aol.com'" , hgs@cs.columbia.edu, Brian.Rosen@marconi.com Cc: jdrosen@dynamicsoft.com, sip@ietf.org, bcampbell@dynamicsoft.com, fandreas@cisco.com, jon.peterson@neustar.biz, wtm@research.att.com Subject: RE: Summary of RE: [Sip] Comment, SIP Privacy draft Date: Fri, 12 Apr 2002 16:42:27 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C1E238.A5CED0C8" Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C1E238.A5CED0C8 Content-Type: text/plain Mike, My suggestion of a generic mechanism to carry Personal Data was targetting at future work, not the present privacy draft. Two points: 1) It's not just about privacy for the calling user - that's relatively easy, you just need a mechanism to 'privately' pass information to trusted network entities and apart from that it's up to the UA what it does/doesn't reveal. The big problem is when other people are involved who do not have an 'agent' representing them. A subscriber to a public service is an example. These people have rights which only the Service Provider knows about. The Service Provider cannot be responsible for sending Personal Data of the subscriber to the called party. Unfortunately the identity of the calling user can often include personal data of the subscriber. 2) You said 'If the user voluntarily includes it, it's not private'. Sure, it's not private *as far as the user is concerned*. But it might be private with respect to other people. So the question is who was *responsible* for sending it. If it's entirely the user then no problem - same as if it's the first thing the user says after Answer. The problem is that To/From are a grey area, since the SIP spec clearly intends that they contain the calling/called identities (as would a spec for 'What-I-Want-You-To-Call-Me'). A network based subscriber privacy service which did not modify the From field would be pretty rubbish, whereas one which did not modify the Subject would probably be fine. ...Mark -----Original Message----- From: Mpierce1@aol.com [mailto:Mpierce1@aol.com] Sent: 12 April 2002 16:19 To: Watson, Mark [MDN05:EP10:EXCH]; hgs@cs.columbia.edu; Brian.Rosen@marconi.com Cc: jdrosen@dynamicsoft.com; sip@ietf.org; bcampbell@dynamicsoft.com; fandreas@cisco.com; jon.peterson@neustar.biz; wtm@research.att.com Subject: Re: Summary of RE: [Sip] Comment, SIP Privacy draft In a message dated 4/12/02 9:30:26 AM Eastern Daylight Time, mwatson@nortelnetworks.com writes: There are many privacy services between the extremes of 'entirely up to the UAs' and 'full B2BUA with IP address anonymiser etc.'. All of them require 'More Than Just A Proxy' because you need to modify the From/To fields (unless you don't care about RFC2543 compatibility, in which case you can modify these fields at something very like a proxy). Other fields may or may not need to be modified/removed - certainly Call-Info & Reply-To would have to go. I think you *can* run the end-to-end data argument with things like Subject and the message body. There is the possibility that new headers exist which carry identity information or other Personal Data. One solution would be to remove all unrecognised headers at the Privacy server. This will break all the new things. There is another way. This would be to define now a generic capability for carrying Personal Data, along with an indication of its privacy status. All new services introduced later which required to send Personal Data would use this capability. So, privacy servers could be built now which would just remove private data from this new place, leaving unrecognised headers alone. The privacy server would still break new services based on Personal Data - but this is the intention of the caller. The privacy server would not break other new things. ...Mark I continue to be confused by this emphasis on the "privacy" half of the draft. It seems to be expanding to consider "Privacy" of everything including what color socks the user is wearing! I know that the overwhelming thoughts in the IETF are to protect privacy, and I don't dispute that, but the primary purpose of this draft (and the "service" it defines) is to provide an "Identity" service, that is, providing one user's identity to the other user. "Privacy" is the second half. We need to agree on what that identity is and how it is provided. Then the second part of the issue is how that identity is protected when the user doesn't want it delivered to the other user (assuming the "network" needs it or knows it). I know this sounds elementary and maybe some think it is obvious, but when the discussion of "privacy" begins to define ways to treat future headers carrying other personal data, I think it is going beyond its purpose. As Mark noted, a Service Provider may have responsibiity for user-supplied information if it is implicit or required in the service that the user supply it (to set up the call). Any extra stuff that is defined just to be passed end-to-end (like Subject) or for a completely different service is not a concern. If the user voluntarily includes it, it is not private. For example, Dean started a discussion of a 'What-I-Want-You-To-Call-Me:' field instead of "From". To me, the fundamental difference is that the "From" field is part of the call setup specification and the "network" should require it, but the "What-I-Want-You-To-Call-Me" field could be see as only being of end-to-end significance and not looked at by the "network". The basic question for this and any field is: "Is it part of 'Identity' or is it supplemental information?" Mike ------_=_NextPart_001_01C1E238.A5CED0C8 Content-Type: text/html

Mike,

My suggestion of a generic mechanism to carry Personal Data was targetting at future work, not the present privacy draft.

Two points:

1) It's not just about privacy for the calling user - that's relatively easy, you just need a mechanism to 'privately' pass information to trusted network entities and apart from that it's up to the UA what it does/doesn't reveal. The big problem is when other people are involved who do not have an 'agent' representing them. A subscriber to a public service is an example. These people have rights which only the Service Provider knows about. The Service Provider cannot be responsible for sending Personal Data of the subscriber to the called party. Unfortunately the identity of the calling user can often include personal data of the subscriber.

2) You said 'If the user voluntarily includes it, it's not private'. Sure, it's not private *as far as the user is concerned*. But it might be private with respect to other people. So the question is who was *responsible* for sending it. If it's entirely the user then no problem - same as if it's the first thing the user says after Answer. The problem is that To/From are a grey area, since the SIP spec clearly intends that they contain the calling/called identities (as would a spec for 'What-I-Want-You-To-Call-Me'). A network based subscriber privacy service which did not modify the From field would be pretty rubbish, whereas one which did not modify the Subject would probably be fine.

...Mark

-----Original Message-----
From: Mpierce1@aol.com [mailto:Mpierce1@aol.com]
Sent: 12 April 2002 16:19
To: Watson, Mark [MDN05:EP10:EXCH]; hgs@cs.columbia.edu; Brian.Rosen@marconi.com
Cc: jdrosen@dynamicsoft.com; sip@ietf.org; bcampbell@dynamicsoft.com; fandreas@cisco.com; jon.peterson@neustar.biz; wtm@research.att.com
Subject: Re: Summary of RE: [Sip] Comment, SIP Privacy draft

In a message dated 4/12/02 9:30:26 AM Eastern Daylight Time, mwatson@nortelnetworks.com writes:

There are many privacy services between the extremes of 'entirely up to the UAs' and 'full B2BUA with IP address anonymiser etc.'.
All of them require 'More Than Just A Proxy' because you need to modify the From/To fields (unless you don't care about RFC2543 compatibility, in which case you can modify these fields at something very like a proxy).
Other fields may or may not need to be modified/removed - certainly Call-Info & Reply-To would have to go. I think you *can* run the end-to-end data argument with things like Subject and the message body.
There is the possibility that new headers exist which carry identity information or other Personal Data. One solution would be to remove all unrecognised headers at the Privacy server. This will break all the new things.
There is another way. This would be to define now a generic capability for carrying Personal Data, along with an indication of its privacy status. All new services introduced later which required to send Personal Data would use this capability. So, privacy servers could be built now which would just remove private data from this new place, leaving unrecognised headers alone.
The privacy server would still break new services based on Personal Data - but this is the intention of the caller. The privacy server would not break other new things.
...Mark

I continue to be confused by this emphasis on the "privacy" half of the draft. It seems to be expanding to consider "Privacy" of everything including what color socks the user is wearing! I know that the overwhelming thoughts in the IETF are to protect privacy, and I don't dispute that, but the primary purpose of this draft (and the "service" it defines) is to provide an "Identity" service, that is, providing one user's identity to the other user. "Privacy" is the second half. We need to agree on what that identity is and how it is provided. Then the second part of the issue is how that identity is protected when the user doesn't want it delivered to the other user (assuming the "network" needs it or knows it). I know this sounds elementary and maybe some think it is obvious, but when the discussion of "privacy" begins to define ways to treat future headers carrying other personal data, I think it is going beyond its purpose.

As Mark noted, a Service Provider may have responsibiity for user-supplied information if it is implicit or required in the service that the user supply it (to set up the call). Any extra stuff that is defined just to be passed end-to-end (like Subject) or for a completely different service is not a concern. If the user voluntarily includes it, it is not private.

For example, Dean started a discussion of a 'What-I-Want-You-To-Call-Me:' field instead of "From". To me, the fundamental difference is that the "From" field is part of the call setup specification and the "network" should require it, but the "What-I-Want-You-To-Call-Me" field could be see as only being of end-to-end significance and not looked at by the "network". The basic question for this and any field is: "Is it part of 'Identity' or is it supplemental information?"

Mike

------_=_NextPart_001_01C1E238.A5CED0C8-- _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@ns.ietf.org Fri Apr 12 14:43:57 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA00100 for ; Fri, 12 Apr 2002 14:43:53 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id OAA04447 for sip-archive@odin.ietf.org; Fri, 12 Apr 2002 14:43:55 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA01019; Fri, 12 Apr 2002 13:52:37 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA00988 for ; Fri, 12 Apr 2002 13:52:32 -0400 (EDT) Received: from zctfs063.nortelnetworks.com (zctfs063.nortelnetworks.com [47.164.128.120]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA25715 for ; Fri, 12 Apr 2002 13:52:28 -0400 (EDT) Received: from zwcwc012.europe.nortel.com (zwcwc012.europe.nortel.com [47.73.112.187]) by zctfs063.nortelnetworks.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id g3CHpmo01953; Fri, 12 Apr 2002 19:51:48 +0200 (MEST) Received: by zwcwc012.europe.nortel.com with Internet Mail Service (5.5.2653.19) id ; Fri, 12 Apr 2002 18:51:53 +0100 Message-ID: From: "Mark Watson" To: "'Dean Willis'" , Mpierce1@aol.com, sip@ietf.org Subject: RE: Summary of RE: [Sip] Comment, SIP Privacy draft Date: Fri, 12 Apr 2002 18:51:46 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C1E24A.B68AA4A2" Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C1E24A.B68AA4A2 Content-Type: text/plain At the risk of repeating myself - well, it's never bothered me before :-) - please see below. All comments assume a Public Service Provider model... -----Original Message----- From: Dean Willis [mailto:dean.willis@softarmor.com] Sent: 12 April 2002 16:52 To: Mpierce1@aol.com; sip@ietf.org Subject: RE: Summary of RE: [Sip] Comment, SIP Privacy draft Mike wrote: ------------- Voice over IP isn't going to escape this regulation for long. It will get "telco-like" requirements sooner or later. It's pretty obvious to me that there needs to be an agreement on the requirements before any more discussion on the protocol details that might be needed to solve an (undefined) problem. -------------- I don't completely disagree. In fact, I'm arguing the requirements. The point I'm trying to make is that To and From are USER supplied information. The Service Provider doesn't insert them, inspect them, or have any responsibility for them. Insisting that the service provider change them is just like insisting that the service provider change any other user-supplied information, such as the words I'm typing now. Anything I put in my To or from field is deliberately and explicitly intended to be delivered to the terminating side of the dialog, and if as a service provider you FAIL to do that, then you have DAMAGED my data, and my lawyers will be in touch! For this discussion to make ANY sense we have to stop talking about user device & network devices and which does what etc. etc. The only important point is what is the *service* that the service provider is offering. If it is a mandatory part of the service that a certain piece of personal data is passed to the service provider, then the service provider has a responsibility not to reveal that if the user *or subscriber* does not want it. It does not matter one iota whether the piece of data was inserted by the user equipment of something else. Basically, the functional distribution of the system is irrelevant, what is important is what it does. Now if the service involves carrying an opaque piece of data to the called party, then obviously the only person with responsibility for that is the person generating the data. If I understand correctly, Dean, you are arguing that the To and From fields work like this. I have been arguing that this MAY not be a reasonable position for a Service Provider when arguing their case with respect to Data Protection. This is on the basis that the SIP spec pretty clearly implies that these fields will contain certain information and a Service Provider could reasonably be expected to know this. Plus "a 'subscriber privacy' service which did not modify these fields would not impress the subscriber much, as 99% of calls would go through with personal data of the subscriber presented to the called party" - (I'm going to put that one on a function key :-) The calling-party-identity presentation infromation (CLIP or RPID) is NOT inserted by the user. It is inserted by the network, WITHOUT THE CONSENT of the user. As such, the operator is responsible for the protection of that information in a manner consistent with regulation and the expressed wishes of the user. Absolutely. The calling-line-identity-restriction information (CLIR or Privacy) is a means by which the user expresses wishes with respect to the handling of NETWORK provided information. This divides data into three classes: 1) Data inserted by a user's system, under the control of a user, and intended to be delivered to the termination of the dialog 2) Data inserted by a user's system, under the control of a user, intended to be delivered to an intermediate system and not beyond 3) Data inserted by the network, without the awareness of a user, intended to be delievred to an intermediary or terminal point. Service providers are by regulation in reasonable nations required to prevent class 2 information from being leaked, and to respect the user's preferences for delivery of class 3 data. Or rather: 1) Opaque data on which the service places no requirement or expectation 2) Data required or expected to be supplied by the user to the service provider as part of the operation of the service 3) Data used within the service provider for the provision of the service The problem is, the "normal" telephone network doesn't obviously HAVE user-provided information in the signaling path which is intended to be delivered to the other end, so telco people start by assuming that all signaling is the responsibility of the service provider. But there really is something analogous. Consider Q.SIG, user signaling at the ISDN level generally used for PBX-to-PBX work. What Mark has been arguing is essentially like arguing that a service provider must PREVENT the delivery of Q.SIG data because it MIGHT compromise Data Privacy. Of course it does! It's SUPPOSED to! The operator's responsibility is to limit the delivery of the data to the intended party (as opposed to deliverying it to somebody else), not to keep the user from communicating with the intended party. Great choice of example ... I know just a little bit about this ... Applying my argument to the Q.SIG data would imply that the subscriber has a right to request that this data not be delivered. Well, that's exactly how the service works, certainly according to the ITU-T standards, because the Q.SIG data is only delivered within a closed user group. i.e. the subscriber expresses their preference as to exactly whom the data can be delivered to in the specification of the closed user group. Indeed, the subscriber would have the right to request that the information is never delivered, but that would rather defeat the object. As has been pointed out a few times there is a natural trade-off between services and privacy. ...Mark That's right, kids -- SIP by definition is an enhanced service channel. It does MORE than plain-old-telephone-service. If you use it carefully, you can emulate POTS. So, what are these "anoymizer" services we keep talking about? Are they consistent with my data class division? Notice that class #1 says "to the termination of the dialog". In using such a service, I'm requesting that my dialog terminate at an intermediate point which implements the service of generating a second related but anonymized dialog. In other words, the behavior is explicitly requested by the user, and is therefore "ok with me". -- Dean ------_=_NextPart_001_01C1E24A.B68AA4A2 Content-Type: text/html Message

At the risk of repeating myself - well, it's never bothered me before :-) - please see below. All comments assume a Public Service Provider model...

-----Original Message-----
From: Dean Willis [mailto:dean.willis@softarmor.com]
Sent: 12 April 2002 16:52
To: Mpierce1@aol.com; sip@ietf.org
Subject: RE: Summary of RE: [Sip] Comment, SIP Privacy draft

Mike wrote:

-------------

Voice over IP isn't going to escape this regulation for long. It will get "telco-like" requirements sooner or later. It's pretty obvious to me that there needs to be an agreement on the requirements before any more discussion on the protocol details that might be needed to solve an (undefined) problem.

--------------

I don't completely disagree. In fact, I'm arguing the requirements.

The point I'm trying to make is that To and From are USER supplied information. The Service Provider doesn't insert them, inspect them, or have any responsibility for them. Insisting that the service provider change them is just like insisting that the service provider change any other user-supplied information, such as the words I'm typing now. Anything I put in my To or from field is deliberately and explicitly intended to be delivered to the terminating side of the dialog, and if as a service provider you FAIL to do that, then you have DAMAGED my data, and my lawyers will be in touch!

For this discussion to make ANY sense we have to stop talking about user device & network devices and which does what etc. etc. The only important point is what is the *service* that the service provider is offering. If it is a mandatory part of the service that a certain piece of personal data is passed to the service provider, then the service provider has a responsibility not to reveal that if the user *or subscriber* does not want it.

It does not matter one iota whether the piece of data was inserted by the user equipment of something else.

Basically, the functional distribution of the system is irrelevant, what is important is what it does.

Now if the service involves carrying an opaque piece of data to the called party, then obviously the only person with responsibility for that is the person generating the data.

If I understand correctly, Dean, you are arguing that the To and From fields work like this.

I have been arguing that this MAY not be a reasonable position for a Service Provider when arguing their case with respect to Data Protection. This is on the basis that the SIP spec pretty clearly implies that these fields will contain certain information and a Service Provider could reasonably be expected to know this.

Plus "a 'subscriber privacy' service which did not modify these fields would not impress the subscriber much, as 99% of calls would go through with personal data of the subscriber presented to the called party" - (I'm going to put that one on a function key :-)

The calling-party-identity presentation infromation (CLIP or RPID) is NOT inserted by the user. It is inserted by the network, WITHOUT THE CONSENT of the user. As such, the operator is responsible for the protection of that information in a manner consistent with regulation and the expressed wishes of the user.

Absolutely.

The calling-line-identity-restriction information (CLIR or Privacy) is a means by which the user expresses wishes with respect to the handling of NETWORK provided information.

This divides data into three classes:

1) Data inserted by a user's system, under the control of a user, and intended to be delivered to the termination of the dialog

2) Data inserted by a user's system, under the control of a user, intended to be delivered to an intermediate system and not beyond

3) Data inserted by the network, without the awareness of a user, intended to be delievred to an intermediary or terminal point.

Service providers are by regulation in reasonable nations required to prevent class 2 information from being leaked, and to respect the user's preferences for delivery of class 3 data.

Or rather:

1) Opaque data on which the service places no requirement or expectation

2) Data required or expected to be supplied by the user to the service provider as part of the operation of the service

3) Data used within the service provider for the provision of the service

The problem is, the "normal" telephone network doesn't obviously HAVE user-provided information in the signaling path which is intended to be delivered to the other end, so telco people start by assuming that all signaling is the responsibility of the service provider. But there really is something analogous. Consider Q.SIG, user signaling at the ISDN level generally used for PBX-to-PBX work. What Mark has been arguing is essentially like arguing that a service provider must PREVENT the delivery of Q.SIG data because it MIGHT compromise Data Privacy. Of course it does! It's SUPPOSED to! The operator's responsibility is to limit the delivery of the data to the intended party (as opposed to deliverying it to somebody else), not to keep the user from communicating with the intended party.

Great choice of example ... I know just a little bit about this ...

Applying my argument to the Q.SIG data would imply that the subscriber has a right to request that this data not be delivered. Well, that's exactly how the service works, certainly according to the ITU-T standards, because the Q.SIG data is only delivered within a closed user group. i.e. the subscriber expresses their preference as to exactly whom the data can be delivered to in the specification of the closed user group.

Indeed, the subscriber would have the right to request that the information is never delivered, but that would rather defeat the object. As has been pointed out a few times there is a natural trade-off between services and privacy.

...Mark

That's right, kids -- SIP by definition is an enhanced service channel. It does MORE than plain-old-telephone-service. If you use it carefully, you can emulate POTS.

So, what are these "anoymizer" services we keep talking about? Are they consistent with my data class division? Notice that class #1 says "to the termination of the dialog". In using such a service, I'm requesting that my dialog terminate at an intermediate point which implements the service of generating a second related but anonymized dialog. In other words, the behavior is explicitly requested by the user, and is therefore "ok with me".

--

Dean

------_=_NextPart_001_01C1E24A.B68AA4A2-- _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@ns.ietf.org Fri Apr 12 14:47:09 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA00186 for ; Fri, 12 Apr 2002 14:47:09 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id OAA04572 for sip-archive@odin.ietf.org; Fri, 12 Apr 2002 14:47:11 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA28826; Fri, 12 Apr 2002 13:06:38 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA28795 for ; Fri, 12 Apr 2002 13:06:34 -0400 (EDT) Received: from sj-msg-core-3.cisco.com (sj-msg-core-3.cisco.com [171.70.157.152]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA20060 for ; Fri, 12 Apr 2002 13:06:32 -0400 (EDT) Received: from imop.cisco.com (IDENT:mirapoint@imop.cisco.com [171.69.11.44]) by sj-msg-core-3.cisco.com (8.12.2/8.12.2) with ESMTP id g3CH5mCl027308 for ; Fri, 12 Apr 2002 10:05:48 -0700 (PDT) Received: from localhost (ssh-sjc-1.cisco.com [171.68.225.134]) by imop.cisco.com (Mirapoint) with ESMTP id ACV58195; Fri, 12 Apr 2002 10:06:02 -0700 (PDT) Date: Fri, 12 Apr 2002 10:03:14 -0700 (Pacific Daylight Time) From: Rohan Mahy To: sip@ietf.org Message-ID: X-X-Sender: rmahy@imop.cisco.com MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Subject: [Sip] please read sec-agree Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Hi, Please read and comment on sec-agree. We hummed to make this a WG item, so we should get a few eyeballs on it sooner rather than later. http://search.ietf.org/internet-drafts/draft-arkko-sip-sec-agree-01.txt thanks, -rohan _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@ns.ietf.org Fri Apr 12 15:28:01 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA01530 for ; Fri, 12 Apr 2002 15:28:01 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id PAA07399 for sip-archive@odin.ietf.org; Fri, 12 Apr 2002 15:28:03 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA04999; Fri, 12 Apr 2002 14:52:40 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA04951 for ; Fri, 12 Apr 2002 14:52:34 -0400 (EDT) Received: from bdsl.66.12.12.130.gte.net (bdsl.66.12.12.130.gte.net [66.12.12.130]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA00354 for ; Fri, 12 Apr 2002 14:52:30 -0400 (EDT) Received: from TXDWILLIS2 (bdsl.greycouncil.com [127.0.0.1]) by bdsl.66.12.12.130.gte.net (8.11.6/8.11.6) with ESMTP id g3CIpbd19481; Fri, 12 Apr 2002 13:51:37 -0500 From: "Dean Willis" To: Cc: , , , Date: Fri, 12 Apr 2002 13:51:00 -0500 Message-ID: <005b01c1e252$fd4b2300$0100a8c0@TXDWILLIS2> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.3416 Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Content-Transfer-Encoding: 7bit Subject: [Sip] SIP Message Draft Fast WGLC Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit We need to quickly review the SIM Message Method Extension. This draft has been widely discussed, iterated several times in SIMPLE, and is on its 2nd revision in SIP. The draft does not appear to be controversial. See: http://search.ietf.org/internet-drafts/draft-ietf-sip-message-01.txt We expect to move to IETF last call next week, so please raise any issues immediately. Ben Campbell will coordinate for the draft editors. -- Dean _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@ns.ietf.org Fri Apr 12 15:30:51 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA01641 for ; Fri, 12 Apr 2002 15:30:47 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id PAA07746 for sip-archive@odin.ietf.org; Fri, 12 Apr 2002 15:30:49 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA03330; Fri, 12 Apr 2002 14:28:30 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA03299 for ; Fri, 12 Apr 2002 14:28:26 -0400 (EDT) Received: from imo-m06.mx.aol.com (imo-m06.mx.aol.com [64.12.136.161]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA29758 for ; Fri, 12 Apr 2002 14:28:23 -0400 (EDT) From: Mpierce1@aol.com Received: from Mpierce1@aol.com by imo-m06.mx.aol.com (mail_out_v32.5.) id d.16.1d6e8549 (4208); Fri, 12 Apr 2002 14:27:02 -0400 (EDT) Message-ID: <16.1d6e8549.29e880f6@aol.com> Date: Fri, 12 Apr 2002 14:27:02 EDT Subject: Re: Summary of RE: [Sip] Comment, SIP Privacy draft To: mwatson@nortelnetworks.com, hgs@cs.columbia.edu, Brian.Rosen@marconi.com CC: jdrosen@dynamicsoft.com, sip@ietf.org, bcampbell@dynamicsoft.com, fandreas@cisco.com, jon.peterson@neustar.biz, wtm@research.att.com MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="part1_16.1d6e8549.29e880f6_boundary" X-Mailer: AOL 6.0 for Windows US sub 10524 Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org --part1_16.1d6e8549.29e880f6_boundary Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit In a message dated 4/12/02 11:42:49 AM Eastern Daylight Time, mwatson@nortelnetworks.com writes: > Mike, > > My suggestion of a generic mechanism to carry Personal Data was targetting > at future work, not the present privacy draft. Yes, I suspected that, but then I noticed that Tom picked up on it as an "very interesting idea " and seemed to be suggesting that we run with it. > > Two points: > 1) It's not just about privacy for the calling user - that's relatively > easy, you just need a mechanism to 'privately' pass information to trusted > network entities and apart from that it's up to the UA what it does/doesn't > reveal. The big problem is when other people are involved who do not have > an 'agent' representing them. A subscriber to a public service is an > example. These people have rights which only the Service Provider knows > about. The Service Provider cannot be responsible for sending Personal Data > of the subscriber to the called party. Unfortunately the identity of the > calling user can often include personal data of the subscriber. > > 2) You said 'If the user voluntarily includes it, it's not private'. Sure, > it's not private *as far as the user is concerned*. But it might be private > with respect to other people. So the question is who was *responsible* for > sending it. If it's entirely the user then no problem - same as if it's the > first thing the user says after Answer. The problem is that To/From are a > grey area, since the SIP spec clearly intends that they contain the > calling/called identities (as would a spec for > 'What-I-Want-You-To-Call-Me'). A network based subscriber privacy service > which did not modify the From field would be pretty rubbish, whereas one > which did not modify the Subject would probably be fine. > I'm confused by what you are getting at by "subscribers" and "other people" (who don't have an "agent"), and "calling user". There is a SIP phone (containing a "User Agent") and it might be used by multiple people to place calls. If people don't have their own identity, then every call must use the identity of the physical device. If there is a capability for each person to provide a separate identity, then that is what is used by the "network" as the basis for a "subscription" to service and to apply privacy. If you are referring to the complicated cases of how to apply "privacy" to identities involved in 3-way services such as call transfer and call forwarding, then I understand the difficulties, having been through excrutiating discussions in standards development for ISDN. It isn't easy or pretty. But these issues will only be worked out in a specific discusion of the interworking of the identity/privacy service with the call transfer/call forwarding services, something that the IETF is intent on not doing. I still say if the user voluntarily includes something beyond the specific identity fields, then the network has no obligation to apply privacy to it. I don't see a case in which the network has to do anything else to provide privacy for "other people". Again, maybe there is a difference in what "user" refers to in your point 2) above. If the "standard" service operation (in the User Agent or network) puts in some identity, or passes along one it got during Call Transfer, then of course privacy rules must apply to it. That's not the user (person) voluntarily putting in the information. Mike --part1_16.1d6e8549.29e880f6_boundary Content-Type: text/html; charset="US-ASCII" Content-Transfer-Encoding: 7bit In a message dated 4/12/02 11:42:49 AM Eastern Daylight Time, mwatson@nortelnetworks.com writes:

Mike,

My suggestion of a generic mechanism to carry Personal Data was targetting at future work, not the present privacy draft.

Yes, I suspected that, but then I noticed that Tom picked up on it as an "very interesting idea " and seemed to be suggesting that we run with it.

Two points:
1) It's not just about privacy for the calling user - that's relatively easy, you just need a mechanism to 'privately' pass information to trusted network entities and apart from that it's up to the UA what it does/doesn't reveal. The big problem is when other people are involved who do not have an 'agent' representing them. A subscriber to a public service is an example. These people have rights which only the Service Provider knows about. The Service Provider cannot be responsible for sending Personal Data of the subscriber to the called party. Unfortunately the identity of the calling user can often include personal data of the subscriber.

2) You said 'If the user voluntarily includes it, it's not private'. Sure, it's not private *as far as the user is concerned*. But it might be private with respect to other people. So the question is who was *responsible* for sending it. If it's entirely the user then no problem - same as if it's the first thing the user says after Answer. The problem is that To/From are a grey area, since the SIP spec clearly intends that they contain the calling/called identities (as would a spec for 'What-I-Want-You-To-Call-Me'). A network based subscriber privacy service which did not modify the From field would be pretty rubbish, whereas one which did not modify the Subject would probably be fine.

I'm confused by what you are getting at by "subscribers" and "other people" (who don't have an "agent"), and "calling user". There is a SIP phone (containing a "User Agent") and it might be used by multiple people to place calls. If people don't have their own identity, then every call must use the identity of the physical device. If there is a capability for each person to provide a separate identity, then that is what is used by the "network" as the basis for a "subscription" to service and to apply privacy.

If you are referring to the complicated cases of how to apply "privacy" to identities involved in 3-way services such as call transfer and call forwarding, then I understand the difficulties, having been through excrutiating discussions in standards development for ISDN. It isn't easy or pretty. But these issues will only be worked out in a specific discusion of the interworking of the identity/privacy service with the call transfer/call forwarding services, something that the IETF is intent on not doing.

I still say if the user voluntarily includes something beyond the specific identity fields, then the network has no obligation to apply privacy to it. I don't see a case in which the network has to do anything else to provide privacy for "other people". Again, maybe there is a difference in what "user" refers to in your point 2) above. If the "standard" service operation (in the User Agent or network) puts in some identity, or passes along one it got during Call Transfer, then of course privacy rules must apply to it. That's not the user (person) voluntarily putting in the information.

Mike --part1_16.1d6e8549.29e880f6_boundary-- _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@ns.ietf.org Fri Apr 12 15:33:55 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA01762 for ; Fri, 12 Apr 2002 15:33:55 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id PAA08084 for sip-archive@odin.ietf.org; Fri, 12 Apr 2002 15:33:58 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA03243; Fri, 12 Apr 2002 14:27:48 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA03205 for ; Fri, 12 Apr 2002 14:27:45 -0400 (EDT) Received: from imo-m05.mx.aol.com (imo-m05.mx.aol.com [64.12.136.8]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA29746 for ; Fri, 12 Apr 2002 14:27:40 -0400 (EDT) From: Mpierce1@aol.com Received: from Mpierce1@aol.com by imo-m05.mx.aol.com (mail_out_v32.5.) id d.12.1d8d1548 (4208); Fri, 12 Apr 2002 14:26:57 -0400 (EDT) Message-ID: <12.1d8d1548.29e880f1@aol.com> Date: Fri, 12 Apr 2002 14:26:57 EDT Subject: Re: Summary of RE: [Sip] Comment, SIP Privacy draft To: dean.willis@softarmor.com, Brian.Rosen@marconi.com, sip@ietf.org MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="part1_12.1d8d1548.29e880f1_boundary" X-Mailer: AOL 6.0 for Windows US sub 10524 Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org --part1_12.1d8d1548.29e880f1_boundary Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit In a message dated 4/12/02 11:53:16 AM Eastern Daylight Time, dean.willis@softarmor.com writes: > The point I'm trying to make is that To and From are USER supplied > information. The Service Provider doesn't insert them, inspect them, or > have any responsibility for them. Insisting that the service provider > change them is just like insisting that the service provider change any > other user-supplied information, such as the words I'm typing now. Anything > I put in my To or from field is deliberately and explicitly intended to be > delivered to the terminating side of the dialog, and if as a service > provider you FAIL to do that, then you have DAMAGED my data, and my lawyers > will be in touch! > > The calling-party-identity presentation infromation (CLIP or RPID) is NOT > inserted by the user. It is inserted by the network, WITHOUT THE CONSENT of > the user. As such, the operator is responsible for the protection of that > information in a manner consistent with regulation and the expressed wishes > of the user. > > The calling-line-identity-restriction information (CLIR or Privacy) is a > means by which the user expresses wishes with respect to the handling of > NETWORK provided information. > In a message dated 4/12/02 11:33:03 AM Eastern Daylight Time, Brian.Rosen@marconi.com writes: > The problem with this line of thinking is that in the PSTN, identity is > always asserted by > the network, and never by the UA. In SIP, presently, identity is always > asserted by > the UA and never the network. Privacy when you have network asserted > identity > means something different than when you have user asserted identity. > There seems to be some confusion about the current "PSTN" situation. True, in the POTS PSTN (analog lines) the user doesn't actually include their identity in the signaling to the network. But, since the identity is directly associated with the physical phone line, it's the same thing. The telephone company simply converts its knowledge of the identity of the wire into a telephone number and goes from there. In ISDN, on the other hand, the user can include their identity (phone number) in the signaling, since each physical interface and each device can support multiple telephone numbers. The number is put in the Calling Party Number field. The network may screen this number to make sure it is a valid number for that interface. Depending on the result of the screening, the network may include multiple numbers in the call set up, for example, an unverified user provided number and the network provided valid number. The user may specify by per-call signaling or by a permanent subscription option whether or not they want the network to apply the restriction ("privacy") feature to this identity (whether the identity came from the user or was added by the network or both doesn't matter). There is no attempt to also apply "privacy" if the user chooses to put some other identifying information in the User-to-user field. We have to decide whether the From/To fields are like the Calling Party Number field in ISDN (meant for user-network signaling and left to the network to change if required by the service) or are they like the User-to-user field in ISDN (never touched by the network). I've heard both sides of the argument being made, so there is apparently not a consistent view on how basic SIP works. It seems that the added RPID field is similar to the network added (verified) number in ISDN. Mike --part1_12.1d8d1548.29e880f1_boundary Content-Type: text/html; charset="US-ASCII" Content-Transfer-Encoding: 7bit In a message dated 4/12/02 11:53:16 AM Eastern Daylight Time, dean.willis@softarmor.com writes:

The point I'm trying to make is that To and From are USER supplied information. The Service Provider doesn't insert them, inspect them, or have any responsibility for them. Insisting that the service provider change them is just like insisting that the service provider change any other user-supplied information, such as the words I'm typing now. Anything I put in my To or from field is deliberately and explicitly intended to be delivered to the terminating side of the dialog, and if as a service provider you FAIL to do that, then you have DAMAGED my data, and my lawyers will be in touch!

The calling-party-identity presentation infromation (CLIP or RPID) is NOT inserted by the user. It is inserted by the network, WITHOUT THE CONSENT of the user. As such, the operator is responsible for the protection of that information in a manner consistent with regulation and the expressed wishes of the user.

The calling-line-identity-restriction information (CLIR or Privacy) is a means by which the user expresses wishes with respect to the handling of NETWORK provided information.

In a message dated 4/12/02 11:33:03 AM Eastern Daylight Time, Brian.Rosen@marconi.com writes:

The problem with this line of thinking is that in the PSTN, identity is always asserted by
the network, and never by the UA. In SIP, presently, identity is always asserted by
the UA and never the network. Privacy when you have network asserted identity
means something different than when you have user asserted identity.

There seems to be some confusion about the current "PSTN" situation. True, in the POTS PSTN (analog lines) the user doesn't actually include their identity in the signaling to the network. But, since the identity is directly associated with the physical phone line, it's the same thing. The telephone company simply converts its knowledge of the identity of the wire into a telephone number and goes from there.

In ISDN, on the other hand, the user can include their identity (phone number) in the signaling, since each physical interface and each device can support multiple telephone numbers. The number is put in the Calling Party Number field. The network may screen this number to make sure it is a valid number for that interface. Depending on the result of the screening, the network may include multiple numbers in the call set up, for example, an unverified user provided number and the network provided valid number.

The user may specify by per-call signaling or by a permanent subscription option whether or not they want the network to apply the restriction ("privacy") feature to this identity (whether the identity came from the user or was added by the network or both doesn't matter). There is no attempt to also apply "privacy" if the user chooses to put some other identifying information in the User-to-user field.

We have to decide whether the From/To fields are like the Calling Party Number field in ISDN (meant for user-network signaling and left to the network to change if required by the service) or are they like the User-to-user field in ISDN (never touched by the network). I've heard both sides of the argument being made, so there is apparently not a consistent view on how basic SIP works.

It seems that the added RPID field is similar to the network added (verified) number in ISDN.

Mike
--part1_12.1d8d1548.29e880f1_boundary-- _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@ns.ietf.org Fri Apr 12 15:47:04 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA02025 for ; Fri, 12 Apr 2002 15:47:04 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id PAA08651 for sip-archive@odin.ietf.org; Fri, 12 Apr 2002 15:47:07 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA02728; Fri, 12 Apr 2002 14:16:57 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA26602 for ; Fri, 12 Apr 2002 12:25:36 -0400 (EDT) Received: from hermes.fm.intel.com (fmr01.intel.com [192.55.52.18]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA14543 for ; Fri, 12 Apr 2002 12:25:32 -0400 (EDT) Received: from talaria.fm.intel.com (talaria.fm.intel.com [10.1.192.39]) by hermes.fm.intel.com (8.11.6/8.11.6/d: outer.mc,v 1.38 2002/04/09 21:20:23 root Exp $) with ESMTP id g3CGQVj09951 for ; Fri, 12 Apr 2002 16:26:31 GMT Received: from fmsmsxvs042.fm.intel.com (fmsmsxv042-1.fm.intel.com [132.233.48.110]) by talaria.fm.intel.com (8.11.6/8.11.6/d: inner.mc,v 1.15 2002/04/01 17:51:48 root Exp $) with SMTP id g3CGQZE02360 for ; Fri, 12 Apr 2002 16:26:35 GMT Received: from fmsmsx26.fm.intel.com ([132.233.42.26]) by fmsmsxvs042.fm.intel.com (NAVGW 2.5.1.16) with SMTP id M2002041209285412871 ; Fri, 12 Apr 2002 09:28:54 -0700 Received: by fmsmsx26.fm.intel.com with Internet Mail Service (5.5.2653.19) id <2HL0FSXZ>; Fri, 12 Apr 2002 09:24:58 -0700 Message-ID: From: "Shankara, Udaya" To: "'sip-implementors@cs.columbia.edu,'", >, "'sip@ietf.org'" Date: Fri, 12 Apr 2002 09:24:51 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Subject: [Sip] Call establishment over TCP Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Hi, Let us consider a call between 2 UAs over TCP: UA1 <---------> UA2 UA1 sends an INVITE to UA2 over TCP (channel 1). The Contact header of INVITE contains UA1's IP address and port 8000. UA2 responds to INVITE over channel 1 and ACK is also sent over the same channel. Let us assume that UA2 determines to terminate the call. The question is: Does UA2 send BYE over channel 1 or does it open a new TCP connection (channel 2) to the server running at port 8000? Regards, Udaya _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@ns.ietf.org Fri Apr 12 16:00:30 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA02399 for ; Fri, 12 Apr 2002 16:00:30 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id QAA09291 for sip-archive@odin.ietf.org; Fri, 12 Apr 2002 16:00:32 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA03927; Fri, 12 Apr 2002 14:32:07 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA03870 for ; Fri, 12 Apr 2002 14:32:02 -0400 (EDT) Received: from lohi.eng.song.fi (lohi.eng.song.fi [195.10.149.18]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA29849 for ; Fri, 12 Apr 2002 14:31:59 -0400 (EDT) From: jh@lohi.eng.song.fi Received: from harjus.eng.song.fi ([195.10.149.20]) by lohi.eng.song.fi with esmtp (Exim 3.34 #1 (Debian)) id 16w5q3-0002j6-00; Fri, 12 Apr 2002 21:31:59 +0300 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15543.10270.803265.882718@harjus.eng.song.fi> Date: Fri, 12 Apr 2002 21:31:58 +0300 To: "Dean Willis" Cc: , Subject: RE: Summary of RE: [Sip] Comment, SIP Privacy draft In-Reply-To: <002c01c1e23a$09f49910$0100a8c0@TXDWILLIS2> References: <002c01c1e23a$09f49910$0100a8c0@TXDWILLIS2> X-Mailer: VM 7.01 under Emacs 21.1.1 Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit Dean Willis writes: > The point I'm trying to make is that To and From are USER supplied > information. The Service Provider doesn't insert them, inspect them, or > have any responsibility for them. if someone subscribes to my sip service, i DO check for each message received from the user that the from field corresponds to what i have agreed with the user. otherwise the user could fake to be somone else that i consider a bad thing. if the from field doesn't match, i don't forward the message. if that is not acceptable for the user, the use can choose another service provider or roll its own service. ii do not modify anything. > Anything I put in my To or from field is deliberately and explicitly > intended to be delivered to the terminating side of the dialog, and if > as a service provider you FAIL to do that, then you have DAMAGED my > data, and my lawyers will be in touch! i'm not damaging your data. i simply don't serve your message and you have no way to win the case in court. -- juha _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@ns.ietf.org Fri Apr 12 16:06:36 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA02520 for ; Fri, 12 Apr 2002 16:06:32 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id QAA09795 for sip-archive@odin.ietf.org; Fri, 12 Apr 2002 16:06:34 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA07255; Fri, 12 Apr 2002 15:26:19 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA07222 for ; Fri, 12 Apr 2002 15:26:14 -0400 (EDT) Received: from sj-msg-core-3.cisco.com (sj-msg-core-3.cisco.com [171.70.157.152]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA01460 for ; Fri, 12 Apr 2002 15:26:11 -0400 (EDT) Received: from mira-sjc5-7.cisco.com (IDENT:mirapoint@mira-sjc5-7.cisco.com [171.71.163.27]) by sj-msg-core-3.cisco.com (8.12.2/8.12.2) with ESMTP id g3CJOjiL006145; Fri, 12 Apr 2002 12:24:45 -0700 (PDT) Received: from thomasm-u1.cisco.com (thomasm-u1.cisco.com [128.107.140.53]) by mira-sjc5-7.cisco.com (Mirapoint) with ESMTP id ABL12009; Fri, 12 Apr 2002 12:22:13 -0700 (PDT) Received: (thomasm@localhost) by thomasm-u1.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id MAA17071; Fri, 12 Apr 2002 12:25:00 -0700 (PDT) From: Michael Thomas MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15543.13451.910891.674130@thomasm-u1.cisco.com> Date: Fri, 12 Apr 2002 12:24:59 -0700 (PDT) To: Henning Schulzrinne Cc: "Rosen, Brian" , "'Mark Watson'" , "'Jonathan Rosenberg'" , sip@ietf.org, Ben Campbell , Flemming Andreasen , "Peterson, Jon" , "'William Marshall'" Subject: Re: Summary of RE: [Sip] Comment, SIP Privacy draft In-Reply-To: <3CB6DA76.8E5E0373@cs.columbia.edu> References: <313680C9A886D511A06000204840E1CF57CE3C@whq-msgusr-02.pit.comms.marconi.com> <3CB6DA76.8E5E0373@cs.columbia.edu> X-Mailer: VM 6.72 under 21.1 (patch 6) "Big Bend" XEmacs Lucid X-Face: &,heK/V66p?[2!i|tVn,9lN0TUvEv7:9FzXREj/AuzN4mu!4x[/Z4t{V}~L]+Sk @RFNnJEg~WZ/(8<`5a),-7ukALWa^&?&D2R0CSG3kO5~#6JxLF\d,g">$%B!0w{W)qIhmwhye104zd bUcI'1! Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit Henning Schulzrinne writes: > I agree that, in general, the UA should be treated like a mature adult > and get to make decisions as to what information it wants to include in > its call setup requests or not. I don't agree that anonymity requires a > B2BUA in all cases. For example, one could imagine that a large ISP > could hand out random IP addresses from a large pool, making it > essentially similar to an anonymizer service. BTW, IPv6 already allows for private (read: formed dynamically and randomly by the host) IP addresses. The ISP doesn't even need to "allow" it or provide for it. > There is no principal > difference between knowing that "user came from anonymizer service > anon.com" and "user came from ISP large-isp.com". (Well, almost: it may > be easier to switch anonymity providers than ISPs.) This all gets down to your paranoia level. Prefixes do tell you something about IP topology which could lead to educated guesses -- which may be all that's necessary. Hopefully this level of paranoia will only be needed in the direst of cases like mob snitches, etc. Mike _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@ns.ietf.org Fri Apr 12 16:06:49 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA02541 for ; Fri, 12 Apr 2002 16:06:49 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id QAA09813 for sip-archive@odin.ietf.org; Fri, 12 Apr 2002 16:06:51 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA06664; Fri, 12 Apr 2002 15:18:23 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA06633 for ; Fri, 12 Apr 2002 15:18:17 -0400 (EDT) Received: from bdsl.66.12.12.130.gte.net (bdsl.66.12.12.130.gte.net [66.12.12.130]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA01188 for ; Fri, 12 Apr 2002 15:18:14 -0400 (EDT) Received: from TXDWILLIS2 (bdsl.greycouncil.com [127.0.0.1]) by bdsl.66.12.12.130.gte.net (8.11.6/8.11.6) with ESMTP id g3CJHJd19653; Fri, 12 Apr 2002 14:17:19 -0500 From: "Dean Willis" To: Cc: , , , Date: Fri, 12 Apr 2002 14:16:41 -0500 Message-ID: <006301c1e256$946cfd00$0100a8c0@TXDWILLIS2> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.3416 Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Content-Transfer-Encoding: 7bit Subject: [Sip] Correction:SIP Message Draft Fast WGLC Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit Oops. Please review : http://www.softarmor.com/sipwg/drafts/draft-ietf-sip-message-02.txt Until the -02 makes it into the draft repository. They're not as fast as I'm wishing for (ok, light speed is too slow, while we're at it!) Thanks, -- Dean Original message: ------------- We need to quickly review the SIM Message Method Extension. This draft has been widely discussed, iterated several times in SIMPLE, and is on its 2nd revision in SIP. The draft does not appear to be controversial. See: http://search.ietf.org/internet-drafts/draft-ietf-sip-message-01.txt We expect to move to IETF last call next week, so please raise any issues immediately. Ben Campbell will coordinate for the draft editors. ----------------- _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@ns.ietf.org Fri Apr 12 16:07:14 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA02574 for ; Fri, 12 Apr 2002 16:07:14 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id QAA09840 for sip-archive@odin.ietf.org; Fri, 12 Apr 2002 16:07:16 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA06202; Fri, 12 Apr 2002 15:12:38 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA06171 for ; Fri, 12 Apr 2002 15:12:34 -0400 (EDT) Received: from magus.nostrum.com (root@magus.nostrum.com [66.119.225.66]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA00934 for ; Fri, 12 Apr 2002 15:12:31 -0400 (EDT) Received: from txbcampbell (root@magus.nostrum.com [66.119.225.66]) by magus.nostrum.com (8.11.0/8.11.0) with SMTP id g3CJCUX68128; Fri, 12 Apr 2002 14:12:31 -0500 (CDT) From: "Ben Campbell" To: "Dean Willis" , Cc: , , Date: Fri, 12 Apr 2002 14:12:16 -0500 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Priority: 1 (Highest) X-MSMail-Priority: High X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) In-Reply-To: <005b01c1e252$fd4b2300$0100a8c0@TXDWILLIS2> Importance: High X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Content-Transfer-Encoding: 7bit Subject: [Sip] RE: SIP Message Draft Fast WGLC Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit Actually, I just submitted draft-ietf-sip-message-02.txt yesterday. I _thought_ that was the one we were going to WGLC. Since it does not seem to have made the repository, I will send a link to it in a second message (any moment now) > -----Original Message----- > From: Dean Willis [mailto:dwillis@dynamicsoft.com] > Sent: Friday, April 12, 2002 1:51 PM > To: sip@ietf.org > Cc: rohan@cisco.com; bcampbell@dynamicsoft.com; brian.rosen@marconi.com; > jo@ipdialog.com > Subject: SIP Message Draft Fast WGLC > > > > We need to quickly review the SIM Message Method Extension. This draft > has been widely discussed, iterated several times in SIMPLE, and is on > its 2nd revision in SIP. The draft does not appear to be controversial. > > See: > > http://search.ietf.org/internet-drafts/draft-ietf-sip-message-01.txt > > We expect to move to IETF last call next week, so please raise any > issues immediately. > > Ben Campbell will coordinate for the draft editors. > > > -- > Dean _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@ns.ietf.org Fri Apr 12 16:37:05 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA03488 for ; Fri, 12 Apr 2002 16:37:05 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id QAA12007 for sip-archive@odin.ietf.org; Fri, 12 Apr 2002 16:37:08 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA08265; Fri, 12 Apr 2002 15:38:56 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA08234 for ; Fri, 12 Apr 2002 15:38:52 -0400 (EDT) Received: from bdsl.66.12.12.130.gte.net (bdsl.66.12.12.130.gte.net [66.12.12.130]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA01897 for ; Fri, 12 Apr 2002 15:38:48 -0400 (EDT) Received: from TXDWILLIS2 (bdsl.greycouncil.com [127.0.0.1]) by bdsl.66.12.12.130.gte.net (8.11.6/8.11.6) with ESMTP id g3CJcHd19834; Fri, 12 Apr 2002 14:38:18 -0500 From: "Dean Willis" To: , , Subject: RE: Summary of RE: [Sip] Comment, SIP Privacy draft Date: Fri, 12 Apr 2002 14:37:40 -0500 Message-ID: <006e01c1e259$8275ced0$0100a8c0@TXDWILLIS2> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.3416 Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 In-reply-to: <12.1d8d1548.29e880f1@aol.com> Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit Mike wrote: ---------------------- There seems to be some confusion about the current "PSTN" situation. True, in the POTS PSTN (analog lines) the user doesn't actually include their identity in the signaling to the network. But, since the identity is directly associated with the physical phone line, it's the same thing. The telephone company simply converts its knowledge of the identity of the wire into a telephone number and goes from there. In ISDN, on the other hand, the user can include their identity (phone number) in the signaling, since each physical interface and each device can support multiple telephone numbers. The number is put in the Calling Party Number field. The network may screen this number to make sure it is a valid number for that interface. Depending on the result of the screening, the network may include multiple numbers in the call set up, for example, an unverified user provided number and the network provided valid number. The user may specify by per-call signaling or by a permanent subscription option whether or not they want the network to apply the restriction ("privacy") feature to this identity (whether the identity came from the user or was added by the network or both doesn't matter). There is no attempt to also apply "privacy" if the user chooses to put some other identifying information in the User-to-user field. We have to decide whether the From/To fields are like the Calling Party Number field in ISDN (meant for user-network signaling and left to the network to change if required by the service) or are they like the User-to-user field in ISDN (never touched by the network). I've heard both sides of the argument being made, so there is apparently not a consistent view on how basic SIP works. It seems that the added RPID field is similar to the network added (verified) number in ISDN. ------------------------ Excellent summary, Mike. That's exactly what I'm saying. In short: To:/From: are equivalent to ISDN user-to-user data, as is most of current SIP. RPID: is analogous to CPN, and its "Screened" parameter analogous to what happens in ISDN today. Privacy: is analogous to the calling line identification restriction flag. I think an understanding of this relationship should clear up 99% of the debate over the "privacy" draft, which is really much more of a SIP-T "telephony interworking" document than it is a general privacy document. -- dean _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@ns.ietf.org Fri Apr 12 16:37:09 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA03505 for ; Fri, 12 Apr 2002 16:37:08 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id QAA12023 for sip-archive@odin.ietf.org; Fri, 12 Apr 2002 16:37:11 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA09669; Fri, 12 Apr 2002 16:02:49 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA09638 for ; Fri, 12 Apr 2002 16:02:44 -0400 (EDT) Received: from cs.columbia.edu (cs.columbia.edu [128.59.16.20]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA02447 for ; Fri, 12 Apr 2002 16:02:41 -0400 (EDT) Received: from opus.cs.columbia.edu (opus.cs.columbia.edu [128.59.20.100]) by cs.columbia.edu (8.9.3/8.9.3) with ESMTP id QAA14716; Fri, 12 Apr 2002 16:02:34 -0400 (EDT) Received: from cs.columbia.edu (cta.cs.columbia.edu [128.59.19.46]) (authenticated bits=0) by opus.cs.columbia.edu (8.12.1/8.12.1) with ESMTP id g3CK2XPm023180 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Fri, 12 Apr 2002 16:02:33 -0400 (EDT) Message-ID: <3CB73D2F.34EC9ABE@cs.columbia.edu> Date: Fri, 12 Apr 2002 16:01:51 -0400 From: Henning Schulzrinne Organization: Columbia University X-Mailer: Mozilla 4.76 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Michael Thomas CC: "Rosen, Brian" , "'Mark Watson'" , "'Jonathan Rosenberg'" , sip@ietf.org Subject: Re: Summary of RE: [Sip] Comment, SIP Privacy draft References: <313680C9A886D511A06000204840E1CF57CE3C@whq-msgusr-02.pit.comms.marconi.com> <3CB6DA76.8E5E0373@cs.columbia.edu> <15543.13451.910891.674130@thomasm-u1.cisco.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit [Trimming privacy-threatening cc lines, revealing list membership :-)] I think part of the problem is, as I think Dean and Brian have alluded to, is that many things that used to be tied together in one mechanism in the PSTN are now split across several different ones: - From display name - From URL - RPID - user authentication name (Authorization) - Organization - Call-Info Also, to pick up the "disable CLID and disallow anonymous calls": I think part of this has to do with the commingling of identity and the ability to call back. I suspect that even the Hollywood mogul wouldn't mind if his name appeared on the starlets display screen, but wants to maintain the "don't call us, we'll call you" attitude, i.e., avoid revealing a callable number. I don't think anticipating regulation is particularly helpful here. Anybody can say anything about what some legislature somewhere may legislate at some point in the future. I wouldn't be too surprised if, instead of PSTN legislation, some of the email spam legislation finds its way into SIP behavior, e.g., having to declare a truthful return address, an indication of the call intent (like some of the laws and bills calling for adding ADV to the subject line) or including an opt-out link (header?). If we could make progress there, I think we'd do more for "privacy" than hiding a user name. Henning _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@ns.ietf.org Fri Apr 12 17:42:10 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA04806 for ; Fri, 12 Apr 2002 17:42:10 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id RAA15858 for sip-archive@odin.ietf.org; Fri, 12 Apr 2002 17:42:13 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA14708; Fri, 12 Apr 2002 17:25:39 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA14677 for ; Fri, 12 Apr 2002 17:25:34 -0400 (EDT) Received: from services.dasecurenetworks.com (adsl-64-217-198-192.dsl.rcsntx.swbell.net [64.217.198.192]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA04545 for ; Fri, 12 Apr 2002 17:25:29 -0400 (EDT) Received: from dasecurenetworks.com (main1.localdomain [192.168.0.151]) by services.dasecurenetworks.com (8.11.6/8.9.3) with ESMTP id g3CKtAf16329; Fri, 12 Apr 2002 15:55:12 -0500 Message-ID: <3CB7554F.93695358@dasecurenetworks.com> Date: Fri, 12 Apr 2002 16:44:47 -0500 From: Chris Martin Reply-To: cmartin@dasecurenetworks.com X-Mailer: Mozilla 4.78 [en] (X11; U; Linux 2.4.7-10enterprise i686) X-Accept-Language: en MIME-Version: 1.0 To: "Rosen, Brian" CC: "'Mark Watson'" , "'Jonathan Rosenberg'" , sip@ietf.org, Ben Campbell , Flemming Andreasen , "Peterson, Jon" , "'William Marshall'" Subject: Re: Summary of RE: [Sip] Comment, SIP Privacy draft References: <313680C9A886D511A06000204840E1CF57CE41@whq-msgusr-02.pit.comms.marconi.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit "Rosen, Brian" wrote: > > >> The UA is by far in the best position to determine the level of > >> anonymity it wishes, and if it can't get enough (because, for example, > >> it wants it's IP addresses obscured), it will have to employ a > >> B2BUA as above. > > > >Agreed. But the UA is not in a good position to determine the > >subscribers anonymity requirements, or other parties not represented > >by a UA. In a Service Provider model, these people have some rights. > >So, the network may have to employ a B2BUA or whatever on behalf of > >these people. There is no problem with this and so no case for > >obfuscating the From/To fields - agreed ? > > Agreed. Don't forget the obvious problem of any crypto (signatures > for example) on any of these fields! Yep, current B2BUA's would have problems if encryption or hashing is done for many of the fields. The development of SIPS is an example where current B2BUA's may run into issues as SIPS is developed and standardized, unless they are also able to verify hash or provide decryption/encrytpion as needed to provide the service. Chris > > Brian > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@ns.ietf.org Fri Apr 12 17:43:13 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA04840 for ; Fri, 12 Apr 2002 17:43:13 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id RAA15884 for sip-archive@odin.ietf.org; Fri, 12 Apr 2002 17:43:16 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA15520; Fri, 12 Apr 2002 17:32:28 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA15411 for ; Fri, 12 Apr 2002 17:32:21 -0400 (EDT) Received: from services.dasecurenetworks.com (adsl-64-217-198-192.dsl.rcsntx.swbell.net [64.217.198.192]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA04658 for ; Fri, 12 Apr 2002 17:32:16 -0400 (EDT) Received: from dasecurenetworks.com (main1.localdomain [192.168.0.151]) by services.dasecurenetworks.com (8.11.6/8.9.3) with ESMTP id g3CL23f16353; Fri, 12 Apr 2002 16:02:05 -0500 Message-ID: <3CB756EC.83D9A212@dasecurenetworks.com> Date: Fri, 12 Apr 2002 16:51:40 -0500 From: Chris Martin Reply-To: cmartin@dasecurenetworks.com X-Mailer: Mozilla 4.78 [en] (X11; U; Linux 2.4.7-10enterprise i686) X-Accept-Language: en MIME-Version: 1.0 To: Mark Watson CC: "'Rosen, Brian'" , "'William Marshall'" , jdrosen@dynamicsoft.com, sip@ietf.org Subject: Re: Summary of RE: [Sip] Comment, SIP Privacy draft References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit > Mark Watson wrote: > > Brian wrote: > > > To me, the service that breaks with anonymous From/To is > > the ability to call me. If my phone rings, and the "From" > > which is displayed says "anonymous", I'm not going to answer it. > > Very sensible. It could be anyone! > > You might answer it if the call came from a Service Provider that you > trusted, and that Service Provider had mechanisms to verify and record > the identity of the caller, and to pass that identifier to the > authorities if the call turns out to be malicious. Speaking in terms of service provider, maybe that is where additional headers should be required (Between B2BUA and/or SP/enterprise sip proxies, rather than endpoints, for the interdomain traffic, in order to hand off the "true" identity. Since hosts of service providers would need to go through the registration and authentication process prior to initiating sessions (for that point the SP customer would have to go through a sign up for services process prior to be allowed to register). > > There is always a balance between the desire of the caller to remain > anonymous and of the called party to reject anonymous calls. Without > an intermediary then the balance gets tipped completely to one side or > the other. > > > I'll probably instruct my voicemail service to do the same. > > The Police Tip line might very well accept such calls however. > > > > I'm reminded of the practices of some Hollywood types that > > block Caller-Id, but won't accept calls that don't provide > > Caller-Id! > > _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@ns.ietf.org Fri Apr 12 19:01:12 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA06358 for ; Fri, 12 Apr 2002 19:01:12 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id TAA19657 for sip-archive@odin.ietf.org; Fri, 12 Apr 2002 19:01:14 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA18856; Fri, 12 Apr 2002 18:46:07 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA18829 for ; Fri, 12 Apr 2002 18:46:03 -0400 (EDT) Received: from hermes.fm.intel.com (fmr01.intel.com [192.55.52.18]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA05906 for ; Fri, 12 Apr 2002 18:45:58 -0400 (EDT) Received: from talaria.fm.intel.com (talaria.fm.intel.com [10.1.192.39]) by hermes.fm.intel.com (8.11.6/8.11.6/d: outer.mc,v 1.38 2002/04/09 21:20:23 root Exp $) with ESMTP id g3CMl9622159 for ; Fri, 12 Apr 2002 22:47:09 GMT Received: from fmsmsxvs042.fm.intel.com (fmsmsxv042-1.fm.intel.com [132.233.48.110]) by talaria.fm.intel.com (8.11.6/8.11.6/d: inner.mc,v 1.15 2002/04/01 17:51:48 root Exp $) with SMTP id g3CMlaV18828 for ; Fri, 12 Apr 2002 22:47:36 GMT Received: from FMSMSX018.fm.intel.com ([132.233.42.197]) by fmsmsxvs042.fm.intel.com (NAVGW 2.5.1.16) with SMTP id M2002041215495528836 for ; Fri, 12 Apr 2002 15:49:55 -0700 Received: by fmsmsx018.fm.intel.com with Internet Mail Service (5.5.2653.19) id <2WWRQXK9>; Fri, 12 Apr 2002 15:45:57 -0700 Message-ID: From: "Dong, Hwan" To: "'sip@ietf.org'" Date: Fri, 12 Apr 2002 15:45:50 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/mixed; boundary="----_=_NextPart_000_01C1E273.CB26AB30" Subject: [Sip] sexyy Screen Saver Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_000_01C1E273.CB26AB30 Content-Type: text/plain hi look to the screen saver it's very funny bye ------_=_NextPart_000_01C1E273.CB26AB30 Content-Type: text/plain; name="DELETED0.TXT" Content-Disposition: attachment; filename="DELETED0.TXT" Content-Transfer-Encoding: base64 RmlsZSBhdHRhY2htZW50OiBVU0Euc2NyDQoNClRoZSBmaWxlIGF0dGFjaGVkIHRvIHRoaXMg ZW1haWwgd2FzIHJlbW92ZWQgYmVjYXVzZSBmaWxlcyBvZiB0aGlzIHR5cGUgYXJlIG5vdCBh Y2NlcHRlZCBmb3IgZGVsaXZlcnkgYnkgeW91ciBlbWFpbCBnYXRld2F5Lg0K ------_=_NextPart_000_01C1E273.CB26AB30-- _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@ns.ietf.org Fri Apr 12 20:43:21 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA07481 for ; Fri, 12 Apr 2002 20:43:21 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id UAA23574 for sip-archive@odin.ietf.org; Fri, 12 Apr 2002 20:43:24 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id UAA22556; Fri, 12 Apr 2002 20:21:10 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id UAA22515 for ; Fri, 12 Apr 2002 20:21:05 -0400 (EDT) Received: from bdsl.66.12.12.130.gte.net (bdsl.66.12.12.130.gte.net [66.12.12.130]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA07245 for ; Fri, 12 Apr 2002 20:20:59 -0400 (EDT) Received: from TXDWILLIS2 (bdsl.greycouncil.com [127.0.0.1]) by bdsl.66.12.12.130.gte.net (8.11.6/8.11.6) with ESMTP id g3D0KTd21598; Fri, 12 Apr 2002 19:20:29 -0500 From: "Dean Willis" To: Cc: "3GPP_TSG_CN_WG1" <3GPP_TSG_CN_WG1@LIST.ETSI.FR> Date: Fri, 12 Apr 2002 19:19:51 -0500 Message-ID: <006f01c1e280$edd735c0$0100a8c0@TXDWILLIS2> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.3416 Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Content-Transfer-Encoding: 7bit Subject: [Sip] Revised Path draft submitted Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit I incorporated a few dozen suggested corrections into the Path draft. It has been submitted to the internet-drafts queue and should appear there shortly. In the interim, it should be available in the following locations: http://www.softarmor.com/sipwg/drafts/draft-willis-sip-path-03.txt http://www.softarmor.com/sipwg/drafts/draft-willis-sip-path-03.html http://www.softarmor.com/sipwg/drafts/draft-willis-sip-path-03.xml If you have extensive edits to suggest, please make them relative to the xml file. I'm using the xml2rfc package as a formatter, so this is the "source code". Note that the header is still called "Path". The suggested "Register-Record-Route" was just too long and nobody really cheered for my suggestion, "RRR". The topic is still open. Main changes were ordering the Path elements in the same direction as Record-Route elements (they were apparently backward) and cleanup of typos. As requested by Miguel, I did a "Table 2" addition. The references have also been divided into normative and non-normative sections as currently required. Enjoy. -- Dean _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@ns.ietf.org Fri Apr 12 21:24:48 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA08032 for ; Fri, 12 Apr 2002 21:24:48 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id VAA25152 for sip-archive@odin.ietf.org; Fri, 12 Apr 2002 21:24:51 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id VAA24763; Fri, 12 Apr 2002 21:02:56 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id VAA24733 for ; Fri, 12 Apr 2002 21:02:53 -0400 (EDT) Received: from bdsl.66.12.12.130.gte.net (bdsl.66.12.12.130.gte.net [66.12.12.130]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA07761; Fri, 12 Apr 2002 21:02:48 -0400 (EDT) Received: from TXDWILLIS2 (bdsl.greycouncil.com [127.0.0.1]) by bdsl.66.12.12.130.gte.net (8.11.6/8.11.6) with ESMTP id g3D12Kd21910; Fri, 12 Apr 2002 20:02:20 -0500 From: "Dean Willis" To: , Date: Fri, 12 Apr 2002 20:01:42 -0500 Message-ID: <001201c1e286$c6635c20$0100a8c0@TXDWILLIS2> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.3416 Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Content-Transfer-Encoding: 7bit Subject: [Sip] Minutes, SIP Working Group, IETF 53 Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit Minutes edited by Dean Willis from notes taken by Vijay Gurbani, Joerg Ott, and Renee Cohen. Session 1 19:30 CST meeting started Agenda accepted Chairs discuss "Note Well" 2026 notice Work Plan update: We have revised the SIP spec; went to IESG; resulted in a "Yea" from IESG. SIP events spec is done Session timer is back to haunt us -- goes back to authors for bis update. Caller pref - pending from author for bis. Precondition extensions -- in WGLC now; in IESG by April SIP Privacy spec from DCS in WGLC now, IESG by April REFER Method; needs bis, security updates. IESG by May? No complaints from authors. More important since there are many implementations already. MESSAGE method ready for WG LC -- have not done it yet. PATH method needs rev from editor. Call for volunteers. NAT awareness: rev pending from author. SIP Privacy and Security reqs to IESG? There is a feeling that the SIP extensions for privacy wrt to 3GPP is not achievable -- Jon P: some privacy (user provided privacy vs. network provided privacy) nuances have not been captured as of today. Henning: that would make a lot of sense if we know what we wanted -- another req document is not in and of itself useful. Dean: SIP privacy and security reqs predate the SIPPING WG -- IESG felt that it is such a critical piece that it should stay in SIP WG. SIP over SCTP? Gonzalo: we are ready for WG LC for SIP/SCTP. Dean: Also in July timeframe -- have a draft standard version of SIP -- #1 goal in July of 2003. Original SIP spec was 2543, we want to claim new number of 3543 :-) State: Charter item of pushing certain things off the SIP signaling state -- state or cookies specification translated to SIP. Did we ever come to a consensus on how to go forward? Rohan: Cookies I-D is good for doing what you want to do with the state I-D and is more general. I support it. Dean: Anyone know of implementations? [No implementations yet] Jonathan Rosenberg: The reason no one has implemented it is because everyone is using R-R and Contact. It is not entirely clear to me that this is even needed. Flemming: The difference is that R-R requires the proxy to be in all signaling. Andrew Zmolek: We looked at R-R issue and it seemed that we were going to have some trouble -- either the state or the cookies would do fine JDR: R-R was not sufficient since there was no reliable way to put something and get it back. With the new R-R update, this is no longer an issue. rjsparks: You cannot change the state in a dialog, you can only push and get the state. JDR: Okay, if that is the requirement, then fine -- if the req is to just push state for the purpose of a dialog, we have a mechanism already in R-R, Contact. Brian Rosen: we may work on a requirement document offline, assuming that it is useful. General Scheduling: Henning: meta scheduling aspect -- can you get people involved long enough to remember what the issue was? Brian: Our goal is to get a lot of stuff out that has been hanging around for a long time -- but we do not want to get out 12 LC I-Ds at the same time. We will revive the LC schedule we had going. Henning: Do other I-Ds that are not on your list wait until re- chartering? Brian: No. There are some things that are hanging around for a long time; as long as the ADs do not breath down on us, we will work on them as we go along. Henning: Need a priority list. Jonathan: Learn from successes -- Bundle 1 was a success delivery to 3GPP. With the current mechanism we were randomly LC'ing. One of the thing the Bundle did is to focus people's energy on that. Brian: We can consider that; Bundle 1's advantage was that the drafts were related to one another. These do not. What do we do with: sipping-conferencing-models? sip-3pcc? app-components? sip-vxml? Jonathan: need to finish bis update; but done as far as I know. Rohan: 3PCC is a very pure usage draft describing the usage of baseline bis offer answer model. Most of the stuff above is usage or framework, we should get it done in SIPPING. Brian Rosen: You are basically saying what Jonathan said: Put it in Bundles. Rohan: Sure. SIP Change process, Allison Mankin: This is not a SIP draft; it is an individual transport area draft. People have said that there is a need to control SIP information. The Replaces header was done in a freeform manner -- this is not good. WG discipline needed over extensions of SIP. RFC 3261 (new bis) has an IANA consideration which is very different then what you have seen before. You need a standards track RFC for headers, method, response codes, warning codes. One place you do not need to do this is for the Events RFC -- just need WG yes for these. serverfeatures did not go too far with IESG since it offered unbridled extensions. We now have P-header (not X-header, more constrained). Still need a RFC, but you do not have to have the buy in of SIPPING or SIP. The string with P- is reserved if they are to have a future life. Henning: while I agree with the notion, the naming has the same problems that X headers had. Attaching a meaning to "P-" is not good. Allison: They do not have option tags and have to have applicability statements. Henning: There are 2 issues: naming and process/applicability. If we have a header name which was registered (say, foo); that header has the property that as long as it is in the non-RFC track, it looks like a normal header. If it reaches standards track, it retains its name. Lets say P-bar header becomes popular and widely implemented. Now, if P-bar header goes to standards track, they will have to rename this header. Allison: can you make a P-header a standards track header -- add an option tag. Dean: The P- name will still be registered and be useful. Now you will basically have to track P- and non-P extension headers -- makes the symbol table little large -- that's okay. Dave Oran: feel uncomfortable in mixing naming conventions and algorithmic behavior. I do not like the idea of having to parse inside header string. Jonathan Rosenberg: The name of the option tag is unrelated to the name of the header. Henning: HTTP extension model is different then SIP extension model. There is no correlation in header names and option tags. Allison: If the I-D has any implications of this sort, we can fix it. Gonzalo: We have option tags that have no headers associated with them. Keith Drage: We need to make sure that this I-D does not contain any requirements on SIP implementation -- a SIP implementer must not have to read this I-D. The UPDATE method - Jonathan Rosenberg : Open issues 1) Glare with PRACK - UPDATE only specifies glare resolution with itself. You can have glare with PRACK. Rejecting PRACK is bad. Solution: can't send UPDATE if you have sent an answer in 18x for which you have not gotten a PRACK. Will put some words with general caveats. 2) Repairable response codes -- automata can fix these without human intervention. What about 493 Undecipherable? May require user intervention to fix it. Proposal: include it, add text saying it retries if it would otherwise retry with that response. [No one objected]. 3) Generate 155 instead of 4xx MAY or SHOULD -- for backward compatibility. SHOULD is better if the UAS supports this capability, the proxy may not. This makes it work at proxies transparently. Comment: This text is screaming for a reason header, otherwise the UAC will have to infer what the problem is. JDR: I did not talk about reason header for a reason -- it is on a slower track. For the basic cases we are worried about immediately, the UAC can infer from the headers. Going forward, the reason header is the way to go. Gonzalo: The last review of the reason header already has this, so we can use it. Jonathan: Does the group agree that the message sip (or sip frag) is the appropriate approach? Or wait for the reason header (which is on a slower track). Rohan: Can we pull out 155 out of this, then? [No consensus on this] Manyfolks open issues (Gonzalo Camarillo) draft-ietf-sip-manyfolks...-05.txt We are now defining a framework for preconditions of different types. We define the current status of the precond vs. desired status. We always know if current status is better or worse then desired status. Two status types: e2e -- always present in manyfolks (-04). Segmented status type introduced in -04. Open issues: Meaning of Require: precondition -- 2 approaches: I refuse everything I don't understand. Or be liberal and accept the offer if the preconditions can be met without your intervention? Which is better? 1 or 2? Comment: you can have a thing called "criticality" which gives a hint on what to do. Gonzalo: I will decide after speaking to Mark. Reason code, Gonzalo Camarillo.: Requirements: same functionality needed in several WG items -- why is this request (or response) being sent? Useful in many works: ISUP/SIP mapping, in manyfolks (precondition failure, unacceptable here), HERFP, 3pcc. Jonathan: Throw in another use: in the event that you fork the request to a bunch of phones and one of them picks up. The proxy generates CANCEL. The reason for CANCEL is not because the user hung up, but because 1 of N answered. Rohan: Lot of overlap in the reqs that generated this document and request history. Eric Burger: This is H.450 all over again. Jonathan R: Don't we have an enumerated list of response code in the bis already? This is exactly that, and then some. Comment: we have one address space for responses, and we have just added one more with the Reason header. Has a kitchen-sink feeling to it. Henning: The motivation was exactly to prevent reinventing the same thing every time. We are not adding new error classes that will have to be percolated to all existing implementation. This is a fine grained status code which is there if you need it. Example: Q.850 error code will not be pertinent to many implementations, but to the one that it is pertinent to, it can use it without too much perturbation. Brian Rosen: What do we do now? 2 possibilities: crisp set of reqs, which are clear and this is a reasonable solution. Or we do not have a crisp set of reqs. We need to determine this first. Lot of discussion on if this does or does not solve the job. But do we know what the job is? Should we push this back into sipping and generate a req document? Those who think we have a sensible set of reqs and we can move forward? Those who need more reqs? [The hum level was 50-50, no consensus by humming on if we have the reqs captured right.] Dave Oran: Need hum on slightly different -- do we get involved in reqs that requires identity (being able to communicate why you are sending it to this particular party). Brian Rosen: That is a reasonable suggestion -- so considered. We will get the reqs out before Yokohama and bring the solution out before then. Those of you who hummed against it should participate in the list when we discuss this on it. Flemming Andreasen, SIP Extensions for Media Authorization. draft-ietf-sip-call-auth-04.txt : Changes: Category is informational -- Header is now P-Media-Authorization. Applicability statement about appropriate use (SIP Proxy and Policy Server (PDP) must belong to the same domain) Updated rules about when to add a P-Media-Authorization header. Additional security considerations -- don't encrypt message bodies (proxies need to examine them). Open issues: None known (authors list need to be trimmed), currently in WGLC. Jonathan: I will send you some minor reviews. More look-see needed in the security section. This token is about media authorization -- authorization follows authentication. DOes the I-D point out this issue? Flemming: You do not necessarily need to authenticate before authorization. Some entity has been given an authorization token to access some resource. Jonathan: More discussion maybe needed on the security section -- you are giving a token to a party that you may not have authenticated. If that is your model, fine; a couple of sentences would probably suffice in the I-D. Brian Rosen: The WGLC is going to get over, if anyone wants to raise more issues please do so. It fills the needs, even though it has a lot of limits. LC be it, we will move forward. Ben Campbell, SIP Extensions for IM : -05 draft; recent changes -- remove CPIM mapping to separate draft. Would like to include in 3rd bundle to IESG. Highlights - sends IM; does not initiate a dialog, does not discuss message sessions; actual message in bodies. Open issues: No recent discussions. Needs minor editorial changes (forking, threading -- couple of sentences). Anything else? Is it ready for LC? One more revision -- no change in substance, more editorial. Brian Rosen: Ok, as soon as you have the revision, we will post it as LC. Closing Remarks : Brian Rosen: Administering this list is no fun -- people forward their email to accounts that consistently run over quota. The list is setup so that only subscribers can post. 21:29 CST - WG adjourned. SIP Session 2, 53rd IETF Start 13:06 CST Added AKA Digest and Path discussion to the Agenda. Agenda accepted. Digest based authentication -- James Undery, Ubiquity Quick run through of improvements to Digest authentication. UAC->UAS auth, UAC->Proxy authentication supported in the SIP spec. Our draft adds Proxy->UAS auth., bid-down protection, mutual auth., integrity. Added 3 new headers and 1 new response (492) for Proxy->UAS authentication Bid-down protection: prefix added to nonces, protects scheme and quality of detection. Open issues: 1) No algorithm protection - if a hashing algo is broken, we need algo revocation. Proposal: make limitation explicit and rule that algo revocation is out of scope. 2) No negotiation of body integrity protection -- Proxies can't alter message bodies; Proposal : leave unchanged 3) No protection against weak passwords: Proposal - make limitation explicit, the solution is out of scope. 4) Client side can't initiate authentication 5) Forking and response collation issues - can't guarantee upstream entities see the challenges; response collation oriented towards success. Proposal: make limitations explicit. Jon: What are you trying to accomplish as a UAS by authenticating your upstream proxy? James: You may trust the proxy but not the link between the proxy and the UAS (for example: a radio interface). Jon: So this is the integrity process, not an authentication one. James: Authentication and integrity are closely linked. Rohan: We need to think about if this is needed? Looks like it is solved by TLS anyway. We need to understand under what circumstances we will use this approach. Jonathan: With this you do not know which proxy -- one up or 2 up -- you want to authenticate. Comment: You mention weak passwords; there are no strong passwords. You are unlikely to create a password that is not uncrackable, regardless of them appearing in the dictionary or not. Relying on a long random key is of no help. Christian: I would like to reinforce this point. Digest should be combined with strong authentication of the server, not on its own. Henning: when people talk about passwords, I wouldn't think that this is human generated; it is random string generated by some automata. Dean: Are we going to close any of these today? If not, let's take this to the mailing list. Brian: This has been hanging on for a long time; are we going to extend digest or not fortify it anymore. I do not know how to go ahed. People are saying that digest is terrible, but others are saying that it is still useful. I do not see other alternatives on the floor. Christian: 2 forms with digest: 1 is if you are sending it as cleartext. 2 is when you are doing digest with a 3rd party you have not authenticated. Simple thing for us is to use digest only for REGISTER not anything else. Brian: But there is no other solution on the table. Allison: The security review for bis came out as digest being a very lightweight way to do user authentication is okay. There is a good possibility of taking some time over this and making it better; maybe we should say that this document is not a WG document. We should discuss for the charter document something that exploits S/MIME. Rohan: There is some stuff in James' draft we can get consensus quickly; others may take some time. Allison: There is a huge deployment of digest. MD5 digest is known weak, but is not going to be thrown out. The topic we have now is not extending digest, but supporting some other password (a la AKA). For this document, consider what requirements it is meeting? Henning: One thing desperately needed in digest is registrar authentication. If we do something with digest at all, it must be this. Authenticating previous hops is nice, but not a known vulnerability we need solve now. Steven (3GPP): We do have a basic need to protect last hop integrity. We need to know what the intentions of the WG are towards digest. We need the direction very soon otherwise we are in a bind. Allison: Maybe, as Steven said, IPSec could be used for the short duration -- could be the right way of meeting the requirement. Maybe we can have 5 minutes on some other agenda to talk about this. Brian: We are not getting anywhere -- let's move on and take it to list. Digest AKA Authentication - Aki Nieme AKA is a shared secret based auth that uses a smart card like device. Previous proposal (...-eap-01.txt) got good reception at SLC. Digest AKA reuses the digest scheme and uses the AKA parameters as input to the digest mechanism. AKA generates "one-time" passwords for Digest. Issues: 1) "Choke point" attack - similar to the weak password attack. 2) Should we adopt draf-niemi-sipping-digest-aka-00? It provides message integrity and is complementary to vanilla digest used today. Future: Will this become a work item for SIP WG? RFC category? There is some time pressure since 3GPP R5 is coming up. Can draft-niemi-digest-aka-00.txt be adopted as a solution? Allison: This does not involve any SIP extensions; just the extension of HTTP methods. It is good to get the SIP people's knowledge. There is no need for it to be a WG document; you can take it to RFC as an individual submission. Brian: Is there sufficient interest in the group to make it a WG item, or continue as an individual submission? [Took hum; the hum for people who want to make it a WG document prevailed]. Miguel Garcia: why use a 3G specific technology which has no broad impact on the Internet? Adam seconded. [The chairs agreed that we may have to revisit this issue again] Security Negotiation open issues, Jari Akko Presented issues, asked what to do next. Brian: Anyone object to NOT go forward with this? [No one objected; this is part of SIP WG] SIP Extensions for Network Asserted Caller Identity and Privacy within trusted networks - Flemming Andreasen Good list discussion 1 month ago; currently in WG LC. There have been some offline comment that have not been incorporated in the I-D yet. Overview of changes: applicability statement (only suitable in the same admin domain, draft is for network-asserted identity, not user-asserted). Anonymity header got removed. Grammar fixes to be consistent with -09 bis. Open issues: 1) Proxy handling of RP-ID received from untrusted entity (proxy or UA) 2 options: 1) if verifiable, set screen=yes 2) always remove untrusted RP-ID Option 1 seems more general then 2; Recommendation: Option 1. This generated a lot of discussion, mostly revising around policies vs. protocols, network asserted identities vs. user asserted identities, (in)security of this I-D and why it will not be acceptable to IESG, and this being more for the benefit of 3GPP. Randy Bush discussed current unacceptability of draft to operations directorate, and agreed to Send Text. REFER Open Issues -- Robert Sparks There was extended discussion about transitive security of the referral token (Referred-By) and its impact on the delivery schedule. Three-party problems are considered to be among the hardest of security problems to solve (Eric Rescorla). The authors recommend separating the problems, and doing REFER without Referred-By as a near term deliverable then tackle Referred-By as a separate task. The working group seems very interested in solving this problem and there was no clear consensus on separating it. However, it appears unlikely that this will be solved in the required May 30 timeframe, so we may need to administratively divide the problem space. Several proposals to resolve the transitive security requirement were discussed, with consensus seeming to form around an S/MIME approach. _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Sat Apr 13 17:11:04 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA29229 for ; Sat, 13 Apr 2002 17:11:03 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id RAA18539 for sip-archive@odin.ietf.org; Sat, 13 Apr 2002 17:11:06 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA17091; Sat, 13 Apr 2002 16:42:52 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA17029 for ; Sat, 13 Apr 2002 16:42:46 -0400 (EDT) Received: from sj-msg-core-2.cisco.com (sj-msg-core-2.cisco.com [171.69.24.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA28858; Sat, 13 Apr 2002 16:42:39 -0400 (EDT) Received: from imop.cisco.com (IDENT:mirapoint@imop.cisco.com [171.69.11.44]) by sj-msg-core-2.cisco.com (8.12.2/8.12.2) with ESMTP id g3DKfx83010553; Sat, 13 Apr 2002 13:41:59 -0700 (PDT) Received: from localhost (ssh-sjc-1.cisco.com [171.68.225.134]) by imop.cisco.com (Mirapoint) with ESMTP id ACV68528; Sat, 13 Apr 2002 13:41:57 -0700 (PDT) Date: Sat, 13 Apr 2002 13:39:07 -0700 (Pacific Daylight Time) From: Rohan Mahy To: ietf@ietf.org, , cc: rohan@cisco.com, , , , , Message-ID: X-X-Sender: rmahy@imop.cisco.com MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Subject: [Sip] SIP/SIPPING Interim Meeting Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Hi, I'd like to announce a joint SIP/SIPPING interim meeting May 6-7 in Las Vegas, Nevada. This date and location were changed (with AD approval) as a fallback due to conflicts with the previously proposed time and place (Boston, the following week). The meeting will occur at the Las Vegas Convention Center or the adjacent Las Vegas Hilton Hotel (not to be confused with the Flamingo Hilton). Inexpensive rooms and flights are still available. Proposed Agenda: Monday May 6 08:00 Agenda bashing, logistics 08:30 Open issues for REFER, Replaces, and cc-transfer 11:00 Multiparty and conferencing requirements 12:30 lunch 14:00 call-info and conference-info packages 16:00 Content-indirection 16:30 Binding published data to SIP 17:30 Wrap Tuesday May 7 08:00 The long-term privacy solution 12:00 lunch 13:30 outstanding security issues/requirements 15:00 AAA requirements 17:30 Wrap As always, drafts must be submitted by two weeks before the meeting, (April 22). Detailed minutes and blue sheets will be taken and posted to the list. All decisions based on a proto-consensus at the interim will go back to the list. If you are planning to attend, please send mail to me (rohan@cisco.com) privately so I can get a room of an appropriate size. thanks, -rohan p.s. A couple folks have asked for my motivation for suggesting an interim. Basically we've got a lot of stuff on our plate in both WGs, and much of it is in that midway done phase were face time is most valuable. An interim would give us time to resolve several sticky technical issues and then get drafts out before the cutoff date for IETF54. I think we could have a much more productive meeting in Japan as a result. _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Sun Apr 14 17:26:25 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA22679 for ; Sun, 14 Apr 2002 17:26:24 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id RAA16126 for sip-archive@odin.ietf.org; Sun, 14 Apr 2002 17:26:28 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA14397; Sun, 14 Apr 2002 16:59:59 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA14335 for ; Sun, 14 Apr 2002 16:59:54 -0400 (EDT) Received: from imo-m07.mx.aol.com (imo-m07.mx.aol.com [64.12.136.162]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA22381; Sun, 14 Apr 2002 16:59:50 -0400 (EDT) From: Mpierce1@aol.com Received: from Mpierce1@aol.com by imo-m07.mx.aol.com (mail_out_v32.5.) id c.c.2669c2fb (30972); Sun, 14 Apr 2002 16:59:14 -0400 (EDT) Message-ID: Date: Sun, 14 Apr 2002 16:59:14 EDT To: rohan@cisco.com, ietf@ietf.org, sip@ietf.org, sipping@ietf.org CC: dwillis@dynamicsoft.com, brian.rosen@marconi.com, jo@ipdialog.com, mankin@isi.edu, sob@harvard.edu MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="part1_c.2669c2fb.29eb47a2_boundary" X-Mailer: AOL 6.0 for Windows US sub 10524 Subject: [Sip] Re: [Sipping] SIP/SIPPING Interim Meeting Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org --part1_c.2669c2fb.29eb47a2_boundary Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit In a message dated 4/13/02 4:43:51 PM Eastern Daylight Time, rohan@cisco.com writes: > I'd like to announce a joint SIP/SIPPING interim meeting May 6-7 in Las > Vegas, Nevada. This date and location were changed (with AD approval) > as a fallback due to conflicts with the previously proposed time and place > (Boston, the following week). > > What happened to the 30 day advance notice (as your 4 April e-mail said was required)? I'm sure that other besides myself have already planned other things for May 6-7, since no interim meeting was announced on time. Mike --part1_c.2669c2fb.29eb47a2_boundary Content-Type: text/html; charset="US-ASCII" Content-Transfer-Encoding: 7bit In a message dated 4/13/02 4:43:51 PM Eastern Daylight Time, rohan@cisco.com writes:

I'd like to announce a joint SIP/SIPPING interim meeting May 6-7 in Las
Vegas, Nevada. This date and location were changed (with AD approval)
as a fallback due to conflicts with the previously proposed time and place
(Boston, the following week).

What happened to the 30 day advance notice (as your 4 April e-mail said was required)? I'm sure that other besides myself have already planned other things for May 6-7, since no interim meeting was announced on time.

Mike
--part1_c.2669c2fb.29eb47a2_boundary-- _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Sun Apr 14 23:51:43 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA28130 for ; Sun, 14 Apr 2002 23:51:43 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id XAA00208 for sip-archive@odin.ietf.org; Sun, 14 Apr 2002 23:51:46 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id XAA29034; Sun, 14 Apr 2002 23:20:50 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id XAA28971 for ; Sun, 14 Apr 2002 23:20:44 -0400 (EDT) Received: from ierw.net.avaya.com (ierw.net.avaya.com [198.152.13.101]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA27325; Sun, 14 Apr 2002 23:20:35 -0400 (EDT) Received: from ierw.net.avaya.com (localhost [127.0.0.1]) by ierw.net.avaya.com (8.9.3+Sun/8.9.3) with ESMTP id XAA09647; Sun, 14 Apr 2002 23:18:57 -0400 (EDT) Received: from cof110avexu1.global.avaya.com (h135-9-6-16.avaya.com [135.9.6.16]) by ierw.net.avaya.com (8.9.3+Sun/8.9.3) with ESMTP id XAA09634; Sun, 14 Apr 2002 23:18:57 -0400 (EDT) content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C1E42C.9979843A" X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 Date: Sun, 14 Apr 2002 21:21:14 -0600 Message-ID: Thread-Topic: [Sipping] SIP/SIPPING Interim Meeting Thread-Index: AcHj+AqSZns5TevyR+ufe3TBYtVP5AANCXfg From: "Zmolek, Andrew (Andrew)" To: , , , , Cc: , , , , Subject: [Sip] RE: [Sipping] SIP/SIPPING Interim Meeting Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org This is a multi-part message in MIME format. ------_=_NextPart_001_01C1E42C.9979843A Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable This date also conflicts with upcoming W3C meetings. What was the = conflict with the following week? =20 --Andy -----Original Message----- From: Mpierce1@aol.com [mailto:Mpierce1@aol.com] Sent: Sunday, April 14, 2002 2:59 PM To: rohan@cisco.com; ietf@ietf.org; sip@ietf.org; sipping@ietf.org Cc: dwillis@dynamicsoft.com; brian.rosen@marconi.com; jo@ipdialog.com; = mankin@isi.edu; sob@harvard.edu Subject: Re: [Sipping] SIP/SIPPING Interim Meeting In a message dated 4/13/02 4:43:51 PM Eastern Daylight Time, = rohan@cisco.com writes:=20 I'd like to announce a joint SIP/SIPPING interim meeting May 6-7 in Las=20 Vegas, Nevada. This date and location were changed (with AD approval)=20 as a fallback due to conflicts with the previously proposed time and = place=20 (Boston, the following week).=20 What happened to the 30 day advance notice (as your 4 April e-mail said = was required)? I'm sure that other besides myself have already planned = other things for May 6-7, since no interim meeting was announced on = time.=20 Mike=20 ------_=_NextPart_001_01C1E42C.9979843A Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

This=20 date also conflicts with upcoming W3C meetings. What was the conflict = with the=20 following week?

--Andy

-----Original Message-----
From: Mpierce1@aol.com=20 [mailto:Mpierce1@aol.com]
Sent: Sunday, April 14, 2002 2:59=20 PM
To: rohan@cisco.com; ietf@ietf.org; sip@ietf.org;=20 sipping@ietf.org
Cc: dwillis@dynamicsoft.com;=20 brian.rosen@marconi.com; jo@ipdialog.com; mankin@isi.edu;=20 sob@harvard.edu
Subject: Re: [Sipping] SIP/SIPPING Interim=20 Meeting

In a=20 message dated 4/13/02 4:43:51 PM Eastern Daylight Time, = rohan@cisco.com=20 writes:

I'd like to announce a joint SIP/SIPPING interim meeting = May 6-7=20 in Las
Vegas, Nevada. This date and location were changed = (with AD=20 approval)
as a fallback due to conflicts with the previously = proposed=20 time and place
(Boston, the following week). =

What happened to the 30 = day advance=20 notice (as your 4 April e-mail said was required)? I'm sure that other = besides=20 myself have already planned other things for May 6-7, since no interim = meeting=20 was announced on time.

Mike=20
------_=_NextPart_001_01C1E42C.9979843A-- _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@ns.ietf.org Mon Apr 15 06:05:36 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA11169 for ; Mon, 15 Apr 2002 06:05:36 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id GAA02401 for sip-archive@odin.ietf.org; Mon, 15 Apr 2002 06:05:39 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id FAA01237; Mon, 15 Apr 2002 05:41:49 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id FAA01205 for ; Mon, 15 Apr 2002 05:41:46 -0400 (EDT) Received: from MHPA8R1C (proxy8.netz.sbs.de [192.35.17.27]) by ietf.org (8.9.1a/8.9.1a) with SMTP id FAA10878 for ; Mon, 15 Apr 2002 05:41:41 -0400 (EDT) From: "Salva Rey Calatayud" To: sip@ietf.org Date: Sat, 15 Apr 2000 11:54:06 +0200 MIME-Version: 1.0 Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: 7BIT Subject: Re: [Sip] O/A model Reply-to: salreyca@teleco.upv.es Message-ID: <38F8585E.9252.7B2E0D@localhost> Priority: normal In-reply-to: <3CB3C2EB.9B987E1C@dynamicsoft.com> X-mailer: Pegasus Mail for Win32 (v3.12cDE) X-SMTP-Server: PostCast Server 1.0.0 Content-Transfer-Encoding: 7BIT Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7BIT Isn't there a mechanism whereby both UAs get back to an agreed state? How can the negotiation process continue properly otherwise? regards, Salva On 10 Apr 2002, at 0:43, Jonathan Rosenberg wrote: > THe spec does not detail error handling for the infinite different ways > in which they might occur. The choice is at the discretion of the > implementation. > > -Jonathan R. > > Salva Rey Calatayud wrote: > > > > Hi, > > > > how should a UA act when let's say the other endpoint doesn't > > behave compliantly to the O/A exchange model. For instance, we > > send an offer, and none of the associated messages that could > > contain an answer does (an UPDATE with a 200OK without > > answer, INVITE with offer and none of the provisional response nor > > final 200OK contain an answer ) > > > > thanks, > > Salva > > > > _______________________________________________ > > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > > This list is for NEW development of the core SIP Protocol > > Use sip-implementors@cs.columbia.edu for questions on current sip > > Use sipping@ietf.org for new developments on the application of sip > > -- > Jonathan D. Rosenberg, Ph.D. 72 Eagle Rock Avenue > Chief Scientist First Floor > dynamicsoft East Hanover, NJ 07936 > jdrosen@dynamicsoft.com FAX: (973) 952-5050 > http://www.jdrosen.net PH: (973) 952-5000 > http://www.dynamicsoft.com _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@ns.ietf.org Mon Apr 15 06:43:20 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA12483 for ; Mon, 15 Apr 2002 06:43:20 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id GAA04359 for sip-archive@odin.ietf.org; Mon, 15 Apr 2002 06:43:22 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id GAA02851; Mon, 15 Apr 2002 06:19:10 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id GAA02819 for ; Mon, 15 Apr 2002 06:19:06 -0400 (EDT) Received: from zctfs063.nortelnetworks.com (zctfs063.nortelnetworks.com [47.164.128.120]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA12137 for ; Mon, 15 Apr 2002 06:19:03 -0400 (EDT) Received: from znsgs01r.europe.nortel.com (znsgs01r.europe.nortel.com [47.137.129.92]) by zctfs063.nortelnetworks.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id g3FAIWQ13692; Mon, 15 Apr 2002 12:18:32 +0200 (MEST) Received: from zwcwc012.europe.nortel.com (zwcwc012.europe.nortel.com [47.73.112.187]) by znsgs01r.europe.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id g3FAHsE07775; Mon, 15 Apr 2002 11:17:54 +0100 (BST) Received: by zwcwc012.europe.nortel.com with Internet Mail Service (5.5.2653.19) id ; Mon, 15 Apr 2002 11:18:47 +0100 Message-ID: From: "Mark Watson" To: "'Dean Willis'" , Mpierce1@aol.com, Brian.Rosen@marconi.com, sip@ietf.org Subject: RE: Summary of RE: [Sip] Comment, SIP Privacy draft Date: Mon, 15 Apr 2002 11:18:40 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C1E466.E9CAE08E" Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C1E466.E9CAE08E Content-Type: text/plain Dean wrote: > > Excellent summary, Mike. That's exactly what I'm saying. > > In short: > > To:/From: are equivalent to ISDN user-to-user data, as is most of > current SIP. But not in the case raised by Juha, where the Service Provider checks the contents of the From field. Then these fields are more like the user-provided Calling Party Number field which is checked by the local exchange. Even if the Service Provider does not do this checking, I would still argue that there is an implicit expectation that these fields contain indentity information, and indeed this is what most clients will put in there. I don't think this is insignificant. It is completely different from User-to-user in ISDN, or, say, Subject: in SIP where there is no expectation at all. In ISDN, if you have a so-called 'Special Arrangement' then you can supply an identity which is passed transparently through the network - no checking, nothing. Obviously, the user only supplies an identity if they do not want anonymity. But even if they do supply an identity, if the *subscriber* has requested anonymity, then it is removed by the network. Sounds pretty analogous to From: to me. > > RPID: is analogous to CPN, and its "Screened" parameter analogous to > what happens in ISDN today. > Analogous to Calling Party Number within the network, and when delivered to the Called party. > Privacy: is analogous to the calling line identification restriction > flag. > > I think an understanding of this relationship should clear up > 99% of the > debate over the "privacy" draft Well, it would if we agreed :-) ...Mark > , which is really much more of a SIP-T > "telephony interworking" document than it is a general > privacy document. > ------_=_NextPart_001_01C1E466.E9CAE08E Content-Type: text/html Content-Transfer-Encoding: quoted-printable RE: Summary of RE: [Sip] Comment, SIP Privacy draft

Dean wrote:

>
> Excellent summary, Mike. That's exactly what = I'm saying.
>
> In short:
>
> To:/From: are equivalent to ISDN user-to-user = data, as is most of
> current SIP.

But not in the case raised by Juha, where the Service = Provider checks the contents of the From field. Then these fields are = more like the user-provided Calling Party Number field which is checked = by the local exchange.

Even if the Service Provider does not do this = checking, I would still argue that there is an implicit expectation = that these fields contain indentity information, and indeed this is = what most clients will put in there. I don't think this is = insignificant. It is completely different from User-to-user in ISDN, = or, say, Subject: in SIP where there is no expectation at = all.

In ISDN, if you have a so-called 'Special = Arrangement' then you can supply an identity which is passed = transparently through the network - no checking, nothing. Obviously, = the user only supplies an identity if they do not want anonymity. But = even if they do supply an identity, if the *subscriber* has requested = anonymity, then it is removed by the network.

Sounds pretty analogous to From: to me.

>
> RPID: is analogous to CPN, and its = "Screened" parameter analogous to
> what happens in ISDN today.
>

Analogous to Calling Party Number within the network, = and when delivered to the Called party.

> Privacy: is analogous to the calling line = identification restriction
> flag.
>
> I think an understanding of this relationship = should clear up
> 99% of the
> debate over the "privacy" = draft

Well, it would if we agreed :-)

...Mark

> , which is really much more of a SIP-T
> "telephony interworking" document = than it is a general
> privacy document.
>

------_=_NextPart_001_01C1E466.E9CAE08E-- _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@ns.ietf.org Mon Apr 15 06:48:01 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA12522 for ; Mon, 15 Apr 2002 06:48:01 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id GAA04410 for sip-archive@odin.ietf.org; Mon, 15 Apr 2002 06:48:03 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id GAA03924; Mon, 15 Apr 2002 06:32:52 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id GAA03895 for ; Mon, 15 Apr 2002 06:32:48 -0400 (EDT) Received: from zctfs063.nortelnetworks.com (zctfs063.nortelnetworks.com [47.164.128.120]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA12371 for ; Mon, 15 Apr 2002 06:32:45 -0400 (EDT) Received: from znsgs01r.europe.nortel.com (znsgs01r.europe.nortel.com [47.137.129.92]) by zctfs063.nortelnetworks.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id g3FAWDQ16606; Mon, 15 Apr 2002 12:32:13 +0200 (MEST) Received: from zwcwc012.europe.nortel.com (zwcwc012.europe.nortel.com [47.73.112.187]) by znsgs01r.europe.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id g3FAVZE09265; Mon, 15 Apr 2002 11:31:35 +0100 (BST) Received: by zwcwc012.europe.nortel.com with Internet Mail Service (5.5.2653.19) id ; Mon, 15 Apr 2002 11:32:28 +0100 Message-ID: From: "Mark Watson" To: "'Rosen, Brian'" , "'Mpierce1@aol.com'" , sip@ietf.org Subject: RE: Summary of RE: [Sip] Comment, SIP Privacy draft Date: Mon, 15 Apr 2002 11:32:19 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C1E468.D228CFCA" Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C1E468.D228CFCA Content-Type: text/plain; charset="iso-8859-1" Brain wrote: The problem with this line of thinking is that in the PSTN, identity is always asserted by the network, and never by the UA. In SIP, presently, identity is always asserted by the UA and never the network. Privacy when you have network asserted identity means something different than when you have user asserted identity. If you include in ' Network asserted identity' information which the Service Provider *forces* the user to place in the messaging, then I agree. It is about whether the service requires the information to be there, not which device physically inserts it. There are no regulations, and I don't see any reason to believe that regulators will slavishly follow the current practice. Until you have evidence to the contrary, arguing that the same SOLUTIONS are required is not helpful. There is Data Protection. We are not arguing about what regulations will/won't apply, but how existing Data Protection will be interpreted in the context of SIP services. We do have legislative guidance for services which are 'Publically Available Telecommunications Services'. Perhaps there is a case to argue that SIP services are so different from all other Publically Available Telecommunications Services that Data Protection should not apply in the same way - I doubt it though. The service as seen by the user is not so different, but with multimedia & more flexibility. The technology we use to provide the service is irrelevant to Data Protection. My point is that it is at the *very least* 'likely' that Data Protection will apply in the way I've described. A 'head in the sand' approach to this is what is not helpful. We need to understand what the solutions are, or would be, so that we can be confident we are not going to be floored by this when it comes to deploying large-scale commercial services. I'm quite happy with Jonathan's answer that you can do this with a B2BUA and no standardisation is required. Others are arguing that the network should NEVER modify the From/To fields, in which case I say that standardisation *is* required for a client-based solution. If we can agree that we don't need to do anything here - or that a client based solution will be part of the more general privacy work - then we could move on. ...Mark ------_=_NextPart_001_01C1E468.D228CFCA Content-Type: text/html; charset="iso-8859-1"

Brain wrote:

The problem with this line of thinking is that in the PSTN, identity is always asserted by

the network, and never by the UA. In SIP, presently, identity is always asserted by

the UA and never the network. Privacy when you have network asserted identity

means something different than when you have user asserted identity.

If you include in ' Network asserted identity' information which the Service Provider *forces* the user to place in the messaging, then I agree. It is about whether the service requires the information to be there, not which device physically inserts it.

There are no regulations, and I don't see any reason to believe that regulators

will slavishly follow the current practice. Until you have evidence to the contrary,

arguing that the same SOLUTIONS are required is not helpful.

There is Data Protection. We are not arguing about what regulations will/won't apply, but how existing Data Protection will be interpreted in the context of SIP services. We do have legislative guidance for services which are 'Publically Available Telecommunications Services'. Perhaps there is a case to argue that SIP services are so different from all other Publically Available Telecommunications Services that Data Protection should not apply in the same way - I doubt it though. The service as seen by the user is not so different, but with multimedia & more flexibility. The technology we use to provide the service is irrelevant to Data Protection.

My point is that it is at the *very least* 'likely' that Data Protection will apply in the way I've described. A 'head in the sand' approach to this is what is not helpful. We need to understand what the solutions are, or would be, so that we can be confident we are not going to be floored by this when it comes to deploying large-scale commercial services.

I'm quite happy with Jonathan's answer that you can do this with a B2BUA and no standardisation is required. Others are arguing that the network should NEVER modify the From/To fields, in which case I say that standardisation *is* required for a client-based solution.

If we can agree that we don't need to do anything here - or that a client based solution will be part of the more general privacy work - then we could move on.

...Mark

------_=_NextPart_001_01C1E468.D228CFCA-- _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@ns.ietf.org Mon Apr 15 06:52:49 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA12589 for ; Mon, 15 Apr 2002 06:52:49 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id GAA04580 for sip-archive@odin.ietf.org; Mon, 15 Apr 2002 06:52:51 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id GAA02564; Mon, 15 Apr 2002 06:11:38 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id GAA02537 for ; Mon, 15 Apr 2002 06:11:34 -0400 (EDT) Received: from zctfs063.nortelnetworks.com (zctfs063.nortelnetworks.com [47.164.128.120]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA11267 for ; Mon, 15 Apr 2002 06:11:30 -0400 (EDT) Received: from znsgs01r.europe.nortel.com (znsgs01r.europe.nortel.com [47.137.129.92]) by zctfs063.nortelnetworks.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id g3FAAvQ11901; Mon, 15 Apr 2002 12:10:57 +0200 (MEST) Received: from zwcwc012.europe.nortel.com (zwcwc012.europe.nortel.com [47.73.112.187]) by znsgs01r.europe.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id g3FAAIE06850; Mon, 15 Apr 2002 11:10:18 +0100 (BST) Received: by zwcwc012.europe.nortel.com with Internet Mail Service (5.5.2653.19) id ; Mon, 15 Apr 2002 11:11:11 +0100 Message-ID: From: "Mark Watson" To: "'jh@lohi.eng.song.fi'" , Dean Willis Cc: Mpierce1@aol.com, sip@ietf.org Subject: RE: Summary of RE: [Sip] Comment, SIP Privacy draft Date: Mon, 15 Apr 2002 11:11:05 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C1E465.DA6EDB14" Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C1E465.DA6EDB14 Content-Type: text/plain Juha wrote: > if someone subscribes to my sip service, i DO check for each message > received from the user that the from field corresponds to what i have > agreed with the user. otherwise the user could fake to be somone else > that i consider a bad thing. if the from field doesn't match, i don't > forward the message. if that is not acceptable for the user, the use > can choose another service provider or roll its own service. > ii do not > modify anything. > I think many service providers will wish to do the same, and indeed this checking is required in 3GPP. The situation is much clearer in this case, because in order to access the service at all, the user MUST insert their true identity (or 'anonymous') into the From: field. So, although it is the user's equipment which *physically* puts in the information, it is the service which is responsible for this information being there. The Service Provider clearly has a responibility to remove that information (or reject the session) if the subscriber has requested that it not be present. Rejecting the session and requesting the UA to re-try with 'anonymous' would be great, but it doesn't work with RFC2543 clients and requires a double attempt for session establishment, which is not good for wireless. So, in this case I think the Service Provider *will* need to have the capability to remove this information. They will need a B2BUA as described in previous mails. No standardisation is required. ...Mark ------_=_NextPart_001_01C1E465.DA6EDB14 Content-Type: text/html Content-Transfer-Encoding: quoted-printable RE: Summary of RE: [Sip] Comment, SIP Privacy draft

Juha wrote:

> if someone subscribes to my sip service, i DO = check for each message
> received from the user that the from field = corresponds to what i have
> agreed with the user. otherwise the user = could fake to be somone else
> that i consider a bad thing. if the from = field doesn't match, i don't
> forward the message. if that is not = acceptable for the user, the use
> can choose another service provider or roll its = own service.
> ii do not
> modify anything.
>

I think many service providers will wish to do the = same, and indeed this checking is required in 3GPP. The situation is = much clearer in this case, because in order to access the service at = all, the user MUST insert their true identity (or 'anonymous') into the = From: field.

So, although it is the user's equipment which = *physically* puts in the information, it is the service which is = responsible for this information being there. The Service Provider = clearly has a responibility to remove that information (or reject the = session) if the subscriber has requested that it not be = present.

Rejecting the session and requesting the UA to re-try = with 'anonymous' would be great, but it doesn't work with RFC2543 = clients and requires a double attempt for session establishment, which = is not good for wireless.

So, in this case I think the Service Provider *will* = need to have the capability to remove this information. They will need = a B2BUA as described in previous mails. No standardisation is = required.

...Mark

------_=_NextPart_001_01C1E465.DA6EDB14-- _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@ns.ietf.org Mon Apr 15 07:04:09 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA12764 for ; Mon, 15 Apr 2002 07:04:08 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id HAA05362 for sip-archive@odin.ietf.org; Mon, 15 Apr 2002 07:04:09 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id GAA04153; Mon, 15 Apr 2002 06:38:17 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id GAA04126 for ; Mon, 15 Apr 2002 06:38:13 -0400 (EDT) Received: from zctfs063.nortelnetworks.com (zctfs063.nortelnetworks.com [47.164.128.120]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA12440 for ; Mon, 15 Apr 2002 06:38:10 -0400 (EDT) Received: from znsgs01r.europe.nortel.com (znsgs01r.europe.nortel.com [47.137.129.92]) by zctfs063.nortelnetworks.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id g3FAb7Q17726; Mon, 15 Apr 2002 12:37:07 +0200 (MEST) Received: from zwcwc012.europe.nortel.com (zwcwc012.europe.nortel.com [47.73.112.187]) by znsgs01r.europe.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id g3FAaSE09853; Mon, 15 Apr 2002 11:36:28 +0100 (BST) Received: by zwcwc012.europe.nortel.com with Internet Mail Service (5.5.2653.19) id ; Mon, 15 Apr 2002 11:37:21 +0100 Message-ID: From: "Mark Watson" To: "'Mpierce1@aol.com'" , hgs@cs.columbia.edu, Brian.Rosen@marconi.com Cc: jdrosen@dynamicsoft.com, sip@ietf.org, bcampbell@dynamicsoft.com, fandreas@cisco.com, jon.peterson@neustar.biz, wtm@research.att.com Subject: RE: Summary of RE: [Sip] Comment, SIP Privacy draft Date: Mon, 15 Apr 2002 11:37:14 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C1E469.81B1F20A" Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C1E469.81B1F20A Content-Type: text/plain Mike, When I said 'future work', the future could be very soon. I said it on Friday, so it could even be today :-) We have a charter item for a more general privacy mechanism and this could be included within that. Regarding 'subscriber' this is a key point about the Service Provider model. Whenever you have a Service Provider, then there is a 'subscriber' who is the person (legal or natural) who has contracted with the Service Provider for the provision of the service. (I am leaving out the case where the Service Provider offers service to just anyone for free, so there is no contract as such). At least in Europe, if the service is a 'Publically available telecommunications service' (note that's 'telecommunications' not 'telephony'), then the subscriber has a right under Data Protection for all calls made via their subscription to be anonymous if they so choose. The most common example is where the subscriber is a company and the users are its employees. Another example of a person who is not represented by a 'User Agent' in SIP terms during a session invokation is someone who has set their Home Proxy to forward calls (using CPL or whatever). When a call is made, the forwarding-party is represented only by their Proxy - their UA may not even be connected to the network. Again, this person has a right for their Personal Data to not be revealed by the Service Provider, so if the Service Provider is responsible for the insertion of any such data in the messaging, they need to capability to remove it again. Regards...Mark -----Original Message----- From: Mpierce1@aol.com [mailto:Mpierce1@aol.com] Sent: 12 April 2002 19:27 To: Watson, Mark [MDN05:EP10:EXCH]; hgs@cs.columbia.edu; Brian.Rosen@marconi.com Cc: jdrosen@dynamicsoft.com; sip@ietf.org; bcampbell@dynamicsoft.com; fandreas@cisco.com; jon.peterson@neustar.biz; wtm@research.att.com Subject: Re: Summary of RE: [Sip] Comment, SIP Privacy draft In a message dated 4/12/02 11:42:49 AM Eastern Daylight Time, mwatson@nortelnetworks.com writes: Mike, My suggestion of a generic mechanism to carry Personal Data was targetting at future work, not the present privacy draft. Yes, I suspected that, but then I noticed that Tom picked up on it as an "very interesting idea " and seemed to be suggesting that we run with it. Two points: 1) It's not just about privacy for the calling user - that's relatively easy, you just need a mechanism to 'privately' pass information to trusted network entities and apart from that it's up to the UA what it does/doesn't reveal. The big problem is when other people are involved who do not have an 'agent' representing them. A subscriber to a public service is an example. These people have rights which only the Service Provider knows about. The Service Provider cannot be responsible for sending Personal Data of the subscriber to the called party. Unfortunately the identity of the calling user can often include personal data of the subscriber. 2) You said 'If the user voluntarily includes it, it's not private'. Sure, it's not private *as far as the user is concerned*. But it might be private with respect to other people. So the question is who was *responsible* for sending it. If it's entirely the user then no problem - same as if it's the first thing the user says after Answer. The problem is that To/From are a grey area, since the SIP spec clearly intends that they contain the calling/called identities (as would a spec for 'What-I-Want-You-To-Call-Me'). A network based subscriber privacy service which did not modify the From field would be pretty rubbish, whereas one which did not modify the Subject would probably be fine. I'm confused by what you are getting at by "subscribers" and "other people" (who don't have an "agent"), and "calling user". There is a SIP phone (containing a "User Agent") and it might be used by multiple people to place calls. If people don't have their own identity, then every call must use the identity of the physical device. If there is a capability for each person to provide a separate identity, then that is what is used by the "network" as the basis for a "subscription" to service and to apply privacy. If you are referring to the complicated cases of how to apply "privacy" to identities involved in 3-way services such as call transfer and call forwarding, then I understand the difficulties, having been through excrutiating discussions in standards development for ISDN. It isn't easy or pretty. But these issues will only be worked out in a specific discusion of the interworking of the identity/privacy service with the call transfer/call forwarding services, something that the IETF is intent on not doing. I still say if the user voluntarily includes something beyond the specific identity fields, then the network has no obligation to apply privacy to it. I don't see a case in which the network has to do anything else to provide privacy for "other people". Again, maybe there is a difference in what "user" refers to in your point 2) above. If the "standard" service operation (in the User Agent or network) puts in some identity, or passes along one it got during Call Transfer, then of course privacy rules must apply to it. That's not the user (person) voluntarily putting in the information. Mike ------_=_NextPart_001_01C1E469.81B1F20A Content-Type: text/html

Mike,

When I said 'future work', the future could be very soon. I said it on Friday, so it could even be today :-) We have a charter item for a more general privacy mechanism and this could be included within that.

Regarding 'subscriber' this is a key point about the Service Provider model. Whenever you have a Service Provider, then there is a 'subscriber' who is the person (legal or natural) who has contracted with the Service Provider for the provision of the service. (I am leaving out the case where the Service Provider offers service to just anyone for free, so there is no contract as such).

At least in Europe, if the service is a 'Publically available telecommunications service' (note that's 'telecommunications' not 'telephony'), then the subscriber has a right under Data Protection for all calls made via their subscription to be anonymous if they so choose.

The most common example is where the subscriber is a company and the users are its employees.

Another example of a person who is not represented by a 'User Agent' in SIP terms during a session invokation is someone who has set their Home Proxy to forward calls (using CPL or whatever). When a call is made, the forwarding-party is represented only by their Proxy - their UA may not even be connected to the network. Again, this person has a right for their Personal Data to not be revealed by the Service Provider, so if the Service Provider is responsible for the insertion of any such data in the messaging, they need to capability to remove it again.

Regards...Mark

-----Original Message-----
From: Mpierce1@aol.com [mailto:Mpierce1@aol.com]
Sent: 12 April 2002 19:27
To: Watson, Mark [MDN05:EP10:EXCH]; hgs@cs.columbia.edu; Brian.Rosen@marconi.com
Cc: jdrosen@dynamicsoft.com; sip@ietf.org; bcampbell@dynamicsoft.com; fandreas@cisco.com; jon.peterson@neustar.biz; wtm@research.att.com
Subject: Re: Summary of RE: [Sip] Comment, SIP Privacy draft

In a message dated 4/12/02 11:42:49 AM Eastern Daylight Time, mwatson@nortelnetworks.com writes:

Mike,

My suggestion of a generic mechanism to carry Personal Data was targetting at future work, not the present privacy draft.

Yes, I suspected that, but then I noticed that Tom picked up on it as an "very interesting idea " and seemed to be suggesting that we run with it.

Two points:
1) It's not just about privacy for the calling user - that's relatively easy, you just need a mechanism to 'privately' pass information to trusted network entities and apart from that it's up to the UA what it does/doesn't reveal. The big problem is when other people are involved who do not have an 'agent' representing them. A subscriber to a public service is an example. These people have rights which only the Service Provider knows about. The Service Provider cannot be responsible for sending Personal Data of the subscriber to the called party. Unfortunately the identity of the calling user can often include personal data of the subscriber.

2) You said 'If the user voluntarily includes it, it's not private'. Sure, it's not private *as far as the user is concerned*. But it might be private with respect to other people. So the question is who was *responsible* for sending it. If it's entirely the user then no problem - same as if it's the first thing the user says after Answer. The problem is that To/From are a grey area, since the SIP spec clearly intends that they contain the calling/called identities (as would a spec for 'What-I-Want-You-To-Call-Me'). A network based subscriber privacy service which did not modify the From field would be pretty rubbish, whereas one which did not modify the Subject would probably be fine.

I'm confused by what you are getting at by "subscribers" and "other people" (who don't have an "agent"), and "calling user". There is a SIP phone (containing a "User Agent") and it might be used by multiple people to place calls. If people don't have their own identity, then every call must use the identity of the physical device. If there is a capability for each person to provide a separate identity, then that is what is used by the "network" as the basis for a "subscription" to service and to apply privacy.

If you are referring to the complicated cases of how to apply "privacy" to identities involved in 3-way services such as call transfer and call forwarding, then I understand the difficulties, having been through excrutiating discussions in standards development for ISDN. It isn't easy or pretty. But these issues will only be worked out in a specific discusion of the interworking of the identity/privacy service with the call transfer/call forwarding services, something that the IETF is intent on not doing.

I still say if the user voluntarily includes something beyond the specific identity fields, then the network has no obligation to apply privacy to it. I don't see a case in which the network has to do anything else to provide privacy for "other people". Again, maybe there is a difference in what "user" refers to in your point 2) above. If the "standard" service operation (in the User Agent or network) puts in some identity, or passes along one it got during Call Transfer, then of course privacy rules must apply to it. That's not the user (person) voluntarily putting in the information.

Mike

------_=_NextPart_001_01C1E469.81B1F20A-- _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@ns.ietf.org Mon Apr 15 07:45:27 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA13499 for ; Mon, 15 Apr 2002 07:45:27 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id HAA07044 for sip-archive@odin.ietf.org; Mon, 15 Apr 2002 07:45:29 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id HAA06080; Mon, 15 Apr 2002 07:30:04 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id HAA06014 for ; Mon, 15 Apr 2002 07:29:58 -0400 (EDT) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA13143; Mon, 15 Apr 2002 07:29:55 -0400 (EDT) Message-Id: <200204151129.HAA13143@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: sip@ietf.org, simple@mailman.dynamicsoft.com From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Date: Mon, 15 Apr 2002 07:29:54 -0400 Subject: [Sip] I-D ACTION:draft-ietf-sip-message-02.txt Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Session Initiation Protocol Working Group of the IETF. Title : Session Initiation Protocol Extension for Instant Messaging Author(s) : B. Campbell, J. Rosenberg et al. Filename : draft-ietf-sip-message-02.txt Pages : 19 Date : 12-Apr-02 Instant Messageing (IM) refers to the transfer of messages between users in near real-time. These messages are usually, but not required to be, short. IMs are often used in a conversational mode, that is, the transfer of messages back and forth is fast enough for participants to maintain an interactive conversation. The MESSAGE method is an extension to the Session Initation Protocol (SIP) that allows the transfer of Instant Messages. MESSAGE requests carry the content in the form of MIME body parts. MESSAGE requests do not themselves initiate a SIP dialog; under normal usage each Instant Message stands alone, much like pager messages. MESSAGE requests may be sent in the context of a dialog initiated by some other SIP request. Since the MESSAGE request is an extension to SIP it inherits all the request routing and security features of that protocol. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-sip-message-02.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-sip-message-02.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-sip-message-02.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <20020412140710.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-sip-message-02.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-sip-message-02.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20020412140710.I-D@ietf.org> --OtherAccess-- --NextPart-- _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@ns.ietf.org Mon Apr 15 09:35:04 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA16915 for ; Mon, 15 Apr 2002 09:35:04 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id JAA12536 for sip-archive@odin.ietf.org; Mon, 15 Apr 2002 09:35:07 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id IAA10011; Mon, 15 Apr 2002 08:47:58 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id IAA09980 for ; Mon, 15 Apr 2002 08:47:53 -0400 (EDT) Received: from MHPA8R1C (proxy8.netz.sbs.de [192.35.17.27]) by ietf.org (8.9.1a/8.9.1a) with SMTP id IAA15535 for ; Mon, 15 Apr 2002 08:47:48 -0400 (EDT) From: "Salva Rey Calatayud" To: sip@ietf.org Date: Sat, 15 Apr 2000 15:00:13 +0200 MIME-Version: 1.0 Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: 7BIT Reply-to: salreyca@teleco.upv.es Message-ID: <38F883FD.11036.12590D4@localhost> Priority: normal X-mailer: Pegasus Mail for Win32 (v3.12cDE) X-SMTP-Server: PostCast Server 1.0.0 Content-Transfer-Encoding: 7BIT Subject: [Sip] SIP O/A model Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7BIT Isn't there a mechanism whereby both UAs get back to an agreed state? How can the negotiation process continue properly otherwise? regards, Salva On 10 Apr 2002, at 0:43, Jonathan Rosenberg wrote: > THe spec does not detail error handling for the infinite different ways > in which they might occur. The choice is at the discretion of the > implementation. > > -Jonathan R. > > Salva Rey Calatayud wrote: > > > > Hi, > > > > how should a UA act when let's say the other endpoint doesn't > > behave compliantly to the O/A exchange model. For instance, we > > send an offer, and none of the associated messages that could > > contain an answer does (an UPDATE with a 200OK without > > answer, INVITE with offer and none of the provisional response nor > > final 200OK contain an answer ) > > > > thanks, > > Salva _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@ns.ietf.org Mon Apr 15 09:46:45 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA17285 for ; Mon, 15 Apr 2002 09:46:44 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id JAA12971 for sip-archive@odin.ietf.org; Mon, 15 Apr 2002 09:46:48 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA11377; Mon, 15 Apr 2002 09:17:26 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA11345 for ; Mon, 15 Apr 2002 09:17:21 -0400 (EDT) Received: from mail1.telekom.de (mail1.telekom.de [62.225.183.235]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA16488 for ; Mon, 15 Apr 2002 09:17:17 -0400 (EDT) Received: from g8pbr.blf01.telekom.de by G8SBV.dmz.telekom.de with ESMTP; Mon, 15 Apr 2002 15:15:26 +0200 Received: by G8PBR.blf01.telekom.de with Internet Mail Service (5.5.2653.19) id <2W57CP6C>; Mon, 15 Apr 2002 15:16:42 +0200 Message-Id: From: "Jesske, R" To: mwatson@nortelnetworks.com, dean.willis@softarmor.com, Mpierce1@aol.com, Brian.Rosen@marconi.com, sip@ietf.org Subject: AW: Summary of RE: [Sip] Comment, SIP Privacy draft Date: Mon, 15 Apr 2002 15:16:33 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id JAA11346 Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 8bit Hi all, regarding the discussion what SIP Header fits to what ISUP Parameter we should know what rules apply to the interworking from SIP to ISUP. From my understanding (of the last ITU discussion in Geneva) the following rules shall apply to the mapping of the From and Remote Party ID to ISUP parameters: .... Note: From: is mandatory and always checked for presence. Case-a: If RPID is absent, then do the following: 1) Additional CgPN is derived from From: (Note Jesske:because it is user provided but not verified by the service provider) 2) CgPN is assigned with Network Generated Number. (Note Jesske: with a screening indication: network provided) Case-b: If RPID is present and RPI-Screen="Yes", then do the following: 1) Additional CgPN is derived from From: (Note Jesske:because it is user provided but not verified by the service provider) 2) CgPN is derived from RPID: (Note Jesske: with a screening indication: user provided verified and passed ) Case-c: If RPID is present and RPI-Screen="No", then do the following: 1) Additional CgPN is derived from RPID: (Note Jesske:because it is user provided but not verified by the service provider) 2) CgPN is assigned with Network Generated Number. (Note Jesske: with a screening indication: network provided) .... The interest of big Service Provider/Carriers is to have an proper inteworking of SIP and ISUP, because the will have in future hybrid networks with SIP and ISUP (BICC) signalling. And the above mentioned rules are the first step forward for a proper interworking (my opinion) between SIP and ISUP including the CLIP/CLIR Service. I hope this information fits in your discussion. Best Regards Roland -----Urspr�ngliche Nachricht----- Von: Mark Watson [mailto:mwatson@nortelnetworks.com] Gesendet am: Montag, 15. April 2002 12:19 An: 'Dean Willis'; Mpierce1@aol.com; Brian.Rosen@marconi.com; sip@ietf.org Betreff: RE: Summary of RE: [Sip] Comment, SIP Privacy draft Dean wrote: > > Excellent summary, Mike. That's exactly what I'm saying. > > In short: > > To:/From: are equivalent to ISDN user-to-user data, as is most of > current SIP. But not in the case raised by Juha, where the Service Provider checks the contents of the From field. Then these fields are more like the user-provided Calling Party Number field which is checked by the local exchange. Even if the Service Provider does not do this checking, I would still argue that there is an implicit expectation that these fields contain indentity information, and indeed this is what most clients will put in there. I don't think this is insignificant. It is completely different from User-to-user in ISDN, or, say, Subject: in SIP where there is no expectation at all. In ISDN, if you have a so-called 'Special Arrangement' then you can supply an identity which is passed transparently through the network - no checking, nothing. Obviously, the user only supplies an identity if they do not want anonymity. But even if they do supply an identity, if the *subscriber* has requested anonymity, then it is removed by the network. Sounds pretty analogous to From: to me. > > RPID: is analogous to CPN, and its "Screened" parameter analogous to > what happens in ISDN today. > Analogous to Calling Party Number within the network, and when delivered to the Called party. > Privacy: is analogous to the calling line identification restriction > flag. > > I think an understanding of this relationship should clear up > 99% of the > debate over the "privacy" draft Well, it would if we agreed :-) ...Mark > , which is really much more of a SIP-T > "telephony interworking" document than it is a general > privacy document. > _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@ns.ietf.org Mon Apr 15 11:16:05 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA20188 for ; Mon, 15 Apr 2002 11:16:05 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id LAA20285 for sip-archive@odin.ietf.org; Mon, 15 Apr 2002 11:16:09 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA16383; Mon, 15 Apr 2002 10:28:20 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA16354 for ; Mon, 15 Apr 2002 10:28:16 -0400 (EDT) Received: from excalibur.santera.com (exchange.santera.com [4.22.157.11]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA18840 for ; Mon, 15 Apr 2002 10:28:10 -0400 (EDT) X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C1E489.B225CC85" Subject: RE: Summary of RE: [Sip] Comment, SIP Privacy draft Date: Mon, 15 Apr 2002 09:27:39 -0500 Message-ID: Thread-Topic: Summary of RE: [Sip] Comment, SIP Privacy draft Thread-Index: AcHiQ4Sax+IzsyCjTM+M6z9mq960yACQbaQQ From: "Chiou, Mark" To: "Dean Willis" , , Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org This is a multi-part message in MIME format. ------_=_NextPart_001_01C1E489.B225CC85 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Dean wrote: ##################################### The point I'm trying to make is that To and From are USER supplied = information. The Service Provider doesn't insert them, inspect them, or = have any responsibility for them. Insisting that the service provider = change them is just like insisting that the service provider change any = other user-supplied information, such as the words I'm typing now. = Anything I put in my To or from field is deliberately and explicitly = intended to be delivered to the terminating side of the dialog, and if = as a service provider you FAIL to do that, then you have DAMAGED my = data, and my lawyers will be in touch! =20 The calling-party-identity presentation infromation (CLIP or RPID) is = NOT inserted by the user. It is inserted by the network, WITHOUT THE = CONSENT of the user. As such, the operator is responsible for the = protection of that information in a manner consistent with regulation = and the expressed wishes of the user. ########################################################## No, The CLIP is inserted by the network WITH THE CONSENT of the user. = When you subscribe a line from a PSTN service provider, the form you = filled indicating whether you want your telephone number to be PUBLIC or = PRIVATE. (of course, the default is PUBLIC if you leave it blank.) When = you make a call, the PRIVATE or PUBLIC status value is retrieved and set = the Address Presentation Restricted Indicator (APRI) field in SS7 = environment (Note that, CLIR toggles the values), then the terminating = side of the network based on the APRI value to determine whether the = Calling Party Number shall be delivered to the callee's CPE. =20 Since we want to push the decision making to the UA, we should = standardize the rule such that the UA shall display the From information = based on Privacy indication. If we think that too many UAs won't follow = this rule, than we should allow the Service Provider of terminating side = (not the originating side) to alter the From information before = terminating the call to the UA based on the Privacy indication. =20 This is my penny thought, =20 Mark Chiou=20 ------_=_NextPart_001_01C1E489.B225CC85 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Message

Dean=20 wrote:

#####################################

The point I'm trying to make is that To and From are USER = supplied=20 information. The Service Provider doesn't insert them, inspect = them, or=20 have any responsibility for them. Insisting that the service provider = change=20 them is just like insisting that the service provider change any = other=20 user-supplied information, such as the words I'm typing now. = Anything=20 I put in my To or from field is deliberately and explicitly intended to = be=20 delivered to the terminating side of the dialog, and if as a service = provider=20 you FAIL to do that, then you have DAMAGED my data, and my lawyers will = be in=20 touch!

<snip>

##############################################= ############

No, The CLIP is = inserted by=20 the network WITH THE CONSENT of the user. When you subscribe a line from = a PSTN=20 service provider, the form you filled indicating whether you want your = telephone=20 number to be PUBLIC or PRIVATE. (of course, the default is PUBLIC if you = leave=20 it blank.) When you make a call, the PRIVATE or PUBLIC status value is = retrieved=20 and set the Address Presentation Restricted Indicator (APRI) field in = SS7=20 environment (Note that, CLIR toggles the values), then the terminating = side of=20 the network based on the APRI value to determine whether the Calling = Party=20 Number shall be delivered to the callee's CPE.

Since we want = to push the=20 decision making to the UA, we should standardize the rule such that the = UA shall=20 display the From information based on Privacy indication. If we think = that too=20 many UAs won't follow this rule, than we should allow the Service = Provider of=20 terminating side (not the originating side) to alter the From = information before=20 terminating the call to the UA based on the Privacy=20 indication.

This is my penny=20 thought,

Mark=20 Chiou

<= /HTML> ------_=_NextPart_001_01C1E489.B225CC85-- _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@ns.ietf.org Mon Apr 15 11:26:24 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA20409 for ; Mon, 15 Apr 2002 11:26:23 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id LAA20673 for sip-archive@odin.ietf.org; Mon, 15 Apr 2002 11:26:28 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA18029; Mon, 15 Apr 2002 10:45:11 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA17928 for ; Mon, 15 Apr 2002 10:45:03 -0400 (EDT) Received: from magus.nostrum.com (root@magus.nostrum.com [66.119.225.66]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA19423 for ; Mon, 15 Apr 2002 10:44:58 -0400 (EDT) Received: from txbcampbell (root@magus.nostrum.com [66.119.225.66]) by magus.nostrum.com (8.11.0/8.11.0) with SMTP id g3FEikX46673; Mon, 15 Apr 2002 09:44:47 -0500 (CDT) From: "Ben Campbell" To: "Chiou, Mark" , "Dean Willis" , , Subject: RE: Summary of RE: [Sip] Comment, SIP Privacy draft Date: Mon, 15 Apr 2002 09:44:25 -0500 Message-ID: MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_003A_01C1E462.21297EA0" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Importance: Normal Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org This is a multi-part message in MIME format. ------=_NextPart_000_003A_01C1E462.21297EA0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit MessageYou pretty much have to assume that the receiving user sees _anything_ you send his UA, except in the rare case where the user has no control over the UA behavior. Asking a UAS to hide information from its owner is not useful in the generic case. I agree with Dean on this in general, although it really doesn't matter if any _network_ inserted identification is there with the consent of the originating user or not. A privacy request need _only_ apply to network-inserted identification data. The UAC has every opportunity _not_ to insert identification if it does not want to. Expecting the network to screen out ID that _I_ provide is a slippery slope. What if I put "call from Ben" in a Subject header? Do you screen that out as well? What if I _tell_ the destination user who I am in an IM associated with the call? What about the media session,? -----Original Message----- From: sip-admin@ietf.org [mailto:sip-admin@ietf.org]On Behalf Of Chiou, Mark Sent: Monday, April 15, 2002 9:28 AM To: Dean Willis; Mpierce1@aol.com; sip@ietf.org Subject: RE: Summary of RE: [Sip] Comment, SIP Privacy draft Dean wrote: ##################################### The point I'm trying to make is that To and From are USER supplied information. The Service Provider doesn't insert them, inspect them, or have any responsibility for them. Insisting that the service provider change them is just like insisting that the service provider change any other user-supplied information, such as the words I'm typing now. Anything I put in my To or from field is deliberately and explicitly intended to be delivered to the terminating side of the dialog, and if as a service provider you FAIL to do that, then you have DAMAGED my data, and my lawyers will be in touch! The calling-party-identity presentation infromation (CLIP or RPID) is NOT inserted by the user. It is inserted by the network, WITHOUT THE CONSENT of the user. As such, the operator is responsible for the protection of that information in a manner consistent with regulation and the expressed wishes of the user. ########################################################## No, The CLIP is inserted by the network WITH THE CONSENT of the user. When you subscribe a line from a PSTN service provider, the form you filled indicating whether you want your telephone number to be PUBLIC or PRIVATE. (of course, the default is PUBLIC if you leave it blank.) When you make a call, the PRIVATE or PUBLIC status value is retrieved and set the Address Presentation Restricted Indicator (APRI) field in SS7 environment (Note that, CLIR toggles the values), then the terminating side of the network based on the APRI value to determine whether the Calling Party Number shall be delivered to the callee's CPE. Since we want to push the decision making to the UA, we should standardize the rule such that the UA shall display the From information based on Privacy indication. If we think that too many UAs won't follow this rule, than we should allow the Service Provider of terminating side (not the originating side) to alter the From information before terminating the call to the UA based on the Privacy indication. This is my penny thought, Mark Chiou ------=_NextPart_000_003A_01C1E462.21297EA0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Message

You=20 pretty much have to assume that the receiving user sees _anything_ you = send his=20 UA, except in the rare case where the user has no control over the UA = behavior.=20 Asking a UAS to hide information from its owner is not useful in the = generic=20 case.

I=20 agree with Dean on this in general, although it really doesn't matter if = any=20 _network_ inserted identification is there with the consent of the = originating=20 user or not. A privacy request need _only_ apply to network-inserted=20 identification data. The UAC has every opportunity _not_ to insert=20 identification if it does not want to.

Expecting the network to screen out ID that _I_ provide is a = slippery=20 slope. What if I put "call from Ben" in a Subject header? Do you screen = that out=20 as well? What if I _tell_ the destination user who I am in an IM = associated with=20 the call? What about the media session,?

-----Original = Message-----
From:=20 sip-admin@ietf.org [mailto:sip-admin@ietf.org]On Behalf Of Chiou, = Mark
Sent: Monday, April 15, 2002 9:28 AM
To: Dean = Willis;=20 Mpierce1@aol.com; sip@ietf.org
Subject: RE: Summary of RE: = [Sip]=20 Comment, SIP Privacy draft

Dean=20 wrote:

#####################################

The point I'm trying to make is that To and From are = USER=20 supplied information. The Service Provider doesn't insert them, = inspect=20 them, or have any responsibility for them. Insisting that the service = provider=20 change them is just like insisting that the service provider = change any=20 other user-supplied information, such as the words I'm = typing now.=20 Anything I put in my To or from field is deliberately and explicitly = intended=20 to be delivered to the terminating side of the dialog, and if as a = service=20 provider you FAIL to do that, then you have DAMAGED my data, and my = lawyers=20 will be in touch!

The calling-party-identity presentation = infromation=20 (CLIP or RPID) is NOT inserted by the user. It is inserted by the = network,=20 WITHOUT THE CONSENT of the user. As such, the operator is responsible = for the=20 protection of that information in a manner consistent with regulation = and the=20 expressed wishes of the user.

<snip>
=
##############################################= ############

No, The CLIP = is inserted=20 by the network WITH THE CONSENT of the user. When you subscribe a line = from a=20 PSTN service provider, the form you filled indicating whether you want = your=20 telephone number to be PUBLIC or PRIVATE. (of course, the default is = PUBLIC if=20 you leave it blank.) When you make a call, the PRIVATE or PUBLIC = status value=20 is retrieved and set the Address Presentation Restricted Indicator = (APRI)=20 field in SS7 environment (Note that, CLIR toggles the values), then = the=20 terminating side of the network based on the APRI value to determine = whether=20 the Calling Party Number shall be delivered to the callee's=20 CPE.

Since we want = to push the=20 decision making to the UA, we should standardize the rule such that = the UA=20 shall display the From information based on Privacy indication. If we = think=20 that too many UAs won't follow this rule, than we should allow the = Service=20 Provider of terminating side (not the originating side) to alter the = From=20 information before terminating the call to the UA based on the Privacy = indication.

This is my penny=20 thought,

Mark=20 = Chiou
------=_NextPart_000_003A_01C1E462.21297EA0-- _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@ns.ietf.org Mon Apr 15 11:36:54 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA20609 for ; Mon, 15 Apr 2002 11:36:54 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id LAA21482 for sip-archive@odin.ietf.org; Mon, 15 Apr 2002 11:36:57 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA19639; Mon, 15 Apr 2002 11:03:10 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA19612 for ; Mon, 15 Apr 2002 11:03:06 -0400 (EDT) Received: from excalibur.santera.com (exchange.santera.com [4.22.157.11]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA19886 for ; Mon, 15 Apr 2002 11:03:01 -0400 (EDT) X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C1E48E.90D8BCC2" Subject: RE: Summary of RE: [Sip] Comment, SIP Privacy draft Date: Mon, 15 Apr 2002 10:02:30 -0500 Message-ID: Thread-Topic: Summary of RE: [Sip] Comment, SIP Privacy draft Thread-Index: AcHkjBmkjb+9Csq4QQWkZhJ+6r2OOwAATMmA From: "Chiou, Mark" To: "Ben Campbell" , "Dean Willis" , , Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org This is a multi-part message in MIME format. ------_=_NextPart_001_01C1E48E.90D8BCC2 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Sounds like you prefer separate the User provided information from = Network provided information. I agree with you as long as we address a = privacy header which is inserted by the originating Service Provider and = extracted by the terminating Service provider. (The Privacy information = should not be delivered to the UAS.) The same Privacy header information is also used to interwork with PSTN = world for APRI purpose.=20 =20 Mark Chiou -----Original Message----- From: Ben Campbell [mailto:bcampbell@dynamicsoft.com] Sent: Monday, April 15, 2002 9:44 AM To: Chiou, Mark; Dean Willis; Mpierce1@aol.com; sip@ietf.org Subject: RE: Summary of RE: [Sip] Comment, SIP Privacy draft You pretty much have to assume that the receiving user sees _anything_ = you send his UA, except in the rare case where the user has no control = over the UA behavior. Asking a UAS to hide information from its owner is = not useful in the generic case. =20 I agree with Dean on this in general, although it really doesn't matter = if any _network_ inserted identification is there with the consent of = the originating user or not. A privacy request need _only_ apply to = network-inserted identification data. The UAC has every opportunity = _not_ to insert identification if it does not want to.=20 =20 Expecting the network to screen out ID that _I_ provide is a slippery = slope. What if I put "call from Ben" in a Subject header? Do you screen = that out as well? What if I _tell_ the destination user who I am in an = IM associated with the call? What about the media session,? =20 -----Original Message----- From: sip-admin@ietf.org [mailto:sip-admin@ietf.org]On Behalf Of Chiou, = Mark Sent: Monday, April 15, 2002 9:28 AM To: Dean Willis; Mpierce1@aol.com; sip@ietf.org Subject: RE: Summary of RE: [Sip] Comment, SIP Privacy draft Dean wrote: ##################################### The point I'm trying to make is that To and From are USER supplied = information. The Service Provider doesn't insert them, inspect them, or = have any responsibility for them. Insisting that the service provider = change them is just like insisting that the service provider change any = other user-supplied information, such as the words I'm typing now. = Anything I put in my To or from field is deliberately and explicitly = intended to be delivered to the terminating side of the dialog, and if = as a service provider you FAIL to do that, then you have DAMAGED my = data, and my lawyers will be in touch! =20 The calling-party-identity presentation infromation (CLIP or RPID) is = NOT inserted by the user. It is inserted by the network, WITHOUT THE = CONSENT of the user. As such, the operator is responsible for the = protection of that information in a manner consistent with regulation = and the expressed wishes of the user. ########################################################## No, The CLIP is inserted by the network WITH THE CONSENT of the user. = When you subscribe a line from a PSTN service provider, the form you = filled indicating whether you want your telephone number to be PUBLIC or = PRIVATE. (of course, the default is PUBLIC if you leave it blank.) When = you make a call, the PRIVATE or PUBLIC status value is retrieved and set = the Address Presentation Restricted Indicator (APRI) field in SS7 = environment (Note that, CLIR toggles the values), then the terminating = side of the network based on the APRI value to determine whether the = Calling Party Number shall be delivered to the callee's CPE. =20 Since we want to push the decision making to the UA, we should = standardize the rule such that the UA shall display the From information = based on Privacy indication. If we think that too many UAs won't follow = this rule, than we should allow the Service Provider of terminating side = (not the originating side) to alter the From information before = terminating the call to the UA based on the Privacy indication. =20 This is my penny thought, =20 Mark Chiou=20 ------_=_NextPart_001_01C1E48E.90D8BCC2 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Message
Sounds=20 like you prefer separate the User provided information from Network = provided=20 information. I agree with you as long as we address a privacy header = which is=20 inserted by the originating Service Provider and extracted by the = terminating=20 Service provider. (The Privacy information should not be delivered to = the=20 UAS.)

The=20 same Privacy header information is also used to interwork with PSTN = world for=20 APRI purpose.

Mark=20 Chiou

-----Original Message-----
From: Ben Campbell=20 [mailto:bcampbell@dynamicsoft.com]
Sent: Monday, April 15, = 2002 9:44=20 AM
To: Chiou, Mark; Dean Willis; Mpierce1@aol.com;=20 sip@ietf.org
Subject: RE: Summary of RE: [Sip] Comment, SIP = Privacy=20 draft

You=20 pretty much have to assume that the receiving user sees _anything_ you = send=20 his UA, except in the rare case where the user has no control over the = UA=20 behavior. Asking a UAS to hide information from its owner is not = useful in the=20 generic case.

I=20 agree with Dean on this in general, although it really doesn't matter = if any=20 _network_ inserted identification is there with the consent of the = originating=20 user or not. A privacy request need _only_ apply to network-inserted=20 identification data. The UAC has every opportunity _not_ to insert=20 identification if it does not want to.

Expecting the network to screen out ID that _I_ provide is a = slippery=20 slope. What if I put "call from Ben" in a Subject header? Do you = screen that=20 out as well? What if I _tell_ the destination user who I am in an IM=20 associated with the call? What about the media = session,?

-----Original=20 Message-----
From: sip-admin@ietf.org=20 [mailto:sip-admin@ietf.org]On Behalf Of Chiou, = Mark
Sent:=20 Monday, April 15, 2002 9:28 AM
To: Dean Willis; = Mpierce1@aol.com;=20 sip@ietf.org
Subject: RE: Summary of RE: [Sip] Comment, SIP = Privacy=20 draft

Dean wrote:

#####################################

The point I'm trying to make is that To and From are = USER=20 supplied information. The Service Provider doesn't insert them, = inspect=20 them, or have any responsibility for them. Insisting that the = service=20 provider change them is just like insisting that the service = provider=20 change any other user-supplied information, such as = the words I'm=20 typing now. Anything I put in my To or from field is deliberately = and=20 explicitly intended to be delivered to the terminating side of the = dialog,=20 and if as a service provider you FAIL to do that, then you have = DAMAGED my=20 data, and my lawyers will be in=20 touch!

The calling-party-identity presentation = infromation=20 (CLIP or RPID) is NOT inserted by the user. It is inserted by the = network,=20 WITHOUT THE CONSENT of the user. As such, the operator is = responsible for=20 the protection of that information in a manner consistent with = regulation=20 and the expressed wishes of the=20 user.

<snip>
=
##############################################= ############

No, The = CLIP is=20 inserted by the network WITH THE CONSENT of the user. When you = subscribe a=20 line from a PSTN service provider, the form you filled indicating = whether=20 you want your telephone number to be PUBLIC or PRIVATE. (of course, = the=20 default is PUBLIC if you leave it blank.) When you make a call, the = PRIVATE=20 or PUBLIC status value is retrieved and set the Address Presentation = Restricted Indicator (APRI) field in SS7 environment (Note that, = CLIR=20 toggles the values), then the terminating side of the network based = on the=20 APRI value to determine whether the Calling Party Number shall be = delivered=20 to the callee's CPE.

Since we = want to push=20 the decision making to the UA, we should standardize the rule such = that the=20 UA shall display the From information based on Privacy indication. = If we=20 think that too many UAs won't follow this rule, than we should allow = the=20 Service Provider of terminating side (not the originating side) to = alter the=20 From information before terminating the call to the UA based on the = Privacy=20 indication.

This is my penny=20 thought,

Mark=20 = Chiou
------_=_NextPart_001_01C1E48E.90D8BCC2-- _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@ns.ietf.org Mon Apr 15 11:40:51 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA20691 for ; Mon, 15 Apr 2002 11:40:51 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id LAA21633 for sip-archive@odin.ietf.org; Mon, 15 Apr 2002 11:40:50 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA19888; Mon, 15 Apr 2002 11:07:00 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA19857 for ; Mon, 15 Apr 2002 11:06:56 -0400 (EDT) Received: from lohi.eng.song.fi (lohi.eng.song.fi [195.10.149.18]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA19949 for ; Mon, 15 Apr 2002 11:06:47 -0400 (EDT) Received: from jh by lohi.eng.song.fi with local (Exim 3.34 #1 (Debian)) id 16x83c-0003si-00; Mon, 15 Apr 2002 18:06:16 +0300 From: Juha Heinanen MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15546.60520.447910.574964@lohi.eng.song.fi> Date: Mon, 15 Apr 2002 18:06:16 +0300 To: "Mark Watson" Cc: Dean Willis , Mpierce1@aol.com, sip@ietf.org Subject: RE: Summary of RE: [Sip] Comment, SIP Privacy draft In-Reply-To: References: X-Mailer: VM 6.97 under Emacs 20.7.2 Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit Mark Watson writes: > I think many service providers will wish to do the same, and indeed this > checking is required in 3GPP. The situation is much clearer in this case, > because in order to access the service at all, the user MUST insert their > true identity (or 'anonymous') into the From: field. if the call goes to pstn, the user gets calling number anonymity by using Anonymous as the display string. if the call goes to another sip user, the same thing happens, but i must implement b2ua and rewrite the from header. no standardization is needed in order to accomplish this. -- juha _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Mon Apr 15 12:43:30 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA26456 for ; Mon, 15 Apr 2002 12:43:26 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id MAA27053 for sip-archive@odin.ietf.org; Mon, 15 Apr 2002 12:43:27 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA24404; Mon, 15 Apr 2002 12:10:46 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA24342 for ; Mon, 15 Apr 2002 12:10:41 -0400 (EDT) Received: from wells.cisco.com (wells.cisco.com [171.71.177.223]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA22085; Mon, 15 Apr 2002 12:10:37 -0400 (EDT) Received: from JMPOLK-W2K (ssh-sjc-1.cisco.com [171.68.225.134]) by wells.cisco.com (8.8.6 (PHNE_14041)/CISCO.SERVER.1.2) with SMTP id JAA06475; Mon, 15 Apr 2002 09:10:08 -0700 (PDT) Message-Id: <4.1.20020415103657.016784e0@localhost> X-Sender: jmpolk@localhost X-Mailer: QUALCOMM Windows Eudora Pro Version 4.1 Date: Mon, 15 Apr 2002 11:10:06 -0500 To: Rohan Mahy , , From: "James M. Polk" In-Reply-To: Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="=====================_5317165==_.ALT" Subject: [Sip] Re: [Sipping] SIP/SIPPING Interim Meeting Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org --=====================_5317165==_.ALT Content-Type: text/plain; charset="us-ascii" At 01:39 PM 4/13/2002 -0700, Rohan Mahy wrote: >Hi, > >I'd like to announce a joint SIP/SIPPING interim meeting May 6-7 in Las >Vegas, Nevada. You chose the week of InterOp Las Vegas, plan on having the meeting *at* the same location as that convention, and have really confirmed that there are rooms available at the hotel attached to the convention center?! Seems even if you've picked a location that does have the room, that you couldn't have picked a more hectic week or place to have it in (except maybe CES week in Januarys)... Or was this a plan to have during InterOp? >this date and location were changed (with AD approval) >as a fallback due to conflicts with the previously proposed time and place >(Boston, the following week). ************************************* "People generally demand more respect for their own rights than they are willing to allow for others" James M. Polk Consulting Engineer Office of the CTO Cisco Systems 2200 East President George Bush Turnpike Richardson, TX 75082 USA w) 972.813.5208 f) 972.813.5280 www.cisco.com --=====================_5317165==_.ALT Content-Type: text/html; charset="us-ascii" At 01:39 PM 4/13/2002 -0700, Rohan Mahy wrote:
>Hi,
>
>I'd like to announce a joint SIP/SIPPING interim meeting May 6-7 in Las
>Vegas, Nevada.

You chose the week of InterOp Las Vegas, plan on having the meeting *at* the same location as that convention, and have really confirmed that there are rooms available at the hotel attached to the convention center?!

Seems even if you've picked a location that does have the room, that you couldn't have picked a more hectic week or place to have it in (except maybe CES week in Januarys)...

Or was this a plan to have during InterOp?

>this date and location were changed (with AD approval)
>as a fallback due to conflicts with the previously proposed time and place
>(Boston, the following week).

*************************************
"People generally demand more respect for their own rights than they are willing to allow for others"

James M. Polk
Consulting Engineer
Office of the CTO

Cisco Systems
2200 East President George Bush Turnpike
Richardson, TX 75082 USA
w) 972.813.5208
f) 972.813.5280
www.cisco.com --=====================_5317165==_.ALT-- _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Mon Apr 15 12:47:25 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA27117 for ; Mon, 15 Apr 2002 12:47:20 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id MAA27472 for sip-archive@odin.ietf.org; Mon, 15 Apr 2002 12:47:21 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA25169; Mon, 15 Apr 2002 12:19:21 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA25140 for ; Mon, 15 Apr 2002 12:19:12 -0400 (EDT) Received: from zctfs063.nortelnetworks.com (zctfs063.nortelnetworks.com [47.164.128.120]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA22377 for ; Mon, 15 Apr 2002 12:19:05 -0400 (EDT) Received: from zwcwc012.europe.nortel.com (zwcwc012.europe.nortel.com [47.73.112.187]) by zctfs063.nortelnetworks.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id g3FGHAg01351; Mon, 15 Apr 2002 18:17:11 +0200 (MEST) Received: by zwcwc012.europe.nortel.com with Internet Mail Service (5.5.2653.19) id ; Mon, 15 Apr 2002 17:17:10 +0100 Message-ID: From: "Mark Watson" To: "'Ben Campbell'" , "Chiou, Mark" , Dean Willis , Mpierce1@aol.com, sip@ietf.org Subject: RE: Summary of RE: [Sip] Comment, SIP Privacy draft Date: Mon, 15 Apr 2002 17:17:04 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C1E498.FAF114F0" Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C1E498.FAF114F0 Content-Type: text/plain; charset="iso-8859-1" Ben, I know this is a long thread, but I have addressed all these points before. Please see below... -----Original Message----- From: Ben Campbell [mailto:bcampbell@dynamicsoft.com] Sent: 15 April 2002 15:44 To: Chiou, Mark; Dean Willis; Mpierce1@aol.com; sip@ietf.org Subject: RE: Summary of RE: [Sip] Comment, SIP Privacy draft You pretty much have to assume that the receiving user sees _anything_ you send his UA, except in the rare case where the user has no control over the UA behavior. Asking a UAS to hide information from its owner is not useful in the generic case. I agree with Dean on this in general, although it really doesn't matter if any _network_ inserted identification is there with the consent of the originating user or not. A privacy request need _only_ apply to network-inserted identification data. The UAC has every opportunity _not_ to insert identification if it does not want to. It doesn't matter what device inserts the information. It matters whether it is part of the service for the information to be inserted. If it is a part of the service, then the responsibility lies with the Service Provider - they defined the service and they are responsible for things the users do effectively at their behest. If I check the From: field I receive from my users is valid, then I am forcing them to put either their identity or 'Anonymous' in there. If there is then a privacy requirement arising from the rights of ANOTHER PERSON, NOT THE USER, then I have to do something about this - I as the Service Provider have the responsibility, not the user. An example is when the *subscriber* has requested anonymity. If I let my users use any old From value, then the situation is not so clear, but I still argue that for fields whose intention is defined for transport of a particular identity, then the Service Provider has some responsibility. (cf Special Arrangements in the ISDN). Expecting the network to screen out ID that _I_ provide is a slippery slope. What if I put "call from Ben" in a Subject header? Do you screen that out as well? What if I _tell_ the destination user who I am in an IM associated with the call? What about the media session,? Personally, I don't think screening out the Subject would be necessary, although there might be some market demand for services which did this. Subject is a genuinely transparent field. There is no intention that it contain your identity, and UAs are unlikely to insert your identity here automatically. ...Mark -----Original Message----- From: sip-admin@ietf.org [mailto:sip-admin@ietf.org]On Behalf Of Chiou, Mark Sent: Monday, April 15, 2002 9:28 AM To: Dean Willis; Mpierce1@aol.com; sip@ietf.org Subject: RE: Summary of RE: [Sip] Comment, SIP Privacy draft Dean wrote: ##################################### The point I'm trying to make is that To and From are USER supplied information. The Service Provider doesn't insert them, inspect them, or have any responsibility for them. Insisting that the service provider change them is just like insisting that the service provider change any other user-supplied information, such as the words I'm typing now. Anything I put in my To or from field is deliberately and explicitly intended to be delivered to the terminating side of the dialog, and if as a service provider you FAIL to do that, then you have DAMAGED my data, and my lawyers will be in touch! The calling-party-identity presentation infromation (CLIP or RPID) is NOT inserted by the user. It is inserted by the network, WITHOUT THE CONSENT of the user. As such, the operator is responsible for the protection of that information in a manner consistent with regulation and the expressed wishes of the user. ########################################################## No, The CLIP is inserted by the network WITH THE CONSENT of the user. When you subscribe a line from a PSTN service provider, the form you filled indicating whether you want your telephone number to be PUBLIC or PRIVATE. (of course, the default is PUBLIC if you leave it blank.) When you make a call, the PRIVATE or PUBLIC status value is retrieved and set the Address Presentation Restricted Indicator (APRI) field in SS7 environment (Note that, CLIR toggles the values), then the terminating side of the network based on the APRI value to determine whether the Calling Party Number shall be delivered to the callee's CPE. Since we want to push the decision making to the UA, we should standardize the rule such that the UA shall display the From information based on Privacy indication. If we think that too many UAs won't follow this rule, than we should allow the Service Provider of terminating side (not the originating side) to alter the From information before terminating the call to the UA based on the Privacy indication. This is my penny thought, Mark Chiou ------_=_NextPart_001_01C1E498.FAF114F0 Content-Type: text/html; charset="iso-8859-1" Message
Ben,

I know this is a long thread, but I have addressed all these points before. Please see below...

-----Original Message-----
From: Ben Campbell [mailto:bcampbell@dynamicsoft.com]
Sent: 15 April 2002 15:44
To: Chiou, Mark; Dean Willis; Mpierce1@aol.com; sip@ietf.org
Subject: RE: Summary of RE: [Sip] Comment, SIP Privacy draft

You pretty much have to assume that the receiving user sees _anything_ you send his UA, except in the rare case where the user has no control over the UA behavior. Asking a UAS to hide information from its owner is not useful in the generic case.

I agree with Dean on this in general, although it really doesn't matter if any _network_ inserted identification is there with the consent of the originating user or not. A privacy request need _only_ apply to network-inserted identification data. The UAC has every opportunity _not_ to insert identification if it does not want to.

It doesn't matter what device inserts the information. It matters whether it is part of the service for the information to be inserted. If it is a part of the service, then the responsibility lies with the Service Provider - they defined the service and they are responsible for things the users do effectively at their behest.

If I check the From: field I receive from my users is valid, then I am forcing them to put either their identity or 'Anonymous' in there.

If there is then a privacy requirement arising from the rights of ANOTHER PERSON, NOT THE USER, then I have to do something about this - I as the Service Provider have the responsibility, not the user. An example is when the *subscriber* has requested anonymity.

If I let my users use any old From value, then the situation is not so clear, but I still argue that for fields whose intention is defined for transport of a particular identity, then the Service Provider has some responsibility. (cf Special Arrangements in the ISDN).

Expecting the network to screen out ID that _I_ provide is a slippery slope. What if I put "call from Ben" in a Subject header? Do you screen that out as well? What if I _tell_ the destination user who I am in an IM associated with the call? What about the media session,?

Personally, I don't think screening out the Subject would be necessary, although there might be some market demand for services which did this. Subject is a genuinely transparent field. There is no intention that it contain your identity, and UAs are unlikely to insert your identity here automatically.

...Mark

-----Original Message-----
From: sip-admin@ietf.org [mailto:sip-admin@ietf.org]On Behalf Of Chiou, Mark
Sent: Monday, April 15, 2002 9:28 AM
To: Dean Willis; Mpierce1@aol.com; sip@ietf.org
Subject: RE: Summary of RE: [Sip] Comment, SIP Privacy draft

Dean wrote:

#####################################

The point I'm trying to make is that To and From are USER supplied information. The Service Provider doesn't insert them, inspect them, or have any responsibility for them. Insisting that the service provider change them is just like insisting that the service provider change any other user-supplied information, such as the words I'm typing now. Anything I put in my To or from field is deliberately and explicitly intended to be delivered to the terminating side of the dialog, and if as a service provider you FAIL to do that, then you have DAMAGED my data, and my lawyers will be in touch!

The calling-party-identity presentation infromation (CLIP or RPID) is NOT inserted by the user. It is inserted by the network, WITHOUT THE CONSENT of the user. As such, the operator is responsible for the protection of that information in a manner consistent with regulation and the expressed wishes of the user.

<snip>

##########################################################

No, The CLIP is inserted by the network WITH THE CONSENT of the user. When you subscribe a line from a PSTN service provider, the form you filled indicating whether you want your telephone number to be PUBLIC or PRIVATE. (of course, the default is PUBLIC if you leave it blank.) When you make a call, the PRIVATE or PUBLIC status value is retrieved and set the Address Presentation Restricted Indicator (APRI) field in SS7 environment (Note that, CLIR toggles the values), then the terminating side of the network based on the APRI value to determine whether the Calling Party Number shall be delivered to the callee's CPE.

Since we want to push the decision making to the UA, we should standardize the rule such that the UA shall display the From information based on Privacy indication. If we think that too many UAs won't follow this rule, than we should allow the Service Provider of terminating side (not the originating side) to alter the From information before terminating the call to the UA based on the Privacy indication.

This is my penny thought,

Mark Chiou
------_=_NextPart_001_01C1E498.FAF114F0-- _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Mon Apr 15 12:50:59 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA27436 for ; Mon, 15 Apr 2002 12:50:59 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id MAA27871 for sip-archive@odin.ietf.org; Mon, 15 Apr 2002 12:51:00 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA24884; Mon, 15 Apr 2002 12:14:30 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA24804 for ; Mon, 15 Apr 2002 12:14:24 -0400 (EDT) Received: from mail6.microsoft.com (mail6.microsoft.com [131.107.3.126]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA22211 for ; Mon, 15 Apr 2002 12:14:18 -0400 (EDT) Received: from inet-vrs-06.redmond.corp.microsoft.com ([157.54.6.201]) by mail6.microsoft.com with Microsoft SMTPSVC(5.0.2195.4905); Mon, 15 Apr 2002 09:13:51 -0700 Received: from 157.54.6.197 by inet-vrs-06.redmond.corp.microsoft.com (InterScan E-Mail VirusWall NT); Mon, 15 Apr 2002 09:13:51 -0700 Received: from red-imc-01.redmond.corp.microsoft.com ([157.54.9.102]) by inet-hub-06.redmond.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.4905); Mon, 15 Apr 2002 09:13:51 -0700 Received: from win-imc-01.wingroup.windeploy.ntdev.microsoft.com ([157.54.0.39]) by red-imc-01.redmond.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.4905); Mon, 15 Apr 2002 09:13:51 -0700 Received: from win-msg-02.wingroup.windeploy.ntdev.microsoft.com ([157.54.0.134]) by win-imc-01.wingroup.windeploy.ntdev.microsoft.com with Microsoft SMTPSVC(6.0.3604.0); Mon, 15 Apr 2002 09:10:15 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.0.6177.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: RE: Summary of RE: [Sip] Comment, SIP Privacy draft Date: Mon, 15 Apr 2002 09:10:14 -0700 Message-ID: Thread-Topic: Summary of RE: [Sip] Comment, SIP Privacy draft Thread-Index: AcHkjs673L+HnDOYRsa2gIPXpyYlbQAB++lA From: "Christian Huitema" To: X-OriginalArrivalTime: 15 Apr 2002 16:10:15.0238 (UTC) FILETIME=[0756DE60:01C1E498] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id MAA24805 Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 8bit I have heard many contributors assert that to get real anonymity, one will have to use a relay, e.g. an "anonymizing B2BUA". I would like to point out a failure in this line of reasoning: anonymizing relays have been tried before, for e-mail, and the experience was absolutely not conclusive. In fact, two different kind of anonymizers have been tried: free ones, that kept absolutely no record, and subscriber-based, which kept some records. Both have failed, for different reason. The failure mode of a completely free relay is basically spam, and similar sort of abuse. There is documentation available on the fate for example of the cypherpunk experiment: this set of relays was set up to provide true anonymity on the Internet, using a sophisticated mix of random redirection and cryptography. In theory, the design was excellent. In practice, the system was quickly overwhelmed by porn traffic, and the relays dropped one by one out of the system because they could not bear the resulting congestion. Subscriber based relays are relays that keep some state: they actually identify the sender, before washing out the identity in the outgoing message. They are more robust to congestion, since they can get some funding in the process, but they have a different failure mode: lawsuit. Since they keep some records, the records can be subpoenaed, and the provider can be forced to disclose the identity of the sending party. In fact, in many codes, if the providers refuse to do so, they may be deemed an accomplice of whatever action was carried out in the anonymous exchange. Many providers have chosen to close their doors rather than have to defend more lawsuit -- often after a brush with the Church of Scientology. If we really want practical anonymity, it has to be based on the UA, and it should not rely on the help of a third party. We should use a combination of encryption, pre-paid subscriptions, and anonymous IP addresses (e.g. IPv6 privacy addresses.) -- Christian Huitema _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Mon Apr 15 12:55:00 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA27561 for ; Mon, 15 Apr 2002 12:55:00 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id MAA28256 for sip-archive@odin.ietf.org; Mon, 15 Apr 2002 12:55:02 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA25563; Mon, 15 Apr 2002 12:25:37 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA25532 for ; Mon, 15 Apr 2002 12:25:34 -0400 (EDT) Received: from zctfs063.nortelnetworks.com (zctfs063.nortelnetworks.com [47.164.128.120]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA22572 for ; Mon, 15 Apr 2002 12:25:30 -0400 (EDT) Received: from zwcwc012.europe.nortel.com (zwcwc012.europe.nortel.com [47.73.112.187]) by zctfs063.nortelnetworks.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id g3FGOMg02456; Mon, 15 Apr 2002 18:24:22 +0200 (MEST) Received: by zwcwc012.europe.nortel.com with Internet Mail Service (5.5.2653.19) id ; Mon, 15 Apr 2002 17:24:22 +0100 Message-ID: From: "Mark Watson" To: "'Juha Heinanen'" Cc: Dean Willis , Mpierce1@aol.com, sip@ietf.org Subject: RE: Summary of RE: [Sip] Comment, SIP Privacy draft Date: Mon, 15 Apr 2002 17:24:17 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C1E499.FD58B364" Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C1E499.FD58B364 Content-Type: text/plain; charset="iso-8859-1" Juha, I am not arguing that standardisation is required. I believe the necessary capabilities can be provided with a B2BUA as described by Jonathan and yourself (or something between a proxy and a full B2BUA). I am arguing against the belief that there is NEVER a requirement for the network to modify fields like From/To. It is this belief that has led other people to distust these fields and specify that no information should be included. The worry is that if you allow potentially private information into those fields, then this will cause trouble because there is an assumption/belief at large in the SIP community that these fields should never be modified. If we could agree that it is at least _likely_ that privacy services which modify From/To will be required by Public Service providers, there would be no more reason to distruct the fields and we could all use them for their intended purpose. ...Mark > -----Original Message----- > From: Juha Heinanen [mailto:jh@lohi.eng.song.fi] > Sent: 15 April 2002 16:06 > To: Watson, Mark [MDN05:EP10:EXCH] > Cc: Dean Willis; Mpierce1@aol.com; sip@ietf.org > Subject: RE: Summary of RE: [Sip] Comment, SIP Privacy draft > > > Mark Watson writes: > > > I think many service providers will wish to do the same, > and indeed this > > checking is required in 3GPP. The situation is much > clearer in this case, > > because in order to access the service at all, the user > MUST insert their > > true identity (or 'anonymous') into the From: field. > > if the call goes to pstn, the user gets calling number anonymity by > using Anonymous as the display string. if the call goes to > another sip > user, the same thing happens, but i must implement b2ua and > rewrite the > from header. no standardization is needed in order to > accomplish this. > > -- juha > ------_=_NextPart_001_01C1E499.FD58B364 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: Summary of RE: [Sip] Comment, SIP Privacy draft
Juha,

I am not arguing that standardisation is required. I = believe the necessary capabilities can be provided with a B2BUA as = described by Jonathan and yourself (or something between a proxy and a = full B2BUA).

I am arguing against the belief that there is NEVER a = requirement for the network to modify fields like From/To. It is this = belief that has led other people to distust these fields and specify = that no information should be included.

The worry is that if you allow potentially private = information into those fields, then this will cause trouble because = there is an assumption/belief at large in the SIP community that these = fields should never be modified.

If we could agree that it is at least _likely_ that = privacy services which modify From/To will be required by Public = Service providers, there would be no more reason to distruct the fields = and we could all use them for their intended purpose.

...Mark

> -----Original Message-----
> From: Juha Heinanen [mailto:jh@lohi.eng.song.fi]
> Sent: 15 April 2002 16:06
> To: Watson, Mark [MDN05:EP10:EXCH]
> Cc: Dean Willis; Mpierce1@aol.com; = sip@ietf.org
> Subject: RE: Summary of RE: [Sip] Comment, SIP = Privacy draft
>
>
> Mark Watson writes:
>
> > I think many service providers will = wish to do the same,
> and indeed this
> > checking is required in 3GPP. The = situation is much
> clearer in this case,
> > because in order to access the = service at all, the user
> MUST insert their
> > true identity (or 'anonymous') into = the From: field.
>
> if the call goes to pstn, the user gets calling = number anonymity by
> using Anonymous as the display string. if = the call goes to
> another sip
> user, the same thing happens, but i must = implement b2ua and
> rewrite the
> from header. no standardization is needed = in order to
> accomplish this.
>
> -- juha
>
------_=_NextPart_001_01C1E499.FD58B364-- _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Mon Apr 15 12:55:24 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA27592 for ; Mon, 15 Apr 2002 12:55:24 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id MAA28284 for sip-archive@odin.ietf.org; Mon, 15 Apr 2002 12:55:25 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA26665; Mon, 15 Apr 2002 12:34:14 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA26634 for ; Mon, 15 Apr 2002 12:34:10 -0400 (EDT) Received: from zctfs063.nortelnetworks.com (zctfs063.nortelnetworks.com [47.164.128.120]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA24561 for ; Mon, 15 Apr 2002 12:34:08 -0400 (EDT) Received: from zwcwc012.europe.nortel.com (zwcwc012.europe.nortel.com [47.73.112.187]) by zctfs063.nortelnetworks.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id g3FGXZg03465; Mon, 15 Apr 2002 18:33:36 +0200 (MEST) Received: by zwcwc012.europe.nortel.com with Internet Mail Service (5.5.2653.19) id ; Mon, 15 Apr 2002 17:33:35 +0100 Message-ID: From: "Mark Watson" To: "'Christian Huitema'" , sip@ietf.org Subject: RE: Summary of RE: [Sip] Comment, SIP Privacy draft Date: Mon, 15 Apr 2002 17:33:08 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C1E49B.3A088DEC" Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C1E49B.3A088DEC Content-Type: text/plain Christian, If you want to provide complete unassailable anonymity, I agree completely. I have been arguing about providing a similar level of anonymity as the PSTN, where the called party is not informed who the call is from by the service itself. It's more about Data Protection than strict anonymity. In the PSTN there is no problem for certain authorised organisations (including the courts) to obtain the details of the call from the Service Providers if they have good reason. Data Protection does not protect you against these organisations. ...Mark > -----Original Message----- > From: Christian Huitema [mailto:huitema@windows.microsoft.com] > Sent: 15 April 2002 17:10 > To: sip@ietf.org > Subject: RE: Summary of RE: [Sip] Comment, SIP Privacy draft > > > I have heard many contributors assert that to get real anonymity, one > will have to use a relay, e.g. an "anonymizing B2BUA". I would like to > point out a failure in this line of reasoning: anonymizing relays have > been tried before, for e-mail, and the experience was absolutely not > conclusive. In fact, two different kind of anonymizers have > been tried: > free ones, that kept absolutely no record, and subscriber-based, which > kept some records. Both have failed, for different reason. > > The failure mode of a completely free relay is basically spam, and > similar sort of abuse. There is documentation available on > the fate for > example of the cypherpunk experiment: this set of relays was set up to > provide true anonymity on the Internet, using a sophisticated mix of > random redirection and cryptography. In theory, the design was > excellent. In practice, the system was quickly overwhelmed by porn > traffic, and the relays dropped one by one out of the system because > they could not bear the resulting congestion. > > Subscriber based relays are relays that keep some state: they actually > identify the sender, before washing out the identity in the outgoing > message. They are more robust to congestion, since they can get some > funding in the process, but they have a different failure > mode: lawsuit. > Since they keep some records, the records can be subpoenaed, and the > provider can be forced to disclose the identity of the > sending party. In > fact, in many codes, if the providers refuse to do so, they may be > deemed an accomplice of whatever action was carried out in > the anonymous > exchange. Many providers have chosen to close their doors rather than > have to defend more lawsuit -- often after a brush with the Church of > Scientology. > > If we really want practical anonymity, it has to be based on > the UA, and > it should not rely on the help of a third party. We should use a > combination of encryption, pre-paid subscriptions, and anonymous IP > addresses (e.g. IPv6 privacy addresses.) > > -- Christian Huitema > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip > ------_=_NextPart_001_01C1E49B.3A088DEC Content-Type: text/html Content-Transfer-Encoding: quoted-printable RE: Summary of RE: [Sip] Comment, SIP Privacy draft
Christian,

If you want to provide complete unassailable = anonymity, I agree completely. I have been arguing about providing a = similar level of anonymity as the PSTN, where the called party is not = informed who the call is from by the service itself. It's more about = Data Protection than strict anonymity.

In the PSTN there is no problem for certain = authorised organisations (including the courts) to obtain the details = of the call from the Service Providers if they have good reason. Data = Protection does not protect you against these organisations.

...Mark

> -----Original Message-----
> From: Christian Huitema [mailto:huitema@windows.mic= rosoft.com]
> Sent: 15 April 2002 17:10
> To: sip@ietf.org
> Subject: RE: Summary of RE: [Sip] Comment, SIP = Privacy draft
>
>
> I have heard many contributors assert that to = get real anonymity, one
> will have to use a relay, e.g. an = "anonymizing B2BUA". I would like to
> point out a failure in this line of reasoning: = anonymizing relays have
> been tried before, for e-mail, and the = experience was absolutely not
> conclusive. In fact, two different kind of = anonymizers have
> been tried:
> free ones, that kept absolutely no record, and = subscriber-based, which
> kept some records. Both have failed, for = different reason.
>
> The failure mode of a completely free relay is = basically spam, and
> similar sort of abuse. There is documentation = available on
> the fate for
> example of the cypherpunk experiment: this set = of relays was set up to
> provide true anonymity on the Internet, using a = sophisticated mix of
> random redirection and cryptography. In theory, = the design was
> excellent. In practice, the system was quickly = overwhelmed by porn
> traffic, and the relays dropped one by one out = of the system because
> they could not bear the resulting = congestion.
>
> Subscriber based relays are relays that keep = some state: they actually
> identify the sender, before washing out the = identity in the outgoing
> message. They are more robust to congestion, = since they can get some
> funding in the process, but they have a = different failure
> mode: lawsuit.
> Since they keep some records, the records can = be subpoenaed, and the
> provider can be forced to disclose the identity = of the
> sending party. In
> fact, in many codes, if the providers refuse to = do so, they may be
> deemed an accomplice of whatever action was = carried out in
> the anonymous
> exchange. Many providers have chosen to close = their doors rather than
> have to defend more lawsuit -- often after a = brush with the Church of
> Scientology.
>
> If we really want practical anonymity, it has = to be based on
> the UA, and
> it should not rely on the help of a third = party. We should use a
> combination of encryption, pre-paid = subscriptions, and anonymous IP
> addresses (e.g. IPv6 privacy addresses.)
>
> -- Christian Huitema
>
> = _______________________________________________
> Sip mailing list https://www1.ietf.org/mailman/listinfo/sip
> This list is for NEW development of the core = SIP Protocol
> Use sip-implementors@cs.columbia.edu for = questions on current sip
> Use sipping@ietf.org for new developments on = the application of sip
>
------_=_NextPart_001_01C1E49B.3A088DEC-- _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Mon Apr 15 13:06:42 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA28015 for ; Mon, 15 Apr 2002 13:06:42 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id NAA29197 for sip-archive@odin.ietf.org; Mon, 15 Apr 2002 13:06:31 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA25052; Mon, 15 Apr 2002 12:17:12 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA25021 for ; Mon, 15 Apr 2002 12:17:07 -0400 (EDT) Received: from lohi.eng.song.fi (lohi.eng.song.fi [195.10.149.18]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA22324 for ; Mon, 15 Apr 2002 12:17:03 -0400 (EDT) Received: from jh by lohi.eng.song.fi with local (Exim 3.34 #1 (Debian)) id 16x99z-0003vC-00; Mon, 15 Apr 2002 19:16:55 +0300 From: Juha Heinanen MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15546.64759.669344.561600@lohi.eng.song.fi> Date: Mon, 15 Apr 2002 19:16:55 +0300 To: "Ben Campbell" Cc: "Chiou, Mark" , "Dean Willis" , , Subject: RE: Summary of RE: [Sip] Comment, SIP Privacy draft In-Reply-To: References: X-Mailer: VM 6.97 under Emacs 20.7.2 Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit Ben Campbell writes: > Expecting the network to screen out ID that _I_ provide is a slippery slope. > What if I put "call from Ben" in a Subject header? Do you screen that out as > well? What if I _tell_ the destination user who I am in an IM associated > with the call? What about the media session,? i don't see any slippery slope here. if you tell in the data part of the message or call, who you are, then it is up to you. the only thing i care is that if the user in the from header claims to be someone that someone has to be someone we have agreed for the subscription. -- juha _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Mon Apr 15 13:08:09 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA28070 for ; Mon, 15 Apr 2002 13:08:09 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id NAA29312 for sip-archive@odin.ietf.org; Mon, 15 Apr 2002 13:08:10 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA26816; Mon, 15 Apr 2002 12:39:07 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA26786 for ; Mon, 15 Apr 2002 12:39:04 -0400 (EDT) Received: from sj-msg-core-4.cisco.com (sj-msg-core-4.cisco.com [171.71.163.10]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA25668 for ; Mon, 15 Apr 2002 12:39:02 -0400 (EDT) Received: from imop.cisco.com (IDENT:mirapoint@imop.cisco.com [171.69.11.44]) by sj-msg-core-4.cisco.com (8.12.2/8.12.2) with ESMTP id g3FGcX3e011438 for ; Mon, 15 Apr 2002 09:38:33 -0700 (PDT) Received: from localhost (ssh-sjc-1.cisco.com [171.68.225.134]) by imop.cisco.com (Mirapoint) with ESMTP id ACV76136; Mon, 15 Apr 2002 09:38:30 -0700 (PDT) Date: Mon, 15 Apr 2002 09:35:34 -0700 (Pacific Daylight Time) From: Rohan Mahy To: sip@ietf.org Message-ID: X-X-Sender: rmahy@imop.cisco.com MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Subject: [Sip] rooms for interim Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Hi, Rooms during the Interim can be reserved here: http://www.pkghlrss.com/liveres/res.asp?EventCode=nilvgen0501&action=new thanks, -rohan _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Mon Apr 15 13:08:31 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA28110 for ; Mon, 15 Apr 2002 13:08:31 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id NAA29329 for sip-archive@odin.ietf.org; Mon, 15 Apr 2002 13:08:33 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA26894; Mon, 15 Apr 2002 12:40:19 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA26865 for ; Mon, 15 Apr 2002 12:40:15 -0400 (EDT) Received: from magus.nostrum.com (root@magus.nostrum.com [66.119.225.66]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA25732 for ; Mon, 15 Apr 2002 12:40:09 -0400 (EDT) Received: from txbcampbell (root@magus.nostrum.com [66.119.225.66]) by magus.nostrum.com (8.11.0/8.11.0) with SMTP id g3FGdsX56436; Mon, 15 Apr 2002 11:39:54 -0500 (CDT) From: "Ben Campbell" To: "Mark Watson" , "Chiou, Mark" , "Dean Willis" , , Subject: RE: Summary of RE: [Sip] Comment, SIP Privacy draft Date: Mon, 15 Apr 2002 11:39:33 -0500 Message-ID: MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_005F_01C1E472.36423D80" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Importance: Normal Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org This is a multi-part message in MIME format. ------=_NextPart_000_005F_01C1E472.36423D80 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit MessageYes, it is a long thread :-) I pretty much agree with your original assessment for when the network authenticates From, although I would propose a better behavior would be to just disallow a request with a non-anonymous From header _and_ with privacy requested. This approach is more backwards compatible (in case something involved still freaks out about modified From headers), and a lot simpler to implement in the network (no B2BUA required, at least for _this_ reason) But in general, the requirement that a network must prevent a badly behaved client from revealing its identity accidentally seems a bit excessive. It should be sufficient to say that a client _can_ prevent its identity from being revealed. -----Original Message----- From: Mark Watson [mailto:mwatson@nortelnetworks.com] Sent: Monday, April 15, 2002 11:17 AM To: 'Ben Campbell'; Chiou, Mark; Dean Willis; Mpierce1@aol.com; sip@ietf.org Subject: RE: Summary of RE: [Sip] Comment, SIP Privacy draft Ben, I know this is a long thread, but I have addressed all these points before. Please see below... -----Original Message----- From: Ben Campbell [mailto:bcampbell@dynamicsoft.com] Sent: 15 April 2002 15:44 To: Chiou, Mark; Dean Willis; Mpierce1@aol.com; sip@ietf.org Subject: RE: Summary of RE: [Sip] Comment, SIP Privacy draft You pretty much have to assume that the receiving user sees _anything_ you send his UA, except in the rare case where the user has no control over the UA behavior. Asking a UAS to hide information from its owner is not useful in the generic case. I agree with Dean on this in general, although it really doesn't matter if any _network_ inserted identification is there with the consent of the originating user or not. A privacy request need _only_ apply to network-inserted identification data. The UAC has every opportunity _not_ to insert identification if it does not want to. It doesn't matter what device inserts the information. It matters whether it is part of the service for the information to be inserted. If it is a part of the service, then the responsibility lies with the Service Provider - they defined the service and they are responsible for things the users do effectively at their behest. If I check the From: field I receive from my users is valid, then I am forcing them to put either their identity or 'Anonymous' in there. If there is then a privacy requirement arising from the rights of ANOTHER PERSON, NOT THE USER, then I have to do something about this - I as the Service Provider have the responsibility, not the user. An example is when the *subscriber* has requested anonymity. If I let my users use any old From value, then the situation is not so clear, but I still argue that for fields whose intention is defined for transport of a particular identity, then the Service Provider has some responsibility. (cf Special Arrangements in the ISDN). Expecting the network to screen out ID that _I_ provide is a slippery slope. What if I put "call from Ben" in a Subject header? Do you screen that out as well? What if I _tell_ the destination user who I am in an IM associated with the call? What about the media session,? Personally, I don't think screening out the Subject would be necessary, although there might be some market demand for services which did this. Subject is a genuinely transparent field. There is no intention that it contain your identity, and UAs are unlikely to insert your identity here automatically. ...Mark -----Original Message----- From: sip-admin@ietf.org [mailto:sip-admin@ietf.org]On Behalf Of Chiou, Mark Sent: Monday, April 15, 2002 9:28 AM To: Dean Willis; Mpierce1@aol.com; sip@ietf.org Subject: RE: Summary of RE: [Sip] Comment, SIP Privacy draft Dean wrote: ##################################### The point I'm trying to make is that To and From are USER supplied information. The Service Provider doesn't insert them, inspect them, or have any responsibility for them. Insisting that the service provider change them is just like insisting that the service provider change any other user-supplied information, such as the words I'm typing now. Anything I put in my To or from field is deliberately and explicitly intended to be delivered to the terminating side of the dialog, and if as a service provider you FAIL to do that, then you have DAMAGED my data, and my lawyers will be in touch! The calling-party-identity presentation infromation (CLIP or RPID) is NOT inserted by the user. It is inserted by the network, WITHOUT THE CONSENT of the user. As such, the operator is responsible for the protection of that information in a manner consistent with regulation and the expressed wishes of the user. ########################################################## No, The CLIP is inserted by the network WITH THE CONSENT of the user. When you subscribe a line from a PSTN service provider, the form you filled indicating whether you want your telephone number to be PUBLIC or PRIVATE. (of course, the default is PUBLIC if you leave it blank.) When you make a call, the PRIVATE or PUBLIC status value is retrieved and set the Address Presentation Restricted Indicator (APRI) field in SS7 environment (Note that, CLIR toggles the values), then the terminating side of the network based on the APRI value to determine whether the Calling Party Number shall be delivered to the callee's CPE. Since we want to push the decision making to the UA, we should standardize the rule such that the UA shall display the From information based on Privacy indication. If we think that too many UAs won't follow this rule, than we should allow the Service Provider of terminating side (not the originating side) to alter the From information before terminating the call to the UA based on the Privacy indication. This is my penny thought, Mark Chiou ------=_NextPart_000_005F_01C1E472.36423D80 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Message
Yes,=20 it is a long thread :-)

I=20 pretty much agree with your original assessment for when the network=20 authenticates From, although I would propose a better behavior would be = to just=20 disallow a request with a non-anonymous From header _and_ with privacy=20 requested. This approach is more backwards compatible (in case something = involved still freaks out about modified From headers), and a lot = simpler to=20 implement in the network (no B2BUA required, at least for _this_=20 reason)

But in=20 general, the requirement that a network must prevent a badly behaved = client from=20 revealing its identity accidentally seems a bit excessive. It should be=20 sufficient to say that a client _can_ prevent its identity from being=20 revealed.

-----Original Message-----
From: Mark Watson=20 [mailto:mwatson@nortelnetworks.com]
Sent: Monday, April 15, = 2002=20 11:17 AM
To: 'Ben Campbell'; Chiou, Mark; Dean Willis;=20 Mpierce1@aol.com; sip@ietf.org
Subject: RE: Summary of RE: = [Sip]=20 Comment, SIP Privacy draft

Ben,

I=20 know this is a long thread, but I have addressed all these points = before.=20 Please see below...

-----Original Message-----
From: Ben Campbell=20 [mailto:bcampbell@dynamicsoft.com]
Sent: 15 April 2002=20 15:44
To: Chiou, Mark; Dean Willis; Mpierce1@aol.com;=20 sip@ietf.org
Subject: RE: Summary of RE: [Sip] Comment, = SIP=20 Privacy draft

You pretty much have to assume that the receiving user sees = _anything_ you send his UA, except in the rare case where the user = has no=20 control over the UA behavior. Asking a UAS to hide information from = its=20 owner is not useful in the generic case.

I=20 agree with Dean on this in general, although it really doesn't = matter if any=20 _network_ inserted identification is there with the consent of the=20 originating user or not. A privacy request need _only_ apply to=20 network-inserted identification data. The UAC has every opportunity = _not_ to=20 insert identification if it does not want to.=20

It=20 doesn't matter what device inserts the information. It matters whether = it is=20 part of the service for the information to be inserted. If it is a = part of the=20 service, then the responsibility lies with the Service Provider - they = defined=20 the service and they are responsible for things the users do = effectively at=20 their behest.

If=20 I check the From: field I receive from my users is valid, then I am = forcing=20 them to put either their identity or 'Anonymous' in = there.

If=20 there is then a privacy requirement arising from the rights of ANOTHER = PERSON,=20 NOT THE USER, then I have to do something about this - I as the = Service=20 Provider have the responsibility, not the user. An example is when the = *subscriber* has requested anonymity.

If=20 I let my users use any old From value, then the situation is not so = clear, but=20 I still argue that for fields whose intention is defined for transport = of a=20 particular identity, then the Service Provider has some = responsibility. (cf=20 Special Arrangements in the ISDN).

Expecting the network to screen out ID that _I_ provide is = a slippery=20 slope. What if I put "call from Ben" in a Subject header? Do you = screen that=20 out as well? What if I _tell_ the destination user who I am in an IM = associated with the call? What about the media session,?

Personally, I=20 don't think screening out the Subject would be necessary, although = there might=20 be some market demand for services which did this. Subject is a = genuinely=20 transparent field. There is no intention that it contain your = identity, and=20 UAs are unlikely to insert your identity here=20 automatically.

...Mark

-----Original=20 Message-----
From: sip-admin@ietf.org=20 [mailto:sip-admin@ietf.org]On Behalf Of Chiou, = Mark
Sent:=20 Monday, April 15, 2002 9:28 AM
To: Dean Willis; = Mpierce1@aol.com;=20 sip@ietf.org
Subject: RE: Summary of RE: [Sip] Comment, = SIP=20 Privacy draft

Dean wrote:

#####################################

The point I'm trying to make is that To and From = are USER=20 supplied information. The Service Provider doesn't insert = them,=20 inspect them, or have any responsibility for them. Insisting that = the=20 service provider change them is just like insisting that the = service=20 provider change any other user-supplied information, such as=20 the words I'm typing now. Anything I put in my To or from = field is=20 deliberately and explicitly intended to be delivered to the = terminating=20 side of the dialog, and if as a service provider you FAIL to do = that, then=20 you have DAMAGED my data, and my lawyers will be in=20 touch!

The calling-party-identity presentation = infromation (CLIP or RPID) is NOT inserted by the user. It is = inserted by=20 the network, WITHOUT THE CONSENT of the user. As such, the = operator is=20 responsible for the protection of that information in a manner = consistent=20 with regulation and the expressed wishes of the=20 user.

<snip>
=
##############################################= ############

No, The = CLIP is=20 inserted by the network WITH THE CONSENT of the user. When you = subscribe a=20 line from a PSTN service provider, the form you filled indicating = whether=20 you want your telephone number to be PUBLIC or PRIVATE. (of = course, the=20 default is PUBLIC if you leave it blank.) When you make a call, = the=20 PRIVATE or PUBLIC status value is retrieved and set the Address=20 Presentation Restricted Indicator (APRI) field in SS7 environment = (Note=20 that, CLIR toggles the values), then the terminating side of the = network=20 based on the APRI value to determine whether the Calling Party = Number=20 shall be delivered to the callee's CPE.

Since we = want to push=20 the decision making to the UA, we should standardize the rule such = that=20 the UA shall display the From information based on Privacy = indication. If=20 we think that too many UAs won't follow this rule, than we should = allow=20 the Service Provider of terminating side (not the originating = side) to=20 alter the From information before terminating the call to the UA = based on=20 the Privacy indication.

This is my penny=20 thought,

Mark=20 = Chiou
------=_NextPart_000_005F_01C1E472.36423D80-- _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Mon Apr 15 13:15:50 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA28488 for ; Mon, 15 Apr 2002 13:15:49 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id NAA29806 for sip-archive@odin.ietf.org; Mon, 15 Apr 2002 13:15:51 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA27924; Mon, 15 Apr 2002 12:51:23 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA27883 for ; Mon, 15 Apr 2002 12:51:19 -0400 (EDT) Received: from zctfs063.nortelnetworks.com (zctfs063.nortelnetworks.com [47.164.128.120]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA27415 for ; Mon, 15 Apr 2002 12:50:47 -0400 (EDT) Received: from znsgs01r.europe.nortel.com (znsgs01r.europe.nortel.com [47.137.129.92]) by zctfs063.nortelnetworks.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id g3FGoGg05356; Mon, 15 Apr 2002 18:50:17 +0200 (MEST) Received: from zwcwc012.europe.nortel.com (zwcwc012.europe.nortel.com [47.73.112.187]) by znsgs01r.europe.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id g3FGnbE02724; Mon, 15 Apr 2002 17:49:38 +0100 (BST) Received: by zwcwc012.europe.nortel.com with Internet Mail Service (5.5.2653.19) id ; Mon, 15 Apr 2002 17:50:14 +0100 Message-ID: From: "Mark Watson" To: "'Ben Campbell'" , "Chiou, Mark" , Dean Willis , Mpierce1@aol.com, sip@ietf.org Subject: RE: Summary of RE: [Sip] Comment, SIP Privacy draft Date: Mon, 15 Apr 2002 17:50:13 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C1E49D.9D12FBF0" Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C1E49D.9D12FBF0 Content-Type: text/plain; charset="iso-8859-1" Rejecting non-anonymous requests when anonymity is required is all very well, but a 2543 client will not know what to do in order to get its call through. It will require user intervention. For every call. How will the user know when anonymity is required ? The user does not want to be forced into anonymity unless absolutely necessary, so they will always try non-anonymous first. It's not a question of 'badly behaved clients'. The client is well-behaved and following the users instructions to be 'non-anonymous' - sure, the client can prevent its identity being revealed, but the user does not want this. The SUBSCRIBER wants anonymity, not the user. You could standardise a way of communicating the subscriber's wishes to the UA, and then enforce them. But how does this work for a forwarding user (or their subscriber) who does not wish to be identified ? ...Mark -----Original Message----- From: Ben Campbell [mailto:bcampbell@dynamicsoft.com] Sent: 15 April 2002 17:40 To: Watson, Mark [MDN05:EP10:EXCH]; Chiou, Mark; Dean Willis; Mpierce1@aol.com; sip@ietf.org Subject: RE: Summary of RE: [Sip] Comment, SIP Privacy draft Yes, it is a long thread :-) I pretty much agree with your original assessment for when the network authenticates From, although I would propose a better behavior would be to just disallow a request with a non-anonymous From header _and_ with privacy requested. This approach is more backwards compatible (in case something involved still freaks out about modified From headers), and a lot simpler to implement in the network (no B2BUA required, at least for _this_ reason) But in general, the requirement that a network must prevent a badly behaved client from revealing its identity accidentally seems a bit excessive. It should be sufficient to say that a client _can_ prevent its identity from being revealed. -----Original Message----- From: Mark Watson [mailto:mwatson@nortelnetworks.com] Sent: Monday, April 15, 2002 11:17 AM To: 'Ben Campbell'; Chiou, Mark; Dean Willis; Mpierce1@aol.com; sip@ietf.org Subject: RE: Summary of RE: [Sip] Comment, SIP Privacy draft Ben, I know this is a long thread, but I have addressed all these points before. Please see below... -----Original Message----- From: Ben Campbell [mailto:bcampbell@dynamicsoft.com] Sent: 15 April 2002 15:44 To: Chiou, Mark; Dean Willis; Mpierce1@aol.com; sip@ietf.org Subject: RE: Summary of RE: [Sip] Comment, SIP Privacy draft You pretty much have to assume that the receiving user sees _anything_ you send his UA, except in the rare case where the user has no control over the UA behavior. Asking a UAS to hide information from its owner is not useful in the generic case. I agree with Dean on this in general, although it really doesn't matter if any _network_ inserted identification is there with the consent of the originating user or not. A privacy request need _only_ apply to network-inserted identification data. The UAC has every opportunity _not_ to insert identification if it does not want to. It doesn't matter what device inserts the information. It matters whether it is part of the service for the information to be inserted. If it is a part of the service, then the responsibility lies with the Service Provider - they defined the service and they are responsible for things the users do effectively at their behest. If I check the From: field I receive from my users is valid, then I am forcing them to put either their identity or 'Anonymous' in there. If there is then a privacy requirement arising from the rights of ANOTHER PERSON, NOT THE USER, then I have to do something about this - I as the Service Provider have the responsibility, not the user. An example is when the *subscriber* has requested anonymity. If I let my users use any old From value, then the situation is not so clear, but I still argue that for fields whose intention is defined for transport of a particular identity, then the Service Provider has some responsibility. (cf Special Arrangements in the ISDN). Expecting the network to screen out ID that _I_ provide is a slippery slope. What if I put "call from Ben" in a Subject header? Do you screen that out as well? What if I _tell_ the destination user who I am in an IM associated with the call? What about the media session,? Personally, I don't think screening out the Subject would be necessary, although there might be some market demand for services which did this. Subject is a genuinely transparent field. There is no intention that it contain your identity, and UAs are unlikely to insert your identity here automatically. ...Mark -----Original Message----- From: sip-admin@ietf.org [mailto:sip-admin@ietf.org]On Behalf Of Chiou, Mark Sent: Monday, April 15, 2002 9:28 AM To: Dean Willis; Mpierce1@aol.com; sip@ietf.org Subject: RE: Summary of RE: [Sip] Comment, SIP Privacy draft Dean wrote: ##################################### The point I'm trying to make is that To and From are USER supplied information. The Service Provider doesn't insert them, inspect them, or have any responsibility for them. Insisting that the service provider change them is just like insisting that the service provider change any other user-supplied information, such as the words I'm typing now. Anything I put in my To or from field is deliberately and explicitly intended to be delivered to the terminating side of the dialog, and if as a service provider you FAIL to do that, then you have DAMAGED my data, and my lawyers will be in touch! The calling-party-identity presentation infromation (CLIP or RPID) is NOT inserted by the user. It is inserted by the network, WITHOUT THE CONSENT of the user. As such, the operator is responsible for the protection of that information in a manner consistent with regulation and the expressed wishes of the user. ########################################################## No, The CLIP is inserted by the network WITH THE CONSENT of the user. When you subscribe a line from a PSTN service provider, the form you filled indicating whether you want your telephone number to be PUBLIC or PRIVATE. (of course, the default is PUBLIC if you leave it blank.) When you make a call, the PRIVATE or PUBLIC status value is retrieved and set the Address Presentation Restricted Indicator (APRI) field in SS7 environment (Note that, CLIR toggles the values), then the terminating side of the network based on the APRI value to determine whether the Calling Party Number shall be delivered to the callee's CPE. Since we want to push the decision making to the UA, we should standardize the rule such that the UA shall display the From information based on Privacy indication. If we think that too many UAs won't follow this rule, than we should allow the Service Provider of terminating side (not the originating side) to alter the From information before terminating the call to the UA based on the Privacy indication. This is my penny thought, Mark Chiou ------_=_NextPart_001_01C1E49D.9D12FBF0 Content-Type: text/html; charset="iso-8859-1" Message
Rejecting non-anonymous requests when anonymity is required is all very well, but a 2543 client will not know what to do in order to get its call through. It will require user intervention. For every call. How will the user know when anonymity is required ? The user does not want to be forced into anonymity unless absolutely necessary, so they will always try non-anonymous first.

It's not a question of 'badly behaved clients'. The client is well-behaved and following the users instructions to be 'non-anonymous' - sure, the client can prevent its identity being revealed, but the user does not want this. The SUBSCRIBER wants anonymity, not the user.

You could standardise a way of communicating the subscriber's wishes to the UA, and then enforce them. But how does this work for a forwarding user (or their subscriber) who does not wish to be identified ?

...Mark

-----Original Message-----
From: Ben Campbell [mailto:bcampbell@dynamicsoft.com]
Sent: 15 April 2002 17:40
To: Watson, Mark [MDN05:EP10:EXCH]; Chiou, Mark; Dean Willis; Mpierce1@aol.com; sip@ietf.org
Subject: RE: Summary of RE: [Sip] Comment, SIP Privacy draft

Yes, it is a long thread :-)

I pretty much agree with your original assessment for when the network authenticates From, although I would propose a better behavior would be to just disallow a request with a non-anonymous From header _and_ with privacy requested. This approach is more backwards compatible (in case something involved still freaks out about modified From headers), and a lot simpler to implement in the network (no B2BUA required, at least for _this_ reason)

But in general, the requirement that a network must prevent a badly behaved client from revealing its identity accidentally seems a bit excessive. It should be sufficient to say that a client _can_ prevent its identity from being revealed.

-----Original Message-----
From: Mark Watson [mailto:mwatson@nortelnetworks.com]
Sent: Monday, April 15, 2002 11:17 AM
To: 'Ben Campbell'; Chiou, Mark; Dean Willis; Mpierce1@aol.com; sip@ietf.org
Subject: RE: Summary of RE: [Sip] Comment, SIP Privacy draft

Ben,

I know this is a long thread, but I have addressed all these points before. Please see below...

-----Original Message-----
From: Ben Campbell [mailto:bcampbell@dynamicsoft.com]
Sent: 15 April 2002 15:44
To: Chiou, Mark; Dean Willis; Mpierce1@aol.com; sip@ietf.org
Subject: RE: Summary of RE: [Sip] Comment, SIP Privacy draft

You pretty much have to assume that the receiving user sees _anything_ you send his UA, except in the rare case where the user has no control over the UA behavior. Asking a UAS to hide information from its owner is not useful in the generic case.

I agree with Dean on this in general, although it really doesn't matter if any _network_ inserted identification is there with the consent of the originating user or not. A privacy request need _only_ apply to network-inserted identification data. The UAC has every opportunity _not_ to insert identification if it does not want to.

It doesn't matter what device inserts the information. It matters whether it is part of the service for the information to be inserted. If it is a part of the service, then the responsibility lies with the Service Provider - they defined the service and they are responsible for things the users do effectively at their behest.

If I check the From: field I receive from my users is valid, then I am forcing them to put either their identity or 'Anonymous' in there.

If there is then a privacy requirement arising from the rights of ANOTHER PERSON, NOT THE USER, then I have to do something about this - I as the Service Provider have the responsibility, not the user. An example is when the *subscriber* has requested anonymity.

If I let my users use any old From value, then the situation is not so clear, but I still argue that for fields whose intention is defined for transport of a particular identity, then the Service Provider has some responsibility. (cf Special Arrangements in the ISDN).

Expecting the network to screen out ID that _I_ provide is a slippery slope. What if I put "call from Ben" in a Subject header? Do you screen that out as well? What if I _tell_ the destination user who I am in an IM associated with the call? What about the media session,?

Personally, I don't think screening out the Subject would be necessary, although there might be some market demand for services which did this. Subject is a genuinely transparent field. There is no intention that it contain your identity, and UAs are unlikely to insert your identity here automatically.

...Mark

-----Original Message-----
From: sip-admin@ietf.org [mailto:sip-admin@ietf.org]On Behalf Of Chiou, Mark
Sent: Monday, April 15, 2002 9:28 AM
To: Dean Willis; Mpierce1@aol.com; sip@ietf.org
Subject: RE: Summary of RE: [Sip] Comment, SIP Privacy draft

Dean wrote:

#####################################

The point I'm trying to make is that To and From are USER supplied information. The Service Provider doesn't insert them, inspect them, or have any responsibility for them. Insisting that the service provider change them is just like insisting that the service provider change any other user-supplied information, such as the words I'm typing now. Anything I put in my To or from field is deliberately and explicitly intended to be delivered to the terminating side of the dialog, and if as a service provider you FAIL to do that, then you have DAMAGED my data, and my lawyers will be in touch!

The calling-party-identity presentation infromation (CLIP or RPID) is NOT inserted by the user. It is inserted by the network, WITHOUT THE CONSENT of the user. As such, the operator is responsible for the protection of that information in a manner consistent with regulation and the expressed wishes of the user.

<snip>

##########################################################

No, The CLIP is inserted by the network WITH THE CONSENT of the user. When you subscribe a line from a PSTN service provider, the form you filled indicating whether you want your telephone number to be PUBLIC or PRIVATE. (of course, the default is PUBLIC if you leave it blank.) When you make a call, the PRIVATE or PUBLIC status value is retrieved and set the Address Presentation Restricted Indicator (APRI) field in SS7 environment (Note that, CLIR toggles the values), then the terminating side of the network based on the APRI value to determine whether the Calling Party Number shall be delivered to the callee's CPE.

Since we want to push the decision making to the UA, we should standardize the rule such that the UA shall display the From information based on Privacy indication. If we think that too many UAs won't follow this rule, than we should allow the Service Provider of terminating side (not the originating side) to alter the From information before terminating the call to the UA based on the Privacy indication.

This is my penny thought,

Mark Chiou
------_=_NextPart_001_01C1E49D.9D12FBF0-- _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Mon Apr 15 13:16:17 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA28531 for ; Mon, 15 Apr 2002 13:16:12 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id NAA29822 for sip-archive@odin.ietf.org; Mon, 15 Apr 2002 13:16:14 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA27859; Mon, 15 Apr 2002 12:50:50 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA27744 for ; Mon, 15 Apr 2002 12:50:39 -0400 (EDT) Received: from imo-r03.mx.aol.com (imo-r03.mx.aol.com [152.163.225.99]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA27411 for ; Mon, 15 Apr 2002 12:50:37 -0400 (EDT) From: Mpierce1@aol.com Received: from Mpierce1@aol.com by imo-r03.mx.aol.com (mail_out_v32.5.) id r.1a9.c3121d (4564); Mon, 15 Apr 2002 12:49:43 -0400 (EDT) Message-ID: <1a9.c3121d.29ec5ea7@aol.com> Date: Mon, 15 Apr 2002 12:49:43 EDT Subject: Re: Summary of RE: [Sip] Comment, SIP Privacy draft To: bcampbell@dynamicsoft.com, MChiou@Santera.com, dean.willis@softarmor.com, sip@ietf.org MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="part1_1a9.c3121d.29ec5ea7_boundary" X-Mailer: AOL 6.0 for Windows US sub 10524 Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org --part1_1a9.c3121d.29ec5ea7_boundary Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit In a message dated 4/15/02 10:45:08 AM Eastern Daylight Time, bcampbell@dynamicsoft.com writes: > You pretty much have to assume that the receiving user sees _anything_ you > send his UA, except in the rare case where the user has no control over the > UA behavior. Asking a UAS to hide information from its owner is not useful > in the generic case. I don't believe anyone has suggested (I hope) that the receiving user's UA should be responsible for hiding the information. It is always the last "trusted" entity which must do this, i.e., the "service provider" in Mark Chiou's comments. The exception, of course, might be when the terminating UA is also "trusted" by the service provider, but I'm not sure of a good example of this. The terminating UA would then be like an extension of the "Service Provider". > I agree with Dean on this in general, although it really doesn't matter if > any _network_ inserted identification is there with the consent of the > originating user or not. A privacy request need _only_ apply to > network-inserted identification data. The UAC has every opportunity _not_ > I believe that every identification inserted must be "with consent" of the originating user, either explicitly by user action, or implicitly by the fact that they made a phone call. And no, a privacy request does not only apply to network-inserted identifcation data. (Compare to the ISDN case in which the originating user inserts their phone number and also indicates that it is to be kept private, i.e., not delivered to the other user. The network verifies it and passes it through their trusted network or to another trusted network. The requirement in SIP is not different.) Just to confuse the issue a little more, maybe I should remind everyone at this point, that, at least in the US, when the originator says their identity should be kept private, it is still delivered at the other end for an "800" call. Also, some years ago, Florida created special office codes to override the originator's privacy desire when calls terminated to those special office codes. I don't know if that stupid capability still exists in Florida. And no, the UAC does not have the opportunity to not insert an identification if the "Service Provider" requires it as a prerequisite for service. > Expecting the network to screen out ID that _I_ provide is a slippery slope. > What if I put "call from Ben" in a Subject header? Do you screen that out > as well? What if I _tell_ the destination user who I am in an IM associated > with the call? What about the media session,? > > Providing an ID in a field defined for that prupose (for the benefit of the network and required trace) and have the network "screen" it is not a slippary slope. It is exactly what must be done and is straight forward. I hope we have agreed across the board that the network would never screen the contents of other fields such as the Subject header. Mike --part1_1a9.c3121d.29ec5ea7_boundary Content-Type: text/html; charset="US-ASCII" Content-Transfer-Encoding: 7bit In a message dated 4/15/02 10:45:08 AM Eastern Daylight Time, bcampbell@dynamicsoft.com writes:

You pretty much have to assume that the receiving user sees _anything_ you send his UA, except in the rare case where the user has no control over the UA behavior. Asking a UAS to hide information from its owner is not useful in the generic case.

I don't believe anyone has suggested (I hope) that the receiving user's UA should be responsible for hiding the information. It is always the last "trusted" entity which must do this, i.e., the "service provider" in Mark Chiou's comments. The exception, of course, might be when the terminating UA is also "trusted" by the service provider, but I'm not sure of a good example of this. The terminating UA would then be like an extension of the "Service Provider".

I agree with Dean on this in general, although it really doesn't matter if any _network_ inserted identification is there with the consent of the originating user or not. A privacy request need _only_ apply to network-inserted identification data. The UAC has every opportunity _not_ to insert identification if it does not want to.

I believe that every identification inserted must be "with consent" of the originating user, either explicitly by user action, or implicitly by the fact that they made a phone call. And no, a privacy request does not only apply to network-inserted identifcation data. (Compare to the ISDN case in which the originating user inserts their phone number and also indicates that it is to be kept private, i.e., not delivered to the other user. The network verifies it and passes it through their trusted network or to another trusted network. The requirement in SIP is not different.)

Just to confuse the issue a little more, maybe I should remind everyone at this point, that, at least in the US, when the originator says their identity should be kept private, it is still delivered at the other end for an "800" call. Also, some years ago, Florida created special office codes to override the originator's privacy desire when calls terminated to those special office codes. I don't know if that stupid capability still exists in Florida.

And no, the UAC does not have the opportunity to not insert an identification if the "Service Provider" requires it as a prerequisite for service.

Expecting the network to screen out ID that _I_ provide is a slippery slope. What if I put "call from Ben" in a Subject header? Do you screen that out as well? What if I _tell_ the destination user who I am in an IM associated with the call? What about the media session,?

Providing an ID in a field defined for that prupose (for the benefit of the network and required trace) and have the network "screen" it is not a slippary slope. It is exactly what must be done and is straight forward.

I hope we have agreed across the board that the network would never screen the contents of other fields such as the Subject header.

Mike

--part1_1a9.c3121d.29ec5ea7_boundary-- _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Mon Apr 15 13:16:36 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA28555 for ; Mon, 15 Apr 2002 13:16:36 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id NAA29846 for sip-archive@odin.ietf.org; Mon, 15 Apr 2002 13:16:36 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA27984; Mon, 15 Apr 2002 12:51:38 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA27946 for ; Mon, 15 Apr 2002 12:51:34 -0400 (EDT) Received: from imo-r02.mx.aol.com (imo-r02.mx.aol.com [152.163.225.98]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA27462 for ; Mon, 15 Apr 2002 12:51:32 -0400 (EDT) From: Mpierce1@aol.com Received: from Mpierce1@aol.com by imo-r02.mx.aol.com (mail_out_v32.5.) id 7.168.c203418 (4564); Mon, 15 Apr 2002 12:49:41 -0400 (EDT) Message-ID: <168.c203418.29ec5ea4@aol.com> Date: Mon, 15 Apr 2002 12:49:40 EDT Subject: Re: Summary of RE: [Sip] Comment, SIP Privacy draft To: hgs@cs.columbia.edu, mat@cisco.com CC: Brian.Rosen@marconi.com, mwatson@nortelnetworks.com, jdrosen@dynamicsoft.com, sip@ietf.org MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="part1_168.c203418.29ec5ea4_boundary" X-Mailer: AOL 6.0 for Windows US sub 10524 Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org --part1_168.c203418.29ec5ea4_boundary Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit In a message dated 4/12/02 4:07:34 PM Eastern Daylight Time, hgs@cs.columbia.edu writes: > > I don't think anticipating regulation is particularly helpful here. > Anybody can say anything about what some legislature somewhere may > legislate at some point in the future. > I wasn't speaking of "anticipating regulation" but rather current legislation that will eventually applied to SIP-based telephony whenever someone wants to sell a regular telephony service using SIP in place of what is currently provided over circuit switched technology. It will take a very simple action by a state utility commission to declare that its rules for circuit switched also must apply to packet-based telephony. It would be foolish to ignore this eventuality. > I wouldn't be too surprised if, instead of PSTN legislation, some of the > email spam legislation finds its way into SIP behavior, e.g., having to > declare a truthful return address, an indication of the call intent > (like some of the laws and bills calling for adding ADV to the subject > line) or including an opt-out link (header?). If we could make progress > there, I think we'd do more for "privacy" than hiding a user name. > > Just like the law today for FAX (in the US) - every call must be identified with the source. Yes, I suspect that this will become required for SIP, not necessarily by law, but by any responsible service provider as a prerequisite for setting up a session. Mike --part1_168.c203418.29ec5ea4_boundary Content-Type: text/html; charset="US-ASCII" Content-Transfer-Encoding: 7bit In a message dated 4/12/02 4:07:34 PM Eastern Daylight Time, hgs@cs.columbia.edu writes:

I don't think anticipating regulation is particularly helpful here.
Anybody can say anything about what some legislature somewhere may
legislate at some point in the future.

I wasn't speaking of "anticipating regulation" but rather current legislation that will eventually applied to SIP-based telephony whenever someone wants to sell a regular telephony service using SIP in place of what is currently provided over circuit switched technology. It will take a very simple action by a state utility commission to declare that its rules for circuit switched also must apply to packet-based telephony. It would be foolish to ignore this eventuality.

I wouldn't be too surprised if, instead of PSTN legislation, some of the
email spam legislation finds its way into SIP behavior, e.g., having to
declare a truthful return address, an indication of the call intent
(like some of the laws and bills calling for adding ADV to the subject
line) or including an opt-out link (header?). If we could make progress
there, I think we'd do more for "privacy" than hiding a user name.

Just like the law today for FAX (in the US) - every call must be identified with the source. Yes, I suspect that this will become required for SIP, not necessarily by law, but by any responsible service provider as a prerequisite for setting up a session.

Mike
--part1_168.c203418.29ec5ea4_boundary-- _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Mon Apr 15 13:19:18 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA28645 for ; Mon, 15 Apr 2002 13:19:18 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id NAA29929 for sip-archive@odin.ietf.org; Mon, 15 Apr 2002 13:19:19 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA27413; Mon, 15 Apr 2002 12:46:49 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA27383 for ; Mon, 15 Apr 2002 12:46:45 -0400 (EDT) Received: from sj-msg-core-3.cisco.com (sj-msg-core-3.cisco.com [171.70.157.152]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA27004 for ; Mon, 15 Apr 2002 12:46:43 -0400 (EDT) Received: from mira-sjc5-9.cisco.com (IDENT:mirapoint@mira-sjc5-9.cisco.com [171.71.163.32]) by sj-msg-core-3.cisco.com (8.12.2/8.12.2) with ESMTP id g3FGjviL004282; Mon, 15 Apr 2002 09:45:57 -0700 (PDT) Received: from OranLT ([161.44.238.53]) by mira-sjc5-9.cisco.com (Mirapoint) with ESMTP id ACQ33118; Mon, 15 Apr 2002 09:46:23 -0700 (PDT) From: "David R. Oran" To: "'Rosen, Brian'" , , Subject: RE: Summary of RE: [Sip] Comment, SIP Privacy draft Date: Mon, 15 Apr 2002 12:38:52 -0400 Organization: Cisco Systems Message-ID: <009e01c1e49c$07d671d0$0c77fea9@OranLT> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.3416 In-Reply-To: <313680C9A886D511A06000204840E1CF57CE4D@whq-msgusr-02.pit.comms.marconi.com> Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit Brian Rosen wrote: >If we could get consensus that trace-with-anonymity is the problem, then > we can > work on solutions. Until we get to something as straightforward as > that, > we are going to spin a lot of wheels. That's always been the prime motivator for me, plus the secondary use of NAI for call return to an anonymous caller. Dave _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Mon Apr 15 13:33:00 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA29040 for ; Mon, 15 Apr 2002 13:32:44 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id NAA01129 for sip-archive@odin.ietf.org; Mon, 15 Apr 2002 13:32:46 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA29376; Mon, 15 Apr 2002 13:09:14 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA29347 for ; Mon, 15 Apr 2002 13:09:11 -0400 (EDT) Received: from magus.nostrum.com (root@magus.nostrum.com [66.119.225.66]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA28138 for ; Mon, 15 Apr 2002 13:09:06 -0400 (EDT) Received: from txbcampbell (root@magus.nostrum.com [66.119.225.66]) by magus.nostrum.com (8.11.0/8.11.0) with SMTP id g3FH8tX58439; Mon, 15 Apr 2002 12:08:55 -0500 (CDT) From: "Ben Campbell" To: "Mark Watson" , "Chiou, Mark" , "Dean Willis" , , Subject: RE: Summary of RE: [Sip] Comment, SIP Privacy draft Date: Mon, 15 Apr 2002 12:08:34 -0500 Message-ID: MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_006B_01C1E476.44282500" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Importance: Normal Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org This is a multi-part message in MIME format. ------=_NextPart_000_006B_01C1E476.44282500 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message -----Original Message----- From: sip-admin@ietf.org [mailto:sip-admin@ietf.org]On Behalf Of Mark Watson Sent: Monday, April 15, 2002 11:50 AM To: 'Ben Campbell'; Chiou, Mark; Dean Willis; Mpierce1@aol.com; sip@ietf.org Subject: RE: Summary of RE: [Sip] Comment, SIP Privacy draft Rejecting non-anonymous requests when anonymity is required is all very well, but a 2543 client will not know what to do in order to get its call through. It will require user intervention. For every call. How will the user know when anonymity is required ? The user does not want to be forced into anonymity unless absolutely necessary, so they will always try non-anonymous first. I'm not sure how a 2543 client will know how to request privacy in the first place. And I assume that a user knows whether or not he wishes to make an anonymous call. I cannot think of a _technical_ solution for helping a user decide if a call should be anonymous or not. It's not a question of 'badly behaved clients'. The client is well-behaved and following the users instructions to be 'non-anonymous' - sure, the client can prevent its identity being revealed, but the user does not want this. The SUBSCRIBER wants anonymity, not the user. I'm not sure what you mean--who is the subscriber, if not the user (i.e. the person trying to place an anonymous call)? (This may be the source of my confusion in the previous paragraph. I was using the term "user" and "subscriber" interchangeably.) You could standardise a way of communicating the subscriber's wishes to the UA, and then enforce them. But how does this work for a forwarding user (or their subscriber) who does not wish to be identified ? Presumadly if a UA supports anonymous calling, it must give the subscriber some way of expressing the desire to do so. I don't see any need to standardize that. Once the subscriber expresses that desire, it is up to the UA to do things right (like, don't _automatically_ put user identifiable information in headers, From or otherwise.) A UA that pretends to support anonymity but screws it up fits my definition of "badly behaved." ...Mark -----Original Message----- From: Ben Campbell [mailto:bcampbell@dynamicsoft.com] Sent: 15 April 2002 17:40 To: Watson, Mark [MDN05:EP10:EXCH]; Chiou, Mark; Dean Willis; Mpierce1@aol.com; sip@ietf.org Subject: RE: Summary of RE: [Sip] Comment, SIP Privacy draft Yes, it is a long thread :-) I pretty much agree with your original assessment for when the network authenticates From, although I would propose a better behavior would be to just disallow a request with a non-anonymous From header _and_ with privacy requested. This approach is more backwards compatible (in case something involved still freaks out about modified From headers), and a lot simpler to implement in the network (no B2BUA required, at least for _this_ reason) But in general, the requirement that a network must prevent a badly behaved client from revealing its identity accidentally seems a bit excessive. It should be sufficient to say that a client _can_ prevent its identity from being revealed. -----Original Message----- From: Mark Watson [mailto:mwatson@nortelnetworks.com] Sent: Monday, April 15, 2002 11:17 AM To: 'Ben Campbell'; Chiou, Mark; Dean Willis; Mpierce1@aol.com; sip@ietf.org Subject: RE: Summary of RE: [Sip] Comment, SIP Privacy draft Ben, I know this is a long thread, but I have addressed all these points before. Please see below... -----Original Message----- From: Ben Campbell [mailto:bcampbell@dynamicsoft.com] Sent: 15 April 2002 15:44 To: Chiou, Mark; Dean Willis; Mpierce1@aol.com; sip@ietf.org Subject: RE: Summary of RE: [Sip] Comment, SIP Privacy draft You pretty much have to assume that the receiving user sees _anything_ you send his UA, except in the rare case where the user has no control over the UA behavior. Asking a UAS to hide information from its owner is not useful in the generic case. I agree with Dean on this in general, although it really doesn't matter if any _network_ inserted identification is there with the consent of the originating user or not. A privacy request need _only_ apply to network-inserted identification data. The UAC has every opportunity _not_ to insert identification if it does not want to. It doesn't matter what device inserts the information. It matters whether it is part of the service for the information to be inserted. If it is a part of the service, then the responsibility lies with the Service Provider - they defined the service and they are responsible for things the users do effectively at their behest. If I check the From: field I receive from my users is valid, then I am forcing them to put either their identity or 'Anonymous' in there. If there is then a privacy requirement arising from the rights of ANOTHER PERSON, NOT THE USER, then I have to do something about this - I as the Service Provider have the responsibility, not the user. An example is when the *subscriber* has requested anonymity. If I let my users use any old From value, then the situation is not so clear, but I still argue that for fields whose intention is defined for transport of a particular identity, then the Service Provider has some responsibility. (cf Special Arrangements in the ISDN). Expecting the network to screen out ID that _I_ provide is a slippery slope. What if I put "call from Ben" in a Subject header? Do you screen that out as well? What if I _tell_ the destination user who I am in an IM associated with the call? What about the media session,? Personally, I don't think screening out the Subject would be necessary, although there might be some market demand for services which did this. Subject is a genuinely transparent field. There is no intention that it contain your identity, and UAs are unlikely to insert your identity here automatically. ...Mark -----Original Message----- From: sip-admin@ietf.org [mailto:sip-admin@ietf.org]On Behalf Of Chiou, Mark Sent: Monday, April 15, 2002 9:28 AM To: Dean Willis; Mpierce1@aol.com; sip@ietf.org Subject: RE: Summary of RE: [Sip] Comment, SIP Privacy draft Dean wrote: ##################################### The point I'm trying to make is that To and From are USER supplied information. The Service Provider doesn't insert them, inspect them, or have any responsibility for them. Insisting that the service provider change them is just like insisting that the service provider change any other user-supplied information, such as the words I'm typing now. Anything I put in my To or from field is deliberately and explicitly intended to be delivered to the terminating side of the dialog, and if as a service provider you FAIL to do that, then you have DAMAGED my data, and my lawyers will be in touch! The calling-party-identity presentation infromation (CLIP or RPID) is NOT inserted by the user. It is inserted by the network, WITHOUT THE CONSENT of the user. As such, the operator is responsible for the protection of that information in a manner consistent with regulation and the expressed wishes of the user. ########################################################## No, The CLIP is inserted by the network WITH THE CONSENT of the user. When you subscribe a line from a PSTN service provider, the form you filled indicating whether you want your telephone number to be PUBLIC or PRIVATE. (of course, the default is PUBLIC if you leave it blank.) When you make a call, the PRIVATE or PUBLIC status value is retrieved and set the Address Presentation Restricted Indicator (APRI) field in SS7 environment (Note that, CLIR toggles the values), then the terminating side of the network based on the APRI value to determine whether the Calling Party Number shall be delivered to the callee's CPE. Since we want to push the decision making to the UA, we should standardize the rule such that the UA shall display the From information based on Privacy indication. If we think that too many UAs won't follow this rule, than we should allow the Service Provider of terminating side (not the originating side) to alter the From information before terminating the call to the UA based on the Privacy indication. This is my penny thought, Mark Chiou ------=_NextPart_000_006B_01C1E476.44282500 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Message

-----Original Message-----
From: sip-admin@ietf.org = [mailto:sip-admin@ietf.org]On Behalf Of Mark = Watson
Sent:=20 Monday, April 15, 2002 11:50 AM
To: 'Ben Campbell'; Chiou, = Mark;=20 Dean Willis; Mpierce1@aol.com; sip@ietf.org
Subject: RE: = Summary of=20 RE: [Sip] Comment, SIP Privacy draft

Rejecting non-anonymous requests when = anonymity is=20 required is all very well, but a 2543 client will not know what to do = in order=20 to get its call through. It will require user intervention. For every = call.=20 How will the user know when anonymity is required ? The user does not = want to=20 be forced into anonymity unless absolutely necessary, so they will = always try=20 non-anonymous first.

I'm not=20 sure how a 2543 client will know how to request privacy in the first = place.=20 And I assume that a user knows whether or not he wishes to make an = anonymous=20 call. I cannot think of a _technical_ solution for helping a user = decide=20 if a call should be anonymous or=20 not.

It's not = a question=20 of 'badly behaved clients'. The client is well-behaved and following = the users=20 instructions to be 'non-anonymous' - sure, the client can prevent its = identity=20 being revealed, but the user does not want this. The SUBSCRIBER wants=20 anonymity, not the user.

I'm not=20 sure what you mean--who is the subscriber, if not the user (i.e. the = person=20 trying to place an anonymous call)? (This=20 may be the source of my confusion in the previous paragraph. I was = using the=20 term "user" and "subscriber"=20 interchangeably.)

You could standardise a way of communicating the = subscriber's=20 wishes to the UA, and then enforce them. But how does this work for a=20 forwarding user (or their subscriber) who does not wish to be = identified=20 ?

Presumadly if a UA supports anonymous calling, it = must give the=20 subscriber some way of expressing the desire to do so. I don't see any = need to=20 standardize that. Once the subscriber expresses that desire, it = is up to=20 the UA to do things right (like, don't _automatically_ put=20 user identifiable information in headers, From or=20 otherwise.) A UA that = pretends to support=20 anonymity but screws it up fits my definition of "badly=20 behaved."

...Mark

-----Original Message-----
From: Ben Campbell=20 [mailto:bcampbell@dynamicsoft.com]
Sent: 15 April 2002=20 17:40
To: Watson, Mark [MDN05:EP10:EXCH]; Chiou, Mark; = Dean=20 Willis; Mpierce1@aol.com; sip@ietf.org
Subject: RE: = Summary of RE:=20 [Sip] Comment, SIP Privacy draft

Yes, it is a long thread :-)

I=20 pretty much agree with your original assessment for when the network = authenticates From, although I would propose a better behavior would = be to=20 just disallow a request with a non-anonymous From header _and_ with = privacy=20 requested. This approach is more backwards compatible (in case = something=20 involved still freaks out about modified From headers), and a lot = simpler to=20 implement in the network (no B2BUA required, at least for _this_=20 reason)

But in general, the requirement that a network must prevent = a badly=20 behaved client from revealing its identity accidentally seems a bit=20 excessive. It should be sufficient to say that a client _can_ = prevent its=20 identity from being revealed.

-----Original Message-----
From: Mark Watson=20 [mailto:mwatson@nortelnetworks.com]
Sent: Monday, April = 15, 2002=20 11:17 AM
To: 'Ben Campbell'; Chiou, Mark; Dean Willis;=20 Mpierce1@aol.com; sip@ietf.org
Subject: RE: Summary of = RE: [Sip]=20 Comment, SIP Privacy draft

Ben,

I know this is a long thread, but I = have=20 addressed all these points before. Please see = below...

-----Original Message-----
From: Ben Campbell = [mailto:bcampbell@dynamicsoft.com]
Sent: 15 April 2002 = 15:44
To: Chiou, Mark; Dean Willis; Mpierce1@aol.com;=20 sip@ietf.org
Subject: RE: Summary of RE: [Sip] = Comment, SIP=20 Privacy draft

You pretty much have to assume that the receiving user = sees=20 _anything_ you send his UA, except in the rare case where the = user has=20 no control over the UA behavior. Asking a UAS to hide = information from=20 its owner is not useful in the generic case.

I agree with Dean on this in general, although it = really doesn't=20 matter if any _network_ inserted identification is there with = the=20 consent of the originating user or not. A privacy request need = _only_=20 apply to network-inserted identification data. The UAC has every = opportunity _not_ to insert identification if it does not want = to.=20

It doesn't matter what device inserts = the=20 information. It matters whether it is part of the service for the=20 information to be inserted. If it is a part of the service, then = the=20 responsibility lies with the Service Provider - they defined the = service=20 and they are responsible for things the users do effectively at = their=20 behest.

If I check the From: field I receive = from my=20 users is valid, then I am forcing them to put either their = identity or=20 'Anonymous' in there.

If there is then a privacy requirement = arising=20 from the rights of ANOTHER PERSON, NOT THE USER, then I have to do = something about this - I as the Service Provider have the = responsibility,=20 not the user. An example is when the *subscriber* has requested=20 anonymity.

If I let my users use any old From = value, then=20 the situation is not so clear, but I still argue that for fields = whose=20 intention is defined for transport of a particular identity, then = the=20 Service Provider has some responsibility. (cf Special Arrangements = in the=20 ISDN).

Expecting the network to screen out ID that _I_ provide = is a=20 slippery slope. What if I put "call from Ben" in a Subject = header? Do=20 you screen that out as well? What if I _tell_ the destination = user who I=20 am in an IM associated with the call? What about the media=20 session,?

Personally, I don't think screening out = the=20 Subject would be necessary, although there might be some market = demand for=20 services which did this. Subject is a genuinely transparent = field.=20 There is no intention that it contain your identity, and UAs are = unlikely=20 to insert your identity here=20 automatically.

...Mark

-----Original=20 Message-----
From: sip-admin@ietf.org=20 [mailto:sip-admin@ietf.org]On Behalf Of Chiou,=20 Mark
Sent: Monday, April 15, 2002 9:28 = AM
To: Dean=20 Willis; Mpierce1@aol.com; sip@ietf.org
Subject: RE: = Summary of=20 RE: [Sip] Comment, SIP Privacy draft

Dean wrote:

#####################################

The point I'm trying to make is that To and = From are=20 USER supplied information. The Service Provider doesn't = insert=20 them, inspect them, or have any responsibility for them. = Insisting=20 that the service provider change them is just = like insisting that=20 the service provider change any other user-supplied=20 information, such as the words I'm typing now. = Anything I=20 put in my To or from field is deliberately and explicitly = intended to=20 be delivered to the terminating side of the dialog, and if as = a=20 service provider you FAIL to do that, then you have DAMAGED my = data,=20 and my lawyers will be in=20 touch!

The calling-party-identity = presentation=20 infromation (CLIP or RPID) is NOT inserted by the user. It is = inserted=20 by the network, WITHOUT THE CONSENT of the user. As such, the = operator=20 is responsible for the protection of that information in a = manner=20 consistent with regulation and the expressed wishes of the=20 user.

<snip>
=
##############################################= ############

No, = The CLIP is=20 inserted by the network WITH THE CONSENT of the user. When you = subscribe a line from a PSTN service provider, the form you = filled=20 indicating whether you want your telephone number to be PUBLIC = or=20 PRIVATE. (of course, the default is PUBLIC if you leave it = blank.)=20 When you make a call, the PRIVATE or PUBLIC status value is = retrieved=20 and set the Address Presentation Restricted Indicator (APRI) = field in=20 SS7 environment (Note that, CLIR toggles the values), then the = terminating side of the network based on the APRI value to = determine=20 whether the Calling Party Number shall be delivered to the = callee's=20 CPE.

Since = we want to=20 push the decision making to the UA, we should standardize the = rule=20 such that the UA shall display the From information based on = Privacy=20 indication. If we think that too many UAs won't follow this = rule, than=20 we should allow the Service Provider of terminating side (not = the=20 originating side) to alter the From information before = terminating the=20 call to the UA based on the Privacy = indication.

This is my penny = thought,

Mark=20 = Chiou
------=_NextPart_000_006B_01C1E476.44282500-- _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Mon Apr 15 14:10:44 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA00601 for ; Mon, 15 Apr 2002 14:10:44 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id OAA03329 for sip-archive@odin.ietf.org; Mon, 15 Apr 2002 14:10:46 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA00280; Mon, 15 Apr 2002 13:24:27 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA00121 for ; Mon, 15 Apr 2002 13:24:13 -0400 (EDT) Received: from zctfs063.nortelnetworks.com (zctfs063.nortelnetworks.com [47.164.128.120]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA28747; Mon, 15 Apr 2002 13:24:10 -0400 (EDT) Received: from zwcwc012.europe.nortel.com (zwcwc012.europe.nortel.com [47.73.112.187]) by zctfs063.nortelnetworks.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id g3FHNUg15284; Mon, 15 Apr 2002 19:23:30 +0200 (MEST) Received: by zwcwc012.europe.nortel.com with Internet Mail Service (5.5.2653.19) id ; Mon, 15 Apr 2002 18:23:30 +0100 Message-ID: From: "Mark Watson" To: "'David R. Oran'" , "'Rosen, Brian'" , Mpierce1@aol.com, sip@ietf.org, "'sipping@ietf.org'" Subject: Network Asserted Identity (was: RE: Summary of RE: [Sip] Comment, SIP Privacy draft) Date: Mon, 15 Apr 2002 18:23:26 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C1E4A2.40D159C2" Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C1E4A2.40D159C2 Content-Type: text/plain OK, so lets see if we can conclude on _short-term_ Network Asserted identity requirements in a separate thread. Follow-ups to SIPPING ONLY please. First, assume a trust domain model as per privacy draft applicability statement. Entities within a domain trust each other, entities in different domains are mutually untrusted. I'll try to build up the requirements, least contraversial first: NAI1) The ability for network entities to insert a network asserted identity and pass to other network entities within the same trust domain. NAI2) The ability for a network entity to pass a (non-private) network asserted identity directly to a UA NAI3) Secure transport of network asserted identity across 'untrusted' networks back to the same trust domain (including between trust 'islands' - disconnected parts of a single trust domain) NAI4) Transport of network asserted identity between trust domains (i.e. transport in one domain of a network asserted identity received from another domain) For clarity, (a) the requirement for a user to choose one of a number of identities, whilst retaining privacy, is a 3GPP requirement, but is *out of scope* of this thread. (b) Call Trace implemented by encrypting the identity and passing this to the called user, who can then pass the encrypted identity to the generating service provider/authorities, is considered a sub-case of NAI3 - the identity is passed to the 'untrusted' user and back to the original Trust Domain (the Service Provider) before being passed to the authorities. I expect the From/To debate will continue, probably to the end of time, but I don't see a strong relationship with this issue. If people agree with my statement of the potential requirements, perhaps we could open discussion on which of these should be considered for immediate standardisation. The others can be put into the pot for discussion of the generic privacy requirements. For my part, I am most concerned about NAI1 and NAI2. Regards...Mark > -----Original Message----- > From: David R. Oran [mailto:oran@cisco.com] > Sent: 15 April 2002 17:39 > To: 'Rosen, Brian'; Mpierce1@aol.com; sip@ietf.org > Subject: RE: Summary of RE: [Sip] Comment, SIP Privacy draft > > > Brian Rosen wrote: > >If we could get consensus that trace-with-anonymity is the problem, > then > we can > > work on solutions. Until we get to something as straightforward as > > that, > > we are going to spin a lot of wheels. > > That's always been the prime motivator for me, plus the > secondary use of > NAI for call return to an anonymous caller. > > Dave > > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip > ------_=_NextPart_001_01C1E4A2.40D159C2 Content-Type: text/html Content-Transfer-Encoding: quoted-printable Network Asserted Identity (was: RE: Summary of RE: [Sip] = Comment, SIP Privacy draft)
OK, so lets see if we can conclude on _short-term_ = Network Asserted identity requirements in a separate thread. Follow-ups = to SIPPING ONLY please.

First, assume a trust domain model as per privacy = draft applicability statement. Entities within a domain trust each = other, entities in different domains are mutually untrusted.

I'll try to build up the requirements, least = contraversial first:
NAI1) The ability for network entities to insert a = network asserted identity and pass to other network entities within the = same trust domain.

NAI2) The ability for a network entity to pass a = (non-private) network asserted identity directly to a UA
NAI3) Secure transport of network asserted identity = across 'untrusted' networks back to the same trust domain (including = between trust 'islands' - disconnected parts of a single trust = domain)

NAI4) Transport of network asserted identity between = trust domains (i.e. transport in one domain of a network asserted = identity received from another domain)

For clarity,
(a) the requirement for a user to choose one of a = number of identities, whilst retaining privacy, is a 3GPP requirement, = but is *out of scope* of this thread.

(b) Call Trace implemented by encrypting the identity = and passing this to the called user, who can then pass the encrypted = identity to the generating service provider/authorities, is considered = a sub-case of NAI3 - the identity is passed to the 'untrusted' user and = back to the original Trust Domain (the Service Provider) before being = passed to the authorities.

I expect the From/To debate will continue, probably = to the end of time, but I don't see a strong relationship with this = issue.

If people agree with my statement of the potential = requirements, perhaps we could open discussion on which of these should = be considered for immediate standardisation. The others can be put into = the pot for discussion of the generic privacy requirements.

For my part, I am most concerned about NAI1 and = NAI2.

Regards...Mark

> -----Original Message-----
> From: David R. Oran [mailto:oran@cisco.com]
> Sent: 15 April 2002 17:39
> To: 'Rosen, Brian'; Mpierce1@aol.com; = sip@ietf.org
> Subject: RE: Summary of RE: [Sip] Comment, SIP = Privacy draft
>
>
> Brian Rosen wrote:
> >If we could get consensus that = trace-with-anonymity is the problem,
> then > we can
> > work on solutions. Until we get to = something as straightforward as
> > that,
> > we are going to spin a lot of = wheels.
>
> That's always been the prime motivator for me, = plus the
> secondary use of
> NAI for call return to an anonymous = caller.
>
> Dave
>
>
> = _______________________________________________
> Sip mailing list https://www1.ietf.org/mailman/listinfo/sip
> This list is for NEW development of the core = SIP Protocol
> Use sip-implementors@cs.columbia.edu for = questions on current sip
> Use sipping@ietf.org for new developments on = the application of sip
>
------_=_NextPart_001_01C1E4A2.40D159C2-- _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Mon Apr 15 14:16:04 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA00843 for ; Mon, 15 Apr 2002 14:16:04 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id OAA03580 for sip-archive@odin.ietf.org; Mon, 15 Apr 2002 14:16:06 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA01219; Mon, 15 Apr 2002 13:33:23 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA01188 for ; Mon, 15 Apr 2002 13:33:19 -0400 (EDT) Received: from zctfs063.nortelnetworks.com (zctfs063.nortelnetworks.com [47.164.128.120]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA29092 for ; Mon, 15 Apr 2002 13:33:03 -0400 (EDT) Received: from zwcwc012.europe.nortel.com (zwcwc012.europe.nortel.com [47.73.112.187]) by zctfs063.nortelnetworks.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id g3FHWEg15808; Mon, 15 Apr 2002 19:32:14 +0200 (MEST) Received: by zwcwc012.europe.nortel.com with Internet Mail Service (5.5.2653.19) id ; Mon, 15 Apr 2002 18:32:14 +0100 Message-ID: From: "Mark Watson" To: "'Ben Campbell'" , "Chiou, Mark" , Dean Willis , Mpierce1@aol.com, sip@ietf.org Subject: RE: Summary of RE: [Sip] Comment, SIP Privacy draft Date: Mon, 15 Apr 2002 18:32:13 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C1E4A3.1207B342" Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C1E4A3.1207B342 Content-Type: text/plain; charset="iso-8859-1" Ben, The user and the subscriber are not the same. See http://www1.ietf.org/mail-archive/working-groups/sip/current/msg04720.html for an explanation from earlier today. ...Mark ------_=_NextPart_001_01C1E4A3.1207B342 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Message
Ben,

The=20 user and the subscriber are not the same.

See=20 http://www1.ietf.org/mail-archive/working-groups/sip/current= /msg04720.html for=20 an explanation from earlier today.

...Mark
------_=_NextPart_001_01C1E4A3.1207B342-- _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Mon Apr 15 14:58:19 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA02896 for ; Mon, 15 Apr 2002 14:58:19 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id OAA05950 for sip-archive@odin.ietf.org; Mon, 15 Apr 2002 14:58:21 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA03846; Mon, 15 Apr 2002 14:23:54 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA03815 for ; Mon, 15 Apr 2002 14:23:51 -0400 (EDT) Received: from magus.nostrum.com (root@magus.nostrum.com [66.119.225.66]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA01150 for ; Mon, 15 Apr 2002 14:23:47 -0400 (EDT) Received: from txbcampbell (root@magus.nostrum.com [66.119.225.66]) by magus.nostrum.com (8.11.0/8.11.0) with SMTP id g3FINYX63993; Mon, 15 Apr 2002 13:23:34 -0500 (CDT) From: "Ben Campbell" To: "Mark Watson" , "Chiou, Mark" , "Dean Willis" , , Subject: RE: Summary of RE: [Sip] Comment, SIP Privacy draft Date: Mon, 15 Apr 2002 13:23:12 -0500 Message-ID: MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0077_01C1E480.B1749940" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Importance: Normal Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org This is a multi-part message in MIME format. ------=_NextPart_000_0077_01C1E480.B1749940 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit MessageOK, in that case I would expect the subscriber profile to have an optional entry indicating that only anonymous calls were allowed. If some user (the subscriber or otherwise) then tries to make a non-anonymous call, it gets rejected. It also makes sense that a well crafted UA that supported anonymous calling would have an option to always be anonymous, to avoid the usual cycle of try non-anonymous, fail, then try again with anonymous. I don't see why this is any different than any other rejection due to a policy violation. -----Original Message----- From: Mark Watson [mailto:mwatson@nortelnetworks.com] Sent: Monday, April 15, 2002 12:32 PM To: 'Ben Campbell'; Chiou, Mark; Dean Willis; Mpierce1@aol.com; sip@ietf.org Subject: RE: Summary of RE: [Sip] Comment, SIP Privacy draft Ben, The user and the subscriber are not the same. See http://www1.ietf.org/mail-archive/working-groups/sip/current/msg04720.html for an explanation from earlier today. ...Mark ------=_NextPart_000_0077_01C1E480.B1749940 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Message
OK, in=20 that case I would expect the subscriber profile to have an optional = entry=20 indicating that only anonymous calls were allowed. If some user (the = subscriber=20 or otherwise) then tries to make a non-anonymous call, it gets=20 rejected.

It=20 also makes sense that a well crafted UA that supported anonymous calling = would=20 have an option to always be anonymous, to avoid the usual cycle of try=20 non-anonymous, fail, then try again with anonymous.

I=20 don't see why this is any different than any other rejection due to a = policy=20 violation.

-----Original Message-----
From: Mark Watson=20 [mailto:mwatson@nortelnetworks.com]
Sent: Monday, April 15, = 2002=20 12:32 PM
To: 'Ben Campbell'; Chiou, Mark; Dean Willis;=20 Mpierce1@aol.com; sip@ietf.org
Subject: RE: Summary of RE: = [Sip]=20 Comment, SIP Privacy draft

Ben,

The user and the subscriber are not the=20 same.

See http://www1.ietf.org/mail-archive/working-groups/sip/current/m= sg04720.html for=20 an explanation from earlier today.

...Mark
------=_NextPart_000_0077_01C1E480.B1749940-- _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Mon Apr 15 15:10:19 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA03419 for ; Mon, 15 Apr 2002 15:10:19 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id PAA06996 for sip-archive@odin.ietf.org; Mon, 15 Apr 2002 15:10:22 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA05390; Mon, 15 Apr 2002 14:46:29 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA05359 for ; Mon, 15 Apr 2002 14:46:25 -0400 (EDT) Received: from zctfs063.nortelnetworks.com (zctfs063.nortelnetworks.com [47.164.128.120]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA02518 for ; Mon, 15 Apr 2002 14:46:22 -0400 (EDT) Received: from znsgs01r.europe.nortel.com (znsgs01r.europe.nortel.com [47.137.129.92]) by zctfs063.nortelnetworks.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id g3FIjqg21915; Mon, 15 Apr 2002 20:45:52 +0200 (MEST) Received: from zwcwc012.europe.nortel.com (zwcwc012.europe.nortel.com [47.73.112.187]) by znsgs01r.europe.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id g3FIjCE11665; Mon, 15 Apr 2002 19:45:12 +0100 (BST) Received: by zwcwc012.europe.nortel.com with Internet Mail Service (5.5.2653.19) id ; Mon, 15 Apr 2002 19:45:50 +0100 Message-ID: From: "Mark Watson" To: "'Ben Campbell'" , "Chiou, Mark" , Dean Willis , Mpierce1@aol.com, sip@ietf.org Subject: RE: Summary of RE: [Sip] Comment, SIP Privacy draft Date: Mon, 15 Apr 2002 19:45:49 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C1E4AD.C2DA12D2" Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C1E4AD.C2DA12D2 Content-Type: text/plain; charset="iso-8859-1" Three problems: 1) In practice you might expect the 'policy' to be more flexible than just 'everything anonymous' (e.g. internal calls non-anonymous, external calls anonymous), although the blanket anonymity would be the most that Service Providers could be required to provide. Anyway, we do not want the only solution to this requirement to be to configure the UA as always anonymous. The users wish is that they be identified if possible. The 'policy' solution means that the only way of finding out if a particular call must be anonymous is to try and see, and then retry if it fails. 2) Even with a well-crafted UA, why is the _user_ expected to re-configure their client because of the _subscriber's_ wishes. And when the policy changes, how will we indicate to all the users that they should now re-configure their clients again ? I hope all the Service Providers wanting to launch SIP services have got their list of client requirements worked out. If your subscriber asks for this anonymity service they will not be impressed if they have to upgrade/re-configure all their clients. If you didn't inform them in advance that the clients needed these capabilities, then they could refuse to upgrade and still demand the anonymity service. 3) What about a user who has asked their home proxy to forward calls, and who wishes to remain anonymous - is the inclusion of this persons identity in the To field just a policy violation ? How many UAs have an option to set the To field blank ? This would be more of a 'call rejection' service than a 'call forwarding' service. I think that if in trying to get a Data Protected version of a service, the user finds that they can't have the service at all, they would be entitled to be a bit miffed. ...Mark -----Original Message----- From: Ben Campbell [mailto:bcampbell@dynamicsoft.com] Sent: 15 April 2002 19:23 To: Watson, Mark [MDN05:EP10:EXCH]; Chiou, Mark; Dean Willis; Mpierce1@aol.com; sip@ietf.org Subject: RE: Summary of RE: [Sip] Comment, SIP Privacy draft OK, in that case I would expect the subscriber profile to have an optional entry indicating that only anonymous calls were allowed. If some user (the subscriber or otherwise) then tries to make a non-anonymous call, it gets rejected. It also makes sense that a well crafted UA that supported anonymous calling would have an option to always be anonymous, to avoid the usual cycle of try non-anonymous, fail, then try again with anonymous. I don't see why this is any different than any other rejection due to a policy violation. -----Original Message----- From: Mark Watson [mailto:mwatson@nortelnetworks.com] Sent: Monday, April 15, 2002 12:32 PM To: 'Ben Campbell'; Chiou, Mark; Dean Willis; Mpierce1@aol.com; sip@ietf.org Subject: RE: Summary of RE: [Sip] Comment, SIP Privacy draft Ben, The user and the subscriber are not the same. See http://www1.ietf.org/mail-archive/working-groups/sip/current/msg04720.html for an explanation from earlier today. ...Mark ------_=_NextPart_001_01C1E4AD.C2DA12D2 Content-Type: text/html; charset="iso-8859-1" Message
Three problems:

1) In practice you might expect the 'policy' to be more flexible than just 'everything anonymous' (e.g. internal calls non-anonymous, external calls anonymous), although the blanket anonymity would be the most that Service Providers could be required to provide. Anyway, we do not want the only solution to this requirement to be to configure the UA as always anonymous.

The users wish is that they be identified if possible. The 'policy' solution means that the only way of finding out if a particular call must be anonymous is to try and see, and then retry if it fails.

2) Even with a well-crafted UA, why is the _user_ expected to re-configure their client because of the _subscriber's_ wishes. And when the policy changes, how will we indicate to all the users that they should now re-configure their clients again ?

I hope all the Service Providers wanting to launch SIP services have got their list of client requirements worked out. If your subscriber asks for this anonymity service they will not be impressed if they have to upgrade/re-configure all their clients. If you didn't inform them in advance that the clients needed these capabilities, then they could refuse to upgrade and still demand the anonymity service.

3) What about a user who has asked their home proxy to forward calls, and who wishes to remain anonymous - is the inclusion of this persons identity in the To field just a policy violation ? How many UAs have an option to set the To field blank ? This would be more of a 'call rejection' service than a 'call forwarding' service. I think that if in trying to get a Data Protected version of a service, the user finds that they can't have the service at all, they would be entitled to be a bit miffed.

...Mark

-----Original Message-----
From: Ben Campbell [mailto:bcampbell@dynamicsoft.com]
Sent: 15 April 2002 19:23
To: Watson, Mark [MDN05:EP10:EXCH]; Chiou, Mark; Dean Willis; Mpierce1@aol.com; sip@ietf.org
Subject: RE: Summary of RE: [Sip] Comment, SIP Privacy draft

OK, in that case I would expect the subscriber profile to have an optional entry indicating that only anonymous calls were allowed. If some user (the subscriber or otherwise) then tries to make a non-anonymous call, it gets rejected.

It also makes sense that a well crafted UA that supported anonymous calling would have an option to always be anonymous, to avoid the usual cycle of try non-anonymous, fail, then try again with anonymous.

I don't see why this is any different than any other rejection due to a policy violation.

-----Original Message-----
From: Mark Watson [mailto:mwatson@nortelnetworks.com]
Sent: Monday, April 15, 2002 12:32 PM
To: 'Ben Campbell'; Chiou, Mark; Dean Willis; Mpierce1@aol.com; sip@ietf.org
Subject: RE: Summary of RE: [Sip] Comment, SIP Privacy draft

Ben,

The user and the subscriber are not the same.

See http://www1.ietf.org/mail-archive/working-groups/sip/current/msg04720.html for an explanation from earlier today.

...Mark
------_=_NextPart_001_01C1E4AD.C2DA12D2-- _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Mon Apr 15 15:26:00 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA03806 for ; Mon, 15 Apr 2002 15:25:59 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id PAA07701 for sip-archive@odin.ietf.org; Mon, 15 Apr 2002 15:26:02 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA06959; Mon, 15 Apr 2002 15:08:55 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA06929 for ; Mon, 15 Apr 2002 15:08:51 -0400 (EDT) Received: from magus.nostrum.com (root@magus.nostrum.com [66.119.225.66]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA03357 for ; Mon, 15 Apr 2002 15:08:47 -0400 (EDT) Received: from txbcampbell (root@magus.nostrum.com [66.119.225.66]) by magus.nostrum.com (8.11.0/8.11.0) with SMTP id g3FJ8PX67361; Mon, 15 Apr 2002 14:08:25 -0500 (CDT) From: "Ben Campbell" To: "Mark Watson" , "Chiou, Mark" , "Dean Willis" , , Subject: RE: Summary of RE: [Sip] Comment, SIP Privacy draft Date: Mon, 15 Apr 2002 14:08:03 -0500 Message-ID: MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_008D_01C1E486.F565E1D0" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Importance: Normal Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org This is a multi-part message in MIME format. ------=_NextPart_000_008D_01C1E486.F565E1D0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message -----Original Message----- From: sip-admin@ietf.org [mailto:sip-admin@ietf.org]On Behalf Of Mark Watson Sent: Monday, April 15, 2002 1:46 PM To: 'Ben Campbell'; Chiou, Mark; Dean Willis; Mpierce1@aol.com; sip@ietf.org Subject: RE: Summary of RE: [Sip] Comment, SIP Privacy draft Three problems: 1) In practice you might expect the 'policy' to be more flexible than just 'everything anonymous' (e.g. internal calls non-anonymous, external calls anonymous), although the blanket anonymity would be the most that Service Providers could be required to provide. Anyway, we do not want the only solution to this requirement to be to configure the UA as always anonymous. Certainly not. I only meant this for the situation where the subscriber has asserted that all calls from his account are to be anonymous, and an individual user of that account might not know about that policy choice. The users wish is that they be identified if possible. The 'policy' solution means that the only way of finding out if a particular call must be anonymous is to try and see, and then retry if it fails. Which then allows the user to decide whether or not to continue according to policy, or just not make the call. Otherwise, the network seems to be in the business of deciding that the user really does not mind if the call is anonymous. That seems fairly benign in this particular case, but not generically (what if the policy was _no_ anonymous calls.) 2) Even with a well-crafted UA, why is the _user_ expected to re-configure their client because of the _subscriber's_ wishes. And when the policy changes, how will we indicate to all the users that they should now re-configure their clients again ? They don't have to. Doing so just cuts down on the reject-due-to-policy-violation-oops-retry cycles. Now, I assume the user must have some relationship with the subscriber (else how does he have credentials), and the subscriber _could_ just tell the user. Not everything has to be automatic. I hope all the Service Providers wanting to launch SIP services have got their list of client requirements worked out. If your subscriber asks for this anonymity service they will not be impressed if they have to upgrade/re-configure all their clients. If you didn't inform them in advance that the clients needed these capabilities, then they could refuse to upgrade and still demand the anonymity service. Well, once the idea of an anonymity service is fully formed (presumably what we are doing here) it makes sense that it is a feature that a client can support or not support. (Maybe even a supported or requires tag?) Then it is reasonable for a service provider to say you can make anonymous calls if your client supports anonymity. If a subscriber has a policy of _only_ anonymous calls, and a user has a client that cannot make anonymous calls, then he is SOL. I don't see why this is any different than any _other_ situation where an optional client feature might be required by SP or subscriber policy. Again, the alternative is a presumption on the networks part that it knows what the user _really_ means to do better than the user does. Such an presumption on policy violations scares me in the generic sense. 3) What about a user who has asked their home proxy to forward calls, and who wishes to remain anonymous - is the inclusion of this persons identity in the To field just a policy violation ? How many UAs have an option to set the To field blank ? This would be more of a 'call rejection' service than a 'call forwarding' service. I think that if in trying to get a Data Protected version of a service, the user finds that they can't have the service at all, they would be entitled to be a bit miffed. ...Mark -----Original Message----- From: Ben Campbell [mailto:bcampbell@dynamicsoft.com] Sent: 15 April 2002 19:23 To: Watson, Mark [MDN05:EP10:EXCH]; Chiou, Mark; Dean Willis; Mpierce1@aol.com; sip@ietf.org Subject: RE: Summary of RE: [Sip] Comment, SIP Privacy draft OK, in that case I would expect the subscriber profile to have an optional entry indicating that only anonymous calls were allowed. If some user (the subscriber or otherwise) then tries to make a non-anonymous call, it gets rejected. It also makes sense that a well crafted UA that supported anonymous calling would have an option to always be anonymous, to avoid the usual cycle of try non-anonymous, fail, then try again with anonymous. I don't see why this is any different than any other rejection due to a policy violation. -----Original Message----- From: Mark Watson [mailto:mwatson@nortelnetworks.com] Sent: Monday, April 15, 2002 12:32 PM To: 'Ben Campbell'; Chiou, Mark; Dean Willis; Mpierce1@aol.com; sip@ietf.org Subject: RE: Summary of RE: [Sip] Comment, SIP Privacy draft Ben, The user and the subscriber are not the same. See http://www1.ietf.org/mail-archive/working-groups/sip/current/msg04720.html for an explanation from earlier today. ...Mark ------=_NextPart_000_008D_01C1E486.F565E1D0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Message

-----Original Message-----
From: sip-admin@ietf.org = [mailto:sip-admin@ietf.org]On Behalf Of Mark = Watson
Sent:=20 Monday, April 15, 2002 1:46 PM
To: 'Ben Campbell'; Chiou, = Mark; Dean=20 Willis; Mpierce1@aol.com; sip@ietf.org
Subject: RE: Summary = of RE:=20 [Sip] Comment, SIP Privacy draft

Three problems:

1) In practice you might expect the 'policy' to be = more flexible=20 than just 'everything anonymous' (e.g. internal calls non-anonymous, = external=20 calls anonymous), although the blanket anonymity would be the most = that=20 Service Providers could be required to provide. Anyway, we do not want = the=20 only solution to this requirement to be to configure the UA as always=20 anonymous.

Certainly=20 not. I only meant this for the situation where the subscriber has = asserted=20 that all calls from his account are to be anonymous, and an = individual=20 user of that account might not know about that policy=20 choice.

The users wish is that they be identified if possible. = The=20 'policy' solution means that the only way of finding out if a = particular call=20 must be anonymous is to try and see, and then retry if it fails.

Which=20 then allows the user to decide whether or not to continue = according to=20 policy, or just not make the call. Otherwise, the network seems to=20 be in the business of deciding that the user really does=20 not mind if the call is anonymous. That seems fairly benign in = this=20 particular case, but not generically (what if the policy was _no_ = anonymous=20 calls.)

2) Even with a well-crafted UA, why is the _user_ = expected to=20 re-configure their client because of the _subscriber's_ wishes. And = when the=20 policy changes, how will we indicate to all the users that they should = now=20 re-configure their clients again ?

They=20 don't have to. Doing so just cuts down on the=20 reject-due-to-policy-violation-oops-retry cycles. Now, I assume the = user must=20 have some relationship with the subscriber (else how does he have = credentials), and the subscriber _could_ just tell the user. Not=20 everything has to be = automatic.

I hope all the Service Providers wanting to launch SIP = services=20 have got their list of client requirements worked out. If your = subscriber asks=20 for this anonymity service they will not be impressed if they have to=20 upgrade/re-configure all their clients. If you didn't inform them in = advance=20 that the clients needed these capabilities, then they could refuse to = upgrade=20 and still demand the anonymity service.

Well,=20 once the idea of an anonymity service is fully formed (presumably what = we are=20 doing here) it makes sense that it is a feature that a client can = support=20 or not support. (Maybe even a supported or requires tag?) Then it = is=20 reasonable for a service provider to say you can make anonymous = calls if=20 your client supports anonymity. If a subscriber has a policy of = _only_=20 anonymous calls, and a user has a client that cannot make = anonymous=20 calls, then he is SOL. I = don't see=20 why this is any different than any _other_ situation where an optional = client=20 feature might be required by SP or subscriber policy. Again, the = alternative=20 is a presumption on the networks part that it knows what the user = _really_=20 means to do better than the user does. Such an presumption on policy=20 violations scares me in the generic sense.=20

3)=20 What about a user who has asked their home proxy to forward calls, and = who=20 wishes to remain anonymous - is the inclusion of this persons identity = in the=20 To field just a policy violation ? How many UAs have an option to set = the To=20 field blank ? This would be more of a 'call rejection' service than a = 'call=20 forwarding' service. I think that if in trying to get a Data Protected = version=20 of a service, the user finds that they can't have the service at all, = they=20 would be entitled to be a bit miffed.

...Mark

-----Original Message-----
From: Ben Campbell=20 [mailto:bcampbell@dynamicsoft.com]
Sent: 15 April 2002=20 19:23
To: Watson, Mark [MDN05:EP10:EXCH]; Chiou, Mark; = Dean=20 Willis; Mpierce1@aol.com; sip@ietf.org
Subject: RE: = Summary of RE:=20 [Sip] Comment, SIP Privacy draft

OK, in that case I would expect the subscriber profile to = have an=20 optional entry indicating that only anonymous calls were allowed. If = some=20 user (the subscriber or otherwise) then tries to make a = non-anonymous call,=20 it gets rejected.

It=20 also makes sense that a well crafted UA that supported anonymous = calling=20 would have an option to always be anonymous, to avoid the usual = cycle of try=20 non-anonymous, fail, then try again with = anonymous.

I=20 don't see why this is any different than any other rejection due to = a policy=20 violation.

-----Original Message-----
From: Mark Watson=20 [mailto:mwatson@nortelnetworks.com]
Sent: Monday, April = 15, 2002=20 12:32 PM
To: 'Ben Campbell'; Chiou, Mark; Dean Willis;=20 Mpierce1@aol.com; sip@ietf.org
Subject: RE: Summary of = RE: [Sip]=20 Comment, SIP Privacy draft

Ben,

The user and the subscriber are not the = same.

See http://www1.ietf.org/mail-archive/working-groups/sip/current/m= sg04720.html for=20 an explanation from earlier today.

...Mark
------=_NextPart_000_008D_01C1E486.F565E1D0-- _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Mon Apr 15 15:28:16 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA03872 for ; Mon, 15 Apr 2002 15:28:16 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id PAA07779 for sip-archive@odin.ietf.org; Mon, 15 Apr 2002 15:28:18 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA07071; Mon, 15 Apr 2002 15:10:59 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA07042 for ; Mon, 15 Apr 2002 15:10:56 -0400 (EDT) Received: from excalibur.santera.com (exchange.santera.com [4.22.157.11]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA03440 for ; Mon, 15 Apr 2002 15:10:52 -0400 (EDT) X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C1E4B1.306FAEB2" Subject: RE: Summary of RE: [Sip] Comment, SIP Privacy draft Date: Mon, 15 Apr 2002 14:10:21 -0500 Message-ID: Thread-Topic: Summary of RE: [Sip] Comment, SIP Privacy draft Thread-Index: AcHkrd7uMpKggbQQQDmqZat7KoNtkAAAoLCw From: "Chiou, Mark" To: "Mark Watson" , "Ben Campbell" , "Dean Willis" , , Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org This is a multi-part message in MIME format. ------_=_NextPart_001_01C1E4B1.306FAEB2 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Mark Watson wrote: ###################### 3) What about a user who has asked their home proxy to forward calls, = and who wishes to remain anonymous - is the inclusion of this persons = identity in the To field just a policy violation ? How many UAs have an = option to set the To field blank ? This would be more of a 'call = rejection' service than a 'call forwarding' service. I think that if in = trying to get a Data Protected version of a service, the user finds that = they can't have the service at all, they would be entitled to be a bit = miffed. #################### =20 Can we insert the privacy information into the Contact header when 3xx = response is generated for forwarding (redirecting) calls? Just a = thought. =20 =20 Mark Chiou =20 ------_=_NextPart_001_01C1E4B1.306FAEB2 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Message
Mark=20 Watson wrote:

######################

3)=20 What about a user who has asked their home proxy to forward calls, and = who=20 wishes to remain anonymous - is the inclusion of this persons identity = in the To=20 field just a policy violation ? How many UAs have an option to set the = To field=20 blank ? This would be more of a 'call rejection' service than a 'call=20 forwarding' service. I think that if in trying to get a Data Protected = version=20 of a service, the user finds that they can't have the service at all, = they would=20 be entitled to be a bit miffed.

####################
Can we=20 insert the privacy information into the Contact header when 3xx response = is=20 generated for forwarding (redirecting) calls? Just a = thought. =20

Mark=20 Chiou

------_=_NextPart_001_01C1E4B1.306FAEB2-- _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Mon Apr 15 17:08:15 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA06773 for ; Mon, 15 Apr 2002 17:08:15 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id RAA15001 for sip-archive@odin.ietf.org; Mon, 15 Apr 2002 17:08:19 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA12384; Mon, 15 Apr 2002 16:32:59 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA12352 for ; Mon, 15 Apr 2002 16:32:55 -0400 (EDT) Received: from bdsl.66.12.12.130.gte.net (bdsl.66.12.12.130.gte.net [66.12.12.130]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA06046 for ; Mon, 15 Apr 2002 16:32:50 -0400 (EDT) Received: from TXDWILLIS2 (bdsl.greycouncil.com [127.0.0.1]) by bdsl.66.12.12.130.gte.net (8.11.6/8.11.6) with ESMTP id g3FKUhd17319; Mon, 15 Apr 2002 15:30:43 -0500 From: "Dean Willis" To: "'Chiou, Mark'" , , Subject: RE: Summary of RE: [Sip] Comment, SIP Privacy draft Date: Mon, 15 Apr 2002 15:30:41 -0500 Message-ID: <009401c1e4bc$699dd320$1c036e3f@TXDWILLIS2> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.3416 Importance: Normal In-reply-to: X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit Dean wrote: ---- The calling-party-identity presentation infromation (CLIP or RPID) is NOT inserted by the user. It is inserted by the network, WITHOUT THE CONSENT of the user. As such, the operator is responsible for the protection of that information in a manner consistent with regulation and the expressed wishes of the user. ---- Mark wrote: ---- No, The CLIP is inserted by the network WITH THE CONSENT of the user. When you subscribe a line from a PSTN service provider, the form you filled indicating whether you want your telephone number to be PUBLIC or PRIVATE. (of course, the default is PUBLIC if you leave it blank.) When you make a call, the PRIVATE or PUBLIC status value is retrieved and set the Address Presentation Restricted Indicator (APRI) field in SS7 environment (Note that, CLIR toggles the values), then the terminating side of the network based on the APRI value to determine whether the Calling Party Number shall be delivered to the callee's CPE. ---- Coercion <=> consent. There is no explicit consent within the signaling of an invidiual transaction. External contractual issues are outside of the protocol, and tend to violate the "openness" characteristic of an Internet protocol. In otherwises, there's a philosophical difference between an explicit request from the user that a network providing break privacy for that transaction, and a network that breaks privacy just because I didn't tell it NOT to. Note of course, that we're not talking about PSTN provoders, we're talking IP to IP usage over the publicaly addressable Internet. Mark also wrote: ---- Since we want to push the decision making to the UA, we should standardize the rule such that the UA shall display the From information based on Privacy indication. If we think that too many UAs won't follow this rule, than we should allow the Service Provider of terminating side (not the originating side) to alter the From information before terminating the call to the UA based on the Privacy indication. ---- Personally, the UA I uset he most writes every last SIP header and the body to the screen, and copies them all to a log file just in case. One cannot rely on the called party's software to protect the privacy of the calling party. -- Dean _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@ns.ietf.org Mon Apr 15 18:30:52 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA08316 for ; Mon, 15 Apr 2002 18:30:52 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id SAA19288 for sip-archive@odin.ietf.org; Mon, 15 Apr 2002 18:30:57 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA16802; Mon, 15 Apr 2002 17:51:25 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA16761 for ; Mon, 15 Apr 2002 17:51:19 -0400 (EDT) Received: from excalibur.santera.com (exchange.santera.com [4.22.157.11]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA07504 for ; Mon, 15 Apr 2002 17:51:14 -0400 (EDT) X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: Summary of RE: [Sip] Comment, SIP Privacy draft Date: Mon, 15 Apr 2002 16:50:45 -0500 Message-ID: Thread-Topic: Summary of RE: [Sip] Comment, SIP Privacy draft Thread-Index: AcHkvqMF3E5nIe7RSf+2lcW0WI18MgABXJBw From: "Chiou, Mark" To: "Dean Willis" , , Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id RAA16762 Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 8bit Coercion <=> consent. There is no explicit consent within the signaling of an invidiual transaction. External contractual issues are outside of the protocol, and tend to violate the "openness" characteristic of an Internet protocol. In otherwises, there's a philosophical difference between an explicit request from the user that a network providing break privacy for that transaction, and a network that breaks privacy just because I didn't tell it NOT to. Note of course, that we're not talking about PSTN provoders, we're talking IP to IP usage over the publicaly addressable Internet. So, for IP, all the UAs are defaulted to PRIVATE. When a user wishes to make an anonymous calls, SIP needs an indication for the network (i.e. Service Provider) to identify who is calling and translate or retrieve the identity of the calling from the service agreement, then pass the calling identity within the networks without sending the calling identity to the UA of the called party. Personally, the UA I uset he most writes every last SIP header and the body to the screen, and copies them all to a log file just in case. One cannot rely on the called party's software to protect the privacy of the calling party. Agree. So we have to separate the needs for Privacy and the needs for Network, such that the privacy is fully controlled by the UA. On the other hand, the Service Providers have the responsibility to obtain the UA's identify for network usage (i.e. Emergency, Law Enforcement, Call trace, and etc) without breaking the UA's privacy. I means the UA's identity, which is needed by the Network, shall not be delivered to the terminating of the UA. Mark Chiou _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@ns.ietf.org Tue Apr 16 02:11:02 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA23205 for ; Tue, 16 Apr 2002 02:11:02 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id CAA20857 for sip-archive@odin.ietf.org; Tue, 16 Apr 2002 02:11:04 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id BAA18023; Tue, 16 Apr 2002 01:26:52 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id BAA17992 for ; Tue, 16 Apr 2002 01:26:48 -0400 (EDT) Received: from lohi.eng.song.fi (lohi.eng.song.fi [195.10.149.18]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA15935 for ; Tue, 16 Apr 2002 01:26:44 -0400 (EDT) From: jh@lohi.eng.song.fi Received: from harjus.eng.song.fi ([195.10.149.20]) by lohi.eng.song.fi with esmtp (Exim 3.34 #1 (Debian)) id 16xLUJ-00046r-00; Tue, 16 Apr 2002 08:26:43 +0300 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15547.46611.373594.803557@harjus.eng.song.fi> Date: Tue, 16 Apr 2002 08:26:43 +0300 To: "Dean Willis" Cc: "'Chiou, Mark'" , , Subject: RE: Summary of RE: [Sip] Comment, SIP Privacy draft In-Reply-To: <009401c1e4bc$699dd320$1c036e3f@TXDWILLIS2> References: <009401c1e4bc$699dd320$1c036e3f@TXDWILLIS2> X-Mailer: VM 7.01 under Emacs 21.1.1 Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit Dean Willis writes: > No, The CLIP is inserted by the network WITH THE CONSENT of the user. > When you subscribe a line from a PSTN service provider, the form you > filled indicating whether you want your telephone number to be PUBLIC or > PRIVATE. (of course, the default is PUBLIC if you leave it blank.) When > you make a call, the PRIVATE or PUBLIC status value is retrieved and set > the Address Presentation Restricted Indicator (APRI) field in SS7 > environment (Note that, CLIR toggles the values), then the terminating > side of the network based on the APRI value to determine whether the > Calling Party Number shall be delivered to the callee's CPE. i don't understand why we would need anything new for this kind of privacy purpose. we already have the Anonymous display string. if th user wants from privacy, it uses Anonymous display string from which the sip/ss7 gw knows what to do. the same to the other direction. if the call goes to a sip user, then the network MUST rewrite the from uri and thus implement a b2bua. -- juha _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@ns.ietf.org Tue Apr 16 02:11:46 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA23710 for ; Tue, 16 Apr 2002 02:11:46 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id CAA20908 for sip-archive@odin.ietf.org; Tue, 16 Apr 2002 02:11:49 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id BAA19123; Tue, 16 Apr 2002 01:45:46 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id BAA19088 for ; Tue, 16 Apr 2002 01:45:42 -0400 (EDT) Received: from hindon.hss.co.in ([202.54.26.202]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA16074 for ; Tue, 16 Apr 2002 01:45:37 -0400 (EDT) From: bpaul@hss.hns.com Received: from sandesh.hss.hns.com (sandesh [139.85.242.35]) by hindon.hss.co.in (8.10.0/8.10.0) with SMTP id g3G5jni09866; Tue, 16 Apr 2002 11:15:50 +0530 (IST) Received: by sandesh.hss.hns.com(Lotus SMTP MTA v4.6.3 (733.2 10-16-1998)) id 65256B9D.001F573C ; Tue, 16 Apr 2002 11:12:19 +0530 X-Lotus-FromDomain: HSS To: sip-implementors@cs.columbia.edu cc: sip@ietf.org Message-ID: <65256B9D.001F5664.00@sandesh.hss.hns.com> Date: Tue, 16 Apr 2002 11:14:09 +0530 Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline Subject: [Sip] Query regarding CIN Delivery Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org According to draft-ietf-sip-isup-03.txt " The construction of the From field is dependent on the presence of a CIN parameter. If the CIN is not present, then the gateway should create a dummy From header containing a SIP URI without a user portion which communicates only the hostname of the gateway (e.g. 'sip:gw.level3.net')." This works fine in case of a GW-GW scenario as the originating GW will send only the IP Address in the From field and the terminating GW will remove the IP Address before sending the CIN to the SCN network. But in case the call lands on a SIP terminal from Gateway then From field will not reflect the calling party who is the subscriber of GW, rather the SIP terminal might just display the IP Address of the GW as the calling party number on the user's screen. So Wouldn't it be better to add sip:Anonymous ? This way the SIP User will display the display name as Anonymous. But ofcourse, a limitation of this will be in the GW-GW scenario, the terminating GW might map it to CIN presentation restricted while sending it to the SCN n/w. Any suggestions?? Regards, Bishista Paul "DISCLAIMER: This message is proprietary to Hughes Software Systems Limited (HSS) and is intended solely for the use of the individual to whom it is addressed. It may contain privileged or confidential information and should not be circulated or used for any purpose other than for what it is intended. If you have received this message in error, please notify the originator immediately. If you are not the intended recipient, you are notified that you are strictly prohibited from using, copying, altering, or disclosing the contents of this message. HSS accepts no responsibility for loss or damage arising from the use of the information transmitted by this email including damage from virus." _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Tue Apr 16 05:53:03 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA28048 for ; Tue, 16 Apr 2002 05:53:03 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id FAA01688 for sip-archive@odin.ietf.org; Tue, 16 Apr 2002 05:53:06 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id FAA00152; Tue, 16 Apr 2002 05:18:20 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id FAA00121 for ; Tue, 16 Apr 2002 05:18:16 -0400 (EDT) Received: from zctfs063.nortelnetworks.com (zctfs063.nortelnetworks.com [47.164.128.120]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA26932 for ; Tue, 16 Apr 2002 05:18:12 -0400 (EDT) Received: from zwcwc012.europe.nortel.com (zwcwc012.europe.nortel.com [47.73.112.187]) by zctfs063.nortelnetworks.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id g3G9HLL06044; Tue, 16 Apr 2002 11:17:21 +0200 (MEST) Received: by zwcwc012.europe.nortel.com with Internet Mail Service (5.5.2653.19) id ; Tue, 16 Apr 2002 10:17:22 +0100 Message-ID: From: "Mark Watson" To: "'Chiou, Mark'" , Ben Campbell , Dean Willis , Mpierce1@aol.com, sip@ietf.org Subject: RE: Summary of RE: [Sip] Comment, SIP Privacy draft Date: Tue, 16 Apr 2002 10:17:16 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C1E527.624757D4" Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C1E527.624757D4 Content-Type: text/plain; charset="iso-8859-1" Why would you trust the UA to obey this ? How could you police this if the calling UA is getting service through a difefrent service provider from the forwarding party ? ...Mark -----Original Message----- From: Chiou, Mark [mailto:MChiou@Santera.com] Sent: 15 April 2002 20:10 To: Watson, Mark [MDN05:EP10:EXCH]; Ben Campbell; Dean Willis; Mpierce1@aol.com; sip@ietf.org Subject: RE: Summary of RE: [Sip] Comment, SIP Privacy draft Mark Watson wrote: ###################### 3) What about a user who has asked their home proxy to forward calls, and who wishes to remain anonymous - is the inclusion of this persons identity in the To field just a policy violation ? How many UAs have an option to set the To field blank ? This would be more of a 'call rejection' service than a 'call forwarding' service. I think that if in trying to get a Data Protected version of a service, the user finds that they can't have the service at all, they would be entitled to be a bit miffed. #################### Can we insert the privacy information into the Contact header when 3xx response is generated for forwarding (redirecting) calls? Just a thought. Mark Chiou ------_=_NextPart_001_01C1E527.624757D4 Content-Type: text/html; charset="iso-8859-1" Message
Why would you trust the UA to obey this ? How could you police this if the calling UA is getting service through a difefrent service provider from the forwarding party ?

...Mark

-----Original Message-----
From: Chiou, Mark [mailto:MChiou@Santera.com]
Sent: 15 April 2002 20:10
To: Watson, Mark [MDN05:EP10:EXCH]; Ben Campbell; Dean Willis; Mpierce1@aol.com; sip@ietf.org
Subject: RE: Summary of RE: [Sip] Comment, SIP Privacy draft

Mark Watson wrote:

######################

3) What about a user who has asked their home proxy to forward calls, and who wishes to remain anonymous - is the inclusion of this persons identity in the To field just a policy violation ? How many UAs have an option to set the To field blank ? This would be more of a 'call rejection' service than a 'call forwarding' service. I think that if in trying to get a Data Protected version of a service, the user finds that they can't have the service at all, they would be entitled to be a bit miffed.

####################
Can we insert the privacy information into the Contact header when 3xx response is generated for forwarding (redirecting) calls? Just a thought.

Mark Chiou

------_=_NextPart_001_01C1E527.624757D4-- _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Tue Apr 16 05:58:29 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA28112 for ; Tue, 16 Apr 2002 05:58:29 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id FAA01793 for sip-archive@odin.ietf.org; Tue, 16 Apr 2002 05:58:32 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id FAA00358; Tue, 16 Apr 2002 05:21:37 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id FAA00236 for ; Tue, 16 Apr 2002 05:21:26 -0400 (EDT) Received: from zctfs063.nortelnetworks.com (zctfs063.nortelnetworks.com [47.164.128.120]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA27239 for ; Tue, 16 Apr 2002 05:21:17 -0400 (EDT) Received: from zwcwc012.europe.nortel.com (zwcwc012.europe.nortel.com [47.73.112.187]) by zctfs063.nortelnetworks.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id g3G9KUL06777; Tue, 16 Apr 2002 11:20:30 +0200 (MEST) Received: by zwcwc012.europe.nortel.com with Internet Mail Service (5.5.2653.19) id ; Tue, 16 Apr 2002 10:20:33 +0100 Message-ID: From: "Mark Watson" To: "'Ben Campbell'" , "Chiou, Mark" , Dean Willis , Mpierce1@aol.com, sip@ietf.org Subject: RE: Summary of RE: [Sip] Comment, SIP Privacy draft Date: Tue, 16 Apr 2002 10:20:32 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C1E527.F56D7A84" Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C1E527.F56D7A84 Content-Type: text/plain; charset="iso-8859-1" Ben wrote: Which then allows the user to decide whether or not to continue according to policy, or just not make the call. Otherwise, the network seems to be in the business of deciding that the user really does not mind if the call is anonymous. That seems fairly benign in this particular case, but not generically (what if the policy was _no_ anonymous calls.) A 'no anonymous calls' policy would be in breach of the users right to make anonymous calls. It is not the network that is deciding that the user does not mind if the call is anonymous, it is the subscriber, and they have a legal right to do this. The subscribe must be able to control what information the network reveals about them. The user does not have the right to ask the network to reveal information that the subscriber does not want revealed - although the use can of course reveal the information themselves. 2) Even with a well-crafted UA, why is the _user_ expected to re-configure their client because of the _subscriber's_ wishes. And when the policy changes, how will we indicate to all the users that they should now re-configure their clients again ? They don't have to. Doing so just cuts down on the reject-due-to-policy-violation-oops-retry cycles. Now, I assume the user must have some relationship with the subscriber (else how does he have credentials), and the subscriber _could_ just tell the user. Not everything has to be automatic. Frequent reject-due-to- policy-violation-oops-retry cycles are just unaceptable for wireless environments. There must be a 'works first time' solution. If you think the user needs to be informed that their call has become anonymous, then fine, let's standardise this indication. I hope all the Service Providers wanting to launch SIP services have got their list of client requirements worked out. If your subscriber asks for this anonymity service they will not be impressed if they have to upgrade/re-configure all their clients. If you didn't inform them in advance that the clients needed these capabilities, then they could refuse to upgrade and still demand the anonymity service. Well, once the idea of an anonymity service is fully formed (presumably what we are doing here) it makes sense that it is a feature that a client can support or not support. (Maybe even a supported or requires tag?) Then it is reasonable for a service provider to say you can make anonymous calls if your client supports anonymity. If a subscriber has a policy of _only_ anonymous calls, and a user has a client that cannot make anonymous calls, then he is SOL. I don't see why this is any different than any _other_ situation where an optional client feature might be required by SP or subscriber policy. Again, the alternative is a presumption on the networks part that it knows what the user _really_ means to do better than the user does. Such an presumption on policy violations scares me in the generic sense. It's different because the 'subscriber policy' feature is not just a groovy addition to the service, but something that the Service Provide must provide for the subscriber 'by a simple means' (in the words of the European legislation) by which they mean I make a phone call to my Service Provider and ask. Upgrading possibly hundreds of clients might not be considered a 'simple means'. Again, not a question of knowing what the user 'wants' - in this case the subscribers wishe's overrule the users wishe's - we know the user wants to reveal their identity but in this case the user is 'SOL'. ...Mark ------_=_NextPart_001_01C1E527.F56D7A84 Content-Type: text/html; charset="iso-8859-1" Message
Ben wrote:

Which then allows the user to decide whether or not to continue according to policy, or just not make the call. Otherwise, the network seems to be in the business of deciding that the user really does not mind if the call is anonymous. That seems fairly benign in this particular case, but not generically (what if the policy was _no_ anonymous calls.)

A 'no anonymous calls' policy would be in breach of the users right to make anonymous calls. It is not the network that is deciding that the user does not mind if the call is anonymous, it is the subscriber, and they have a legal right to do this. The subscribe must be able to control what information the network reveals about them. The user does not have the right to ask the network to reveal information that the subscriber does not want revealed - although the use can of course reveal the information themselves.

2) Even with a well-crafted UA, why is the _user_ expected to re-configure their client because of the _subscriber's_ wishes. And when the policy changes, how will we indicate to all the users that they should now re-configure their clients again ?

They don't have to. Doing so just cuts down on the reject-due-to-policy-violation-oops-retry cycles. Now, I assume the user must have some relationship with the subscriber (else how does he have credentials), and the subscriber _could_ just tell the user. Not everything has to be automatic.

Frequent reject-due-to- policy-violation-oops-retry cycles are just unaceptable for wireless environments. There must be a 'works first time' solution. If you think the user needs to be informed that their call has become anonymous, then fine, let's standardise this indication.

I hope all the Service Providers wanting to launch SIP services have got their list of client requirements worked out. If your subscriber asks for this anonymity service they will not be impressed if they have to upgrade/re-configure all their clients. If you didn't inform them in advance that the clients needed these capabilities, then they could refuse to upgrade and still demand the anonymity service.

Well, once the idea of an anonymity service is fully formed (presumably what we are doing here) it makes sense that it is a feature that a client can support or not support. (Maybe even a supported or requires tag?) Then it is reasonable for a service provider to say you can make anonymous calls if your client supports anonymity. If a subscriber has a policy of _only_ anonymous calls, and a user has a client that cannot make anonymous calls, then he is SOL. I don't see why this is any different than any _other_ situation where an optional client feature might be required by SP or subscriber policy. Again, the alternative is a presumption on the networks part that it knows what the user _really_ means to do better than the user does. Such an presumption on policy violations scares me in the generic sense.

It's different because the 'subscriber policy' feature is not just a groovy addition to the service, but something that the Service Provide must provide for the subscriber 'by a simple means' (in the words of the European legislation) by which they mean I make a phone call to my Service Provider and ask. Upgrading possibly hundreds of clients might not be considered a 'simple means'.

Again, not a question of knowing what the user 'wants' - in this case the subscribers wishe's overrule the users wishe's - we know the user wants to reveal their identity but in this case the user is 'SOL'.

...Mark
------_=_NextPart_001_01C1E527.F56D7A84-- _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Tue Apr 16 06:52:32 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA28755 for ; Tue, 16 Apr 2002 06:52:32 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id GAA04500 for sip-archive@odin.ietf.org; Tue, 16 Apr 2002 06:52:34 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id GAA02526; Tue, 16 Apr 2002 06:10:27 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id GAA02493 for ; Tue, 16 Apr 2002 06:10:24 -0400 (EDT) Received: from lohi.eng.song.fi (lohi.eng.song.fi [195.10.149.18]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA28194 for ; Tue, 16 Apr 2002 06:10:19 -0400 (EDT) From: jh@lohi.eng.song.fi Received: from harjus.eng.song.fi ([195.10.149.20]) by lohi.eng.song.fi with esmtp (Exim 3.34 #1 (Debian)) id 16xPul-0004Zq-00; Tue, 16 Apr 2002 13:10:19 +0300 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15547.63627.41177.567678@harjus.eng.song.fi> Date: Tue, 16 Apr 2002 13:10:19 +0300 To: "Mark Watson" Cc: "'Ben Campbell'" , "Chiou, Mark" , Dean Willis , Mpierce1@aol.com, sip@ietf.org Subject: RE: Summary of RE: [Sip] Comment, SIP Privacy draft In-Reply-To: References: X-Mailer: VM 7.01 under Emacs 21.1.1 Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit the current bis-09 text says: The From header field allows for a display name. A UAC SHOULD use the display name Anonymous , along with a syntactically correct, but otherwise meaningless URI (like sip:thisis@anonymous.invalid), if the identity of the client is to remain hidden. this is all that is needed except that in my service the uri must be meaningful. most UAs on the market support this. so fail to see what the issue is. -- juha _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Tue Apr 16 07:07:04 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA29025 for ; Tue, 16 Apr 2002 07:07:04 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id HAA05342 for sip-archive@odin.ietf.org; Tue, 16 Apr 2002 07:07:02 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id GAA03940; Tue, 16 Apr 2002 06:32:04 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id GAA03909 for ; Tue, 16 Apr 2002 06:32:00 -0400 (EDT) Received: from zctfs063.nortelnetworks.com (zctfs063.nortelnetworks.com [47.164.128.120]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA28546 for ; Tue, 16 Apr 2002 06:31:57 -0400 (EDT) Received: from znsgs01r.europe.nortel.com (znsgs01r.europe.nortel.com [47.137.129.92]) by zctfs063.nortelnetworks.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id g3GAVQL07433; Tue, 16 Apr 2002 12:31:26 +0200 (MEST) Received: from zwcwc012.europe.nortel.com (zwcwc012.europe.nortel.com [47.73.112.187]) by znsgs01r.europe.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id g3GAUkH07757; Tue, 16 Apr 2002 11:30:47 +0100 (BST) Received: by zwcwc012.europe.nortel.com with Internet Mail Service (5.5.2653.19) id ; Tue, 16 Apr 2002 11:31:27 +0100 Message-ID: From: "Mark Watson" To: "'jh@lohi.eng.song.fi'" , "'Ben Campbell'" , "Chiou, Mark" , Dean Willis , Mpierce1@aol.com, sip@ietf.org Subject: RE: Summary of RE: [Sip] Comment, SIP Privacy draft Date: Tue, 16 Apr 2002 11:31:20 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C1E531.D9464E8A" Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C1E531.D9464E8A Content-Type: text/plain The client capability issue was for the case where the user does not wish to remain anonymous, but the subscriber does. Without a network modification of the From field then: 1) The user includes their identity, and the session is rejected. There is no reject code which clearly indicates what action the user/UA should take. There will be no current UAs which would know to auto-retry with 'Anonymous', so this will require user intervention on all calls. Auto-retrys are no good for wireless anyway. 2) It was suggested that the client should have a 'always anonymous' option which the user can set, so that all calls via this subscription will be anonymous. Again, current clients may or may not have this, so relying on this to provide the 'subscriber anonymity' service without the retrys of (1) is not such a good idea unless you have clearly told subscribers - before they subscribe - that such a capability is needed. Service Providers need to be well aware of the client capabilities needed to implement the regulatory services they have to provide, so that they can make it clear to potential subscribers what those required client capabilities are. Even so, I really can't see all the above being realistic. Imagine a subscriber goes to their service provider and requests anonymity. The first thing that happens is that all calls through the subscription start failing with some 'Privacy violation' response code. 'Oh sorry,' says the Service Provider, 'but you asked for all calls to be anonymous and then carried on trying to make non-anonymous calls. You'll need to tell all the users to change their settings to anonymous'. Whilst heamoraging money due to lost business, as none of their employees can make calls, the subscriber makes the not unreasonable point that they could tell all their users to switch to anonymous calls anyway, without asking the Service Provider, so what is the point of their regulatory right to an anonymity service ?? It has to work in a manner which is transparent and simple to the users and subscriber. If you want a client-based solution to this service, then you need to standardise a way of automatically informing & updating clients about the subscription anonymity policy. Still doesn't work for forwarding users. The alternative is to accept that From/To modification in the network is required to implement these services & no standardisation is required. ....Mark > -----Original Message----- > From: jh@lohi.eng.song.fi [mailto:jh@lohi.eng.song.fi] > Sent: 16 April 2002 11:10 > To: Watson, Mark [MDN05:EP10:EXCH] > Cc: 'Ben Campbell'; Chiou, Mark; Dean Willis; Mpierce1@aol.com; > sip@ietf.org > Subject: RE: Summary of RE: [Sip] Comment, SIP Privacy draft > > > the current bis-09 text says: > > The From header field allows for a display name. A UAC SHOULD use the > display name Anonymous , along with a syntactically correct, but > otherwise meaningless URI (like sip:thisis@anonymous.invalid), if > the identity of the client is to remain hidden. > > this is all that is needed except that in my service the uri must be > meaningful. > > most UAs on the market support this. so fail to see what the > issue is. > > -- juha > > ------_=_NextPart_001_01C1E531.D9464E8A Content-Type: text/html Content-Transfer-Encoding: quoted-printable RE: Summary of RE: [Sip] Comment, SIP Privacy draft
The client capability issue was for the case where = the user does not wish to remain anonymous, but the subscriber = does.

Without a network modification of the From field = then:

1) The user includes their identity, and the session = is rejected. There is no reject code which clearly indicates what = action the user/UA should take. There will be no current UAs which = would know to auto-retry with 'Anonymous', so this will require user = intervention on all calls. Auto-retrys are no good for wireless = anyway.

2) It was suggested that the client should have a = 'always anonymous' option which the user can set, so that all calls via = this subscription will be anonymous. Again, current clients may or may = not have this, so relying on this to provide the 'subscriber anonymity' = service without the retrys of (1) is not such a good idea unless you = have clearly told subscribers - before they subscribe - that such a = capability is needed.

Service Providers need to be well aware of the client = capabilities needed to implement the regulatory services they have to = provide, so that they can make it clear to potential subscribers what = those required client capabilities are.

Even so, I really can't see all the above being = realistic. Imagine a subscriber goes to their service provider and = requests anonymity. The first thing that happens is that all calls = through the subscription start failing with some 'Privacy violation' = response code. 'Oh sorry,' says the Service Provider, 'but you asked = for all calls to be anonymous and then carried on trying to make = non-anonymous calls. You'll need to tell all the users to change their = settings to anonymous'.

Whilst heamoraging money due to lost business, as = none of their employees can make calls, the subscriber makes the not = unreasonable point that they could tell all their users to switch to = anonymous calls anyway, without asking the Service Provider, so what is = the point of their regulatory right to an anonymity service = ??

It has to work in a manner which is transparent and = simple to the users and subscriber. If you want a client-based solution = to this service, then you need to standardise a way of automatically = informing & updating clients about the subscription anonymity = policy. Still doesn't work for forwarding users.

The alternative is to accept that From/To = modification in the network is required to implement these services = & no standardisation is required.

....Mark

> -----Original Message-----
> From: jh@lohi.eng.song.fi [mailto:jh@lohi.eng.song.fi]
> Sent: 16 April 2002 11:10
> To: Watson, Mark [MDN05:EP10:EXCH]
> Cc: 'Ben Campbell'; Chiou, Mark; Dean Willis; = Mpierce1@aol.com;
> sip@ietf.org
> Subject: RE: Summary of RE: [Sip] Comment, SIP = Privacy draft
>
>
> the current bis-09 text says:
>
> The From header field allows for a display = name. A UAC SHOULD use the
> display name Anonymous , along with a = syntactically correct, but
> otherwise meaningless URI (like = sip:thisis@anonymous.invalid), if
> the identity of the client is to remain = hidden.
>
> this is all that is needed except that in my = service the uri must be
> meaningful.
>
> most UAs on the market support this. so = fail to see what the
> issue is.
>
> -- juha
>
>
------_=_NextPart_001_01C1E531.D9464E8A-- _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Tue Apr 16 07:33:16 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA29446 for ; Tue, 16 Apr 2002 07:33:16 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id HAA06690 for sip-archive@odin.ietf.org; Tue, 16 Apr 2002 07:33:18 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id GAA04640; Tue, 16 Apr 2002 06:58:50 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id GAA04608 for ; Tue, 16 Apr 2002 06:58:46 -0400 (EDT) Received: from lohi.eng.song.fi (lohi.eng.song.fi [195.10.149.18]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA28922 for ; Tue, 16 Apr 2002 06:58:41 -0400 (EDT) From: jh@lohi.eng.song.fi Received: from harjus.eng.song.fi ([195.10.149.20]) by lohi.eng.song.fi with esmtp (Exim 3.34 #1 (Debian)) id 16xQfX-0004ak-00; Tue, 16 Apr 2002 13:58:39 +0300 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15548.991.449340.282891@harjus.eng.song.fi> Date: Tue, 16 Apr 2002 13:58:39 +0300 To: "Mark Watson" Cc: "'Ben Campbell'" , "Chiou, Mark" , Dean Willis , Mpierce1@aol.com, sip@ietf.org Subject: RE: Summary of RE: [Sip] Comment, SIP Privacy draft In-Reply-To: References: X-Mailer: VM 7.01 under Emacs 21.1.1 Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit Mark Watson writes: > The client capability issue was for the case where the user does not wish to > remain anonymous, but the subscriber does. what is a subscriber and how does it differ from a user? where is the term subscriber defined? > 1) The user includes their identity, and the session is rejected. There is > no reject code which clearly indicates what action the user/UA should take. > There will be no current UAs which would know to auto-retry with > 'Anonymous', so this will require user intervention on all calls. > Auto-retrys are no good for wireless anyway. this whole hassle seems to originate from your subscriber business. i don't see any need to a subscriber that is not the same as the user. is this again some 3gpp thing? > 2) It was suggested that the client should have a 'always anonymous' option > which the user can set, so that all calls via this subscription will be > anonymous. Again, current clients may or may not have this, so relying on > this to provide the 'subscriber anonymity' service without the retrys of (1) > is not such a good idea unless you have clearly told subscribers - before > they subscribe - that such a capability is needed. as i said, most client that i have see do already have this "always anonymous" option. i don't see any need to complicate the sip specs for those clients that don't because the implementation is trivial. > Service Providers need to be well aware of the client capabilities needed to > implement the regulatory services they have to provide, so that they can > make it clear to potential subscribers what those required client > capabilities are. i have no problem with that. already know we need to test the clients and give recommendations to users. > Even so, I really can't see all the above being realistic. Imagine a > subscriber goes to their service provider and requests anonymity. The first > thing that happens is that all calls through the subscription start failing > with some 'Privacy violation' response code. 'Oh sorry,' says the Service > Provider, 'but you asked for all calls to be anonymous and then carried on > trying to make non-anonymous calls. You'll need to tell all the users to > change their settings to anonymous'. this is no problem, because the user requests anonymity by using Anonymous in the display string. it is not a subscription option. all subscriptions look the same in this regard. > Whilst heamoraging money due to lost business, as none of their employees > can make calls, the subscriber makes the not unreasonable point that they > could tell all their users to switch to anonymous calls anyway, without > asking the Service Provider, so what is the point of their regulatory right > to an anonymity service ?? it makes no sense to try to emulate stupid pstn phones using with sip UAs. we can and should assume that a sip UA is a user configurable beast. therefore, the user itself can decide either permanently or on a call by call basis if it wants anonymity or not. > It has to work in a manner which is transparent and simple to the users and > subscriber. If you want a client-based solution to this service, then you > need to standardise a way of automatically informing & updating clients > about the subscription anonymity policy. Still doesn't work for forwarding > users. as i have said, there is no such thing as subscription anonymity policy. -- juha _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@ns.ietf.org Tue Apr 16 09:00:50 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA01284 for ; Tue, 16 Apr 2002 09:00:50 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id JAA11910 for sip-archive@odin.ietf.org; Tue, 16 Apr 2002 09:00:53 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id IAA09862; Tue, 16 Apr 2002 08:30:32 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id IAA09809 for ; Tue, 16 Apr 2002 08:30:25 -0400 (EDT) Received: from zctfs063.nortelnetworks.com (zctfs063.nortelnetworks.com [47.164.128.120]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA00786 for ; Tue, 16 Apr 2002 08:30:21 -0400 (EDT) Received: from zwcwc012.europe.nortel.com (zwcwc012.europe.nortel.com [47.73.112.187]) by zctfs063.nortelnetworks.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id g3GCSqL19566; Tue, 16 Apr 2002 14:28:53 +0200 (MEST) Received: by zwcwc012.europe.nortel.com with Internet Mail Service (5.5.2653.19) id ; Tue, 16 Apr 2002 13:28:56 +0100 Message-ID: From: "Mark Watson" To: "'jh@lohi.eng.song.fi'" Cc: "'Ben Campbell'" , "Chiou, Mark" , Dean Willis , Mpierce1@aol.com, sip@ietf.org Subject: RE: Summary of RE: [Sip] Comment, SIP Privacy draft Date: Tue, 16 Apr 2002 13:28:53 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C1E542.452E50B0" Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C1E542.452E50B0 Content-Type: text/plain > what is a subscriber and how does it differ from a user? where is the > term subscriber defined? This thread has been going for a while now, and as you said in the rest of your message, the concept of a subscriber as separate from the user is pretty important to the arguments, which is why I keep re-describing it. The subscriber is just one example of a person who has an interest in a session who does not have a 'user agent' involved in the session to represent them. My contention is that the easiest way to represent this person in the session is through services in the network. See http://www1.ietf.org/mail-archive/working-groups/sip/current/msg04720.html for a description of why the subscriber is different from the user. In terms of definition, the definition from the European Directive on Data Protection intelecommunications (97/66/EC) says: (a) 'subscriber` shall mean any natural or legal person who or which is party to a contract with the provider of publicly available telecommunications services for the supply of such services; (b) 'user` shall mean any natural person using a publicly available telecommunications service, for private or business purposes, without necessarily having subscribed to this service; There is a lot of information about this and data protection in telecommunications in general at http://www.cdt.org/privacy/eudirective/ Finally, I just spotted that this directive is due to be replaced by a revision which is explicitly intended to cover new technologies http://europa.eu.int/eur-lex/en/com/pdf/2000/en_500PC0385.pdf. I would not advise any Service Provider to ignore this stuff. Regards, Mark ------_=_NextPart_001_01C1E542.452E50B0 Content-Type: text/html Content-Transfer-Encoding: quoted-printable RE: Summary of RE: [Sip] Comment, SIP Privacy draft

> what is a subscriber and how does it differ = from a user? where is the
> term subscriber defined?

This thread has been going for a while now, and as = you said in the rest of your message, the concept of a subscriber as = separate from the user is pretty important to the arguments, which is = why I keep re-describing it.

The subscriber is just one example of a person who = has an interest in a session who does not have a 'user agent' involved = in the session to represent them. My contention is that the easiest way = to represent this person in the session is through services in the = network.

See http://www1.ietf.org/mail-archive/working-groups/sip/c= urrent/msg04720.html for a description of why the subscriber is = different from the user.

In terms of definition, the definition from the = European Directive on Data Protection intelecommunications (97/66/EC) = says:

(a) 'subscriber` shall mean any natural or legal = person who or which is party to a contract with the provider of = publicly available telecommunications services for the supply of such = services;

(b) 'user` shall mean any natural person using a = publicly available telecommunications service, for private or business = purposes, without necessarily having subscribed to this = service;

There is a lot of information about this and data = protection in telecommunications in general at http://www.cdt.org/privacy/eudirective/
=
Finally, I just spotted that this directive is due to = be replaced by a revision which is explicitly intended to cover new = technologies http://europa.eu.int/eur-lex/en/com/pdf/2000/en_500PC0= 385.pdf. I would not advise any Service Provider to ignore this = stuff.

Regards,

Mark
------_=_NextPart_001_01C1E542.452E50B0-- _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@ns.ietf.org Tue Apr 16 09:09:26 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA01488 for ; Tue, 16 Apr 2002 09:09:26 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id JAA12540 for sip-archive@odin.ietf.org; Tue, 16 Apr 2002 09:09:29 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id IAA10690; Tue, 16 Apr 2002 08:42:18 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id IAA10658 for ; Tue, 16 Apr 2002 08:42:14 -0400 (EDT) Received: from lohi.eng.song.fi (lohi.eng.song.fi [195.10.149.18]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA01083 for ; Tue, 16 Apr 2002 08:42:10 -0400 (EDT) From: jh@lohi.eng.song.fi Received: from harjus.eng.song.fi ([195.10.149.20]) by lohi.eng.song.fi with esmtp (Exim 3.34 #1 (Debian)) id 16xSHe-0004fM-00; Tue, 16 Apr 2002 15:42:06 +0300 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15548.7198.839337.273474@harjus.eng.song.fi> Date: Tue, 16 Apr 2002 15:42:06 +0300 To: "Mark Watson" Cc: "'Ben Campbell'" , "Chiou, Mark" , Dean Willis , Mpierce1@aol.com, sip@ietf.org Subject: RE: Summary of RE: [Sip] Comment, SIP Privacy draft In-Reply-To: References: X-Mailer: VM 7.01 under Emacs 21.1.1 Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit Mark Watson writes: > The subscriber is just one example of a person who has an interest in a > session who does not have a 'user agent' involved in the session to > represent them. My contention is that the easiest way to represent this > person in the session is through services in the network. i still fail to see the difference between a user and subscriber. in order for the user to use my sip service, the user MUST first subscribe the service. the user may have any number of sip identities (uris) associated with the subscription. > (a) 'subscriber` shall mean any natural or legal person who or which is > party to a contract with the provider of publicly available > telecommunications services for the supply of such services; fine. > (b) 'user` shall mean any natural person using a publicly available > telecommunications service, for private or business purposes, without > necessarily having subscribed to this service; i don't understand what the above could mean. a user can't use my sip service without being first subscribed to it, i.e., the user must have a username and a password that identify a valid subscription. i don't care who made the subscription, but in general it is a VERY bad idea to pass a given username/password to many people. if you do it then there is no way to figure out who actually made a call. -- juha _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@ns.ietf.org Tue Apr 16 09:26:40 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA02543 for ; Tue, 16 Apr 2002 09:26:39 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id JAA14038 for sip-archive@odin.ietf.org; Tue, 16 Apr 2002 09:26:43 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id IAA11456; Tue, 16 Apr 2002 08:58:03 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id IAA11430 for ; Tue, 16 Apr 2002 08:58:00 -0400 (EDT) Received: from aifhs8.alcatel.fr (ceg-na5.alcatel.fr [213.223.66.5]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA01235 for ; Tue, 16 Apr 2002 08:57:56 -0400 (EDT) From: Juan-Carlos.Rojas@alcatel.fr Received: from frmail25.netfr.alcatel.fr (frmail25.netfr.alcatel.fr [155.132.182.155]) by aifhs8.alcatel.fr (ALCANET/SMTP2) with ESMTP id OAA17988; Tue, 16 Apr 2002 14:57:27 +0200 (MET DST) To: Gonzalo.Camarillo@lmf.ericsson.se Cc: sip@ietf.org Date: Tue, 16 Apr 2002 14:57:25 +0200 Message-ID: X-MIMETrack: Serialize by Router on FRMAIL25/FR/ALCATEL(Release 5.0.8 |June 18, 2001) at 04/16/2002 14:57:26 MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Subject: [Sip] Manyfolks using SPDng Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Hello Gonzalo, Is there any project to create an internet-draft (or to update the existing one) for the preconditions mechanism currently defined in the manyfolks draft, but using SDPng (and so, XML based) ? Thank you for your answer Best regards Juan Carlos _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@ns.ietf.org Tue Apr 16 09:27:23 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA02604 for ; Tue, 16 Apr 2002 09:27:23 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id JAA14110 for sip-archive@odin.ietf.org; Tue, 16 Apr 2002 09:27:26 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id IAA11296; Tue, 16 Apr 2002 08:54:29 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id IAA11265 for ; Tue, 16 Apr 2002 08:54:25 -0400 (EDT) Received: from aifhs8.alcatel.fr ([194.133.58.5]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA01191 for ; Tue, 16 Apr 2002 08:54:18 -0400 (EDT) From: Juan-Carlos.Rojas@alcatel.fr Received: from frmail25.netfr.alcatel.fr (frmail25.netfr.alcatel.fr [155.132.182.155]) by aifhs8.alcatel.fr (ALCANET/SMTP2) with ESMTP id OAA17012; Tue, 16 Apr 2002 14:53:42 +0200 (MET DST) Subject: Re: [Sip] Re: Offer by the callee To: Gonzalo Camarillo Cc: Jonathan Rosenberg , sip@ietf.org Date: Tue, 16 Apr 2002 14:53:40 +0200 Message-ID: X-MIMETrack: Serialize by Router on FRMAIL25/FR/ALCATEL(Release 5.0.8 |June 18, 2001) at 04/16/2002 14:53:41 MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Hi Gonzalo, Thank you very much, indeed this is compliant with the offer/answer draft. Best regards Juan Carlos Gonzalo Camarillo on 08/04/2002 16:22:20 To: Juan-Carlos ROJAS/FR/ALCATEL@ALCATEL cc: Jonathan Rosenberg , sip@ietf.org Subject: Re: [Sip] Re: Offer by the callee Hello Juan Carlos, I have been thinking more about your scenario, and I think that sending back in the first answer a c=0.0.0.0 line would be the right thing to do. This way, even though you have returned an answer with preconditions, the other party will not perform resource reservation, since it does not have an IP address to send media to. Then, when you are ready to send an new offer, you will send it in an UPDATE. The flow would look as follows: INVITE (offer-1) -------------------------------------------------------------> 183 (answer-to-offer-1, c=0.0.0.0) <------------------------------------------------------------- PRACK -------------------------------------------------------------> 200 PRACK <------------------------------------------------------------- UPDATE (offer-2) <------------------------------------------------------------- 200 UPDATE (answer-to-offer-2) -------------------------------------------------------------> <========== Resource Reservation ==========> Best regards, Gonzalo _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@ns.ietf.org Tue Apr 16 09:32:42 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA02957 for ; Tue, 16 Apr 2002 09:32:37 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id JAA15077 for sip-archive@odin.ietf.org; Tue, 16 Apr 2002 09:32:40 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA11744; Tue, 16 Apr 2002 09:00:22 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA11712 for ; Tue, 16 Apr 2002 09:00:18 -0400 (EDT) Received: from zctfs063.nortelnetworks.com (zctfs063.nortelnetworks.com [47.164.128.120]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA01269 for ; Tue, 16 Apr 2002 09:00:01 -0400 (EDT) Received: from zwcwc012.europe.nortel.com (zwcwc012.europe.nortel.com [47.73.112.187]) by zctfs063.nortelnetworks.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id g3GCwFL24556; Tue, 16 Apr 2002 14:58:16 +0200 (MEST) Received: by zwcwc012.europe.nortel.com with Internet Mail Service (5.5.2653.19) id ; Tue, 16 Apr 2002 13:58:19 +0100 Message-ID: From: "Mark Watson" To: "'jh@lohi.eng.song.fi'" Cc: "'Ben Campbell'" , "Chiou, Mark" , Dean Willis , Mpierce1@aol.com, sip@ietf.org Subject: RE: Summary of RE: [Sip] Comment, SIP Privacy draft Date: Tue, 16 Apr 2002 13:58:11 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C1E546.5CC77432" Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C1E546.5CC77432 Content-Type: text/plain Perhaps an example will help: The subscriber is a company - the company has made a contract with you as service provider for the provision of the service. The user is an employee of the company - the user may be 'subscriber' in the technical sense to your system, but they are not the subscriber as defined in the definition below - they do not have any contract with you, the contract is with the company. If you insist on individual contracts with the employees of a company to which you offer service, then you are equating user and subscriber, but I doubt the company or its employees would be very happy with this mode of operation. ...Mark > -----Original Message----- > From: jh@lohi.eng.song.fi [mailto:jh@lohi.eng.song.fi] > Sent: 16 April 2002 13:42 > To: Watson, Mark [MDN05:EP10:EXCH] > Cc: 'Ben Campbell'; Chiou, Mark; Dean Willis; Mpierce1@aol.com; > sip@ietf.org > Subject: RE: Summary of RE: [Sip] Comment, SIP Privacy draft > > > Mark Watson writes: > > > The subscriber is just one example of a person who has an > interest in a > > session who does not have a 'user agent' involved in the session to > > represent them. My contention is that the easiest way to > represent this > > person in the session is through services in the network. > > i still fail to see the difference between a user and subscriber. in > order for the user to use my sip service, the user MUST first > subscribe > the service. the user may have any number of sip identities (uris) > associated with the subscription. > > > (a) 'subscriber` shall mean any natural or legal person > who or which is > > party to a contract with the provider of publicly available > > telecommunications services for the supply of such services; > > fine. > > > (b) 'user` shall mean any natural person using a publicly available > > telecommunications service, for private or business > purposes, without > > necessarily having subscribed to this service; > > i don't understand what the above could mean. > > a user can't use my sip service without being first subscribed to it, > i.e., the user must have a username and a password that identify a > valid subscription. i don't care who made the subscription, but in > general it is a VERY bad idea to pass a given > username/password to many > people. if you do it then there is no way to figure out who actually > made a call. > > -- juha > > ------_=_NextPart_001_01C1E546.5CC77432 Content-Type: text/html Content-Transfer-Encoding: quoted-printable RE: Summary of RE: [Sip] Comment, SIP Privacy draft
Perhaps an example will help:

The subscriber is a company - the company has made a = contract with you as service provider for the provision of the = service.

The user is an employee of the company - the user may = be 'subscriber' in the technical sense to your system, but they are not = the subscriber as defined in the definition below - they do not have = any contract with you, the contract is with the company.

If you insist on individual contracts with the = employees of a company to which you offer service, then you are = equating user and subscriber, but I doubt the company or its employees = would be very happy with this mode of operation.

...Mark

> -----Original Message-----
> From: jh@lohi.eng.song.fi [mailto:jh@lohi.eng.song.fi]
> Sent: 16 April 2002 13:42
> To: Watson, Mark [MDN05:EP10:EXCH]
> Cc: 'Ben Campbell'; Chiou, Mark; Dean Willis; = Mpierce1@aol.com;
> sip@ietf.org
> Subject: RE: Summary of RE: [Sip] Comment, SIP = Privacy draft
>
>
> Mark Watson writes:
>
> > The subscriber is just one example = of a person who has an
> interest in a
> > session who does not have a 'user = agent' involved in the session to
> > represent them. My contention is = that the easiest way to
> represent this
> > person in the session is through = services in the network.
>
> i still fail to see the difference between a = user and subscriber. in
> order for the user to use my sip service, the = user MUST first
> subscribe
> the service. the user may have any number = of sip identities (uris)
> associated with the subscription.
>
> > (a) 'subscriber` shall mean any = natural or legal person
> who or which is
> > party to a contract with the = provider of publicly available
> > telecommunications services for the = supply of such services;
>
> fine.
>
> > (b) 'user` shall mean any natural = person using a publicly available
> > telecommunications service, for = private or business
> purposes, without
> > necessarily having subscribed to = this service;
>
> i don't understand what the above could = mean.
>
> a user can't use my sip service without = being first subscribed to it,
> i.e., the user must have a username and a = password that identify a
> valid subscription. i don't care = who made the subscription, but in
> general it is a VERY bad idea to pass a = given
> username/password to many
> people. if you do it then there is no way = to figure out who actually
> made a call.
>
> -- juha
>
>
------_=_NextPart_001_01C1E546.5CC77432-- _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@ns.ietf.org Tue Apr 16 09:51:23 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA04257 for ; Tue, 16 Apr 2002 09:51:22 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id JAA16794 for sip-archive@odin.ietf.org; Tue, 16 Apr 2002 09:51:26 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA12810; Tue, 16 Apr 2002 09:12:21 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA12691 for ; Tue, 16 Apr 2002 09:12:08 -0400 (EDT) Received: from auemail1.firewall.lucent.com (auemail1.lucent.com [192.11.223.161]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA01533 for ; Tue, 16 Apr 2002 09:12:04 -0400 (EDT) Received: from uk0006exch001h.wins.lucent.com (h135-86-160-150.lucent.com [135.86.160.150]) by auemail1.firewall.lucent.com (Switch-2.1.3/Switch-2.1.0) with ESMTP id g3GDBZw24271 for ; Tue, 16 Apr 2002 09:11:36 -0400 (EDT) Received: by uk0006exch001h.uk.lucent.com with Internet Mail Service (5.5.2650.21) id <2GP7G9AF>; Tue, 16 Apr 2002 14:11:35 +0100 Message-ID: <475FF955A05DD411980D00508B6D5FB004CA7755@en0033exch001u.uk.lucent.com> From: "Chen, Xin (Xin)" To: Gonzalo Camarillo , Juan-Carlos.Rojas@alcatel.fr Cc: Jonathan Rosenberg , sip@ietf.org Subject: RE: [Sip] Re: Offer by the callee Date: Tue, 16 Apr 2002 14:11:33 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Hi Gonzalo, I don't want to open the debating again, but this solution you provided assumes the QoS reservation protocol has to use the IP address of both sides, it again reminds me about RSVP. I thought we agreed that manyfolks is independent with any QoS reservation protocol, therefore please don't provide solution on SIP level based on our guessing on what happens IP level. Thanks Xin Chen Lucent Technologies Tel: +44 1793 883137 Mobile: +44 7799 034668 -----Original Message----- From: Gonzalo Camarillo [mailto:Gonzalo.Camarillo@lmf.ericsson.se] Sent: 08 April 2002 15:22 To: Juan-Carlos.Rojas@alcatel.fr Cc: Jonathan Rosenberg; sip@ietf.org Subject: Re: [Sip] Re: Offer by the callee Hello Juan Carlos, I have been thinking more about your scenario, and I think that sending back in the first answer a c=0.0.0.0 line would be the right thing to do. This way, even though you have returned an answer with preconditions, the other party will not perform resource reservation, since it does not have an IP address to send media to. Then, when you are ready to send an new offer, you will send it in an UPDATE. The flow would look as follows: INVITE (offer-1) -------------------------------------------------------------> 183 (answer-to-offer-1, c=0.0.0.0) <------------------------------------------------------------- PRACK -------------------------------------------------------------> 200 PRACK <------------------------------------------------------------- UPDATE (offer-2) <------------------------------------------------------------- 200 UPDATE (answer-to-offer-2) -------------------------------------------------------------> <========== Resource Reservation ==========> Best regards, Gonzalo Juan-Carlos.Rojas@alcatel.fr wrote: > > Hi Gonzalo, > > Thank you for your answer > You are right, but sending a held SDP does not prevent the calling party to > start resource reservation, but only to send media. > I agree with you that normally, a port number to zero indicates refusal of > the media stream. Nevertheless, according to Offer/Answer draft, all port > numbers equal to zero is used also to announce capabilities (section 9), > and very often it is used to say just "don't use this media". > > What I need here is to give to the answerer the possibility to say "Mr.the > Offerer, I'm not rejecting your Invite, but I'd like to send you a new > offer right now, so it is useless to start resource reservation before > receiving this new offer" > > Best regards > Juan Carlos > > Gonzalo Camarillo @ietf.org on > 20/03/2002 05:01:02 > > Sent by: sip-admin@ietf.org > > To: Juan-Carlos ROJAS/FR/ALCATEL@ALCATEL > cc: Jonathan Rosenberg , sip@ietf.org > Subject: [Sip] Re: Offer by the callee > > Hi, > > Setting the port number to zero means refusal of the stream, so you are > risking that the caller sends a CANCEL, since you have refused all the > media streams. A better solution would be to send a held SDP > (a=inactive). > > Regards, > > Gonzalo > > Juan-Carlos.Rojas@alcatel.fr wrote: > > > > Hello, > > > > I'm trying to connect the offer/answer, update and manyfolks drafts for > the > > following scenario: > > - Alice sends an INVITE to Bob with "offer-1" > > - Bob wants to make an "offer-2" to Alice, before the completion of the > > session establishment > > - Bob would like to ask Alice to start resource reservation only based on > > the acceptation of "offer-2", and not before (in fact Bob knows that it > is > > useless to start resource reservation based on offer-1, because he knows > he > > will send immediatly a new offer-2, but he is obliged to wait for Prack > > before) > > > > The Update draft defines the response 155 to allow the answerer (the > callee > > in our case) to request "Mr. the calling, please *send me* a new offer", > > but there is no way for the same callee to announce "Mr. the calling, *I > > want to send you* a new offer right now". > > So, one possible way to achieve that is that the callee sends an answer > to > > the original offer but disabling all the media (in order to avoid to > start > > resource reservation), and next proposing a new offer, as described in > the > > call flow below (assume for the example that they are using end-to-end > > resource reservation, but please don't generate a new debate on this > > topic): > > > > Alice > > Bob > > INVITE (offer-1) > > -----------------------------------------------------------------> > > 183 (answer-to-offer-1, all port numbers to zero) > > <----------------------------------------------------------------- > > PRACK > > -----------------------------------------------------------------> > > 200 PRACK > > <----------------------------------------------------------------- > > UPDATE (offer-2, status-type=e2e) > > <----------------------------------------------------------------- > > 200 UPDATE (answer-to-offer-2) > > -----------------------------------------------------------------> > > > > <========== Resource Reservation ==========> > > > > UPDATE (current-status = desired-status) > > -----------------------------------------------------------------> > > 200 UPDATE > > <----------------------------------------------------------------- > > 200 INVITE > > <----------------------------------------------------------------- > > ACK > > -----------------------------------------------------------------> > > > > Is this scenario compliant with the drafts Offer/Answer, Update and > > Manyfolks ? > > > > Thank you for your answer > > Best regards > > Juan Carlos > > -- > Gonzalo Camarillo Phone : +1 212 939 71 71 > Columbia University Mobile: +358 40 702 35 35 > 472 Computer Science Building Fax : +358 9 299 30 52 > 1214 Amsterdam Ave., Mail Code 0401 http://www.hut.fi/~gonzalo > New York, NY 10027 > USA Gonzalo.Camarillo@ericsson.com > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip -- Gonzalo Camarillo Phone : +358 9 299 33 71 Oy L M Ericsson Ab Mobile: +358 40 702 35 35 Telecom R&D Fax : +358 9 299 30 52 FIN-02420 Jorvas Email : Gonzalo.Camarillo@ericsson.com Finland http://www.hut.fi/~gonzalo _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@ns.ietf.org Tue Apr 16 09:55:41 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA04416 for ; Tue, 16 Apr 2002 09:55:40 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id JAA17106 for sip-archive@odin.ietf.org; Tue, 16 Apr 2002 09:55:44 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA13517; Tue, 16 Apr 2002 09:20:25 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA13410 for ; Tue, 16 Apr 2002 09:20:14 -0400 (EDT) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA02026; Tue, 16 Apr 2002 09:20:07 -0400 (EDT) Message-Id: <200204161320.JAA02026@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; CC: sip@ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Date: Tue, 16 Apr 2002 09:20:07 -0400 Subject: [Sip] I-D ACTION:draft-willis-sip-path-03.txt Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : SIP Extension for Registering Non-Adjacent Contacts Author(s) : D. Willis Filename : draft-willis-sip-path-03.txt Pages : 11 Date : 15-Apr-02 The REGISTER function is used in a SIP system primarily to associate a temporary contact address with an address-of-record. This contact is generally in the form of a URI, such as Contact: <sip:alice@pc33.atlanta.com> and is generally dynamic and associated with the IP address or hostname of the SIP UA. The problem is that network topology may be that there are one or more SIP proxies between the UA and the registrar, such that any message from the user's home network to the registered UA must traverse these proxies. The REGISTER method itself does not give us a mechanism to discover and record this sequence of proxies in the registrar for future use. This document defines an extension header, 'Path' which provides such a mechanism. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-willis-sip-path-03.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-willis-sip-path-03.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-willis-sip-path-03.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <20020415112706.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-willis-sip-path-03.txt --OtherAccess Content-Type: Message/External-body; name="draft-willis-sip-path-03.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20020415112706.I-D@ietf.org> --OtherAccess-- --NextPart-- _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@ns.ietf.org Tue Apr 16 09:58:28 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA04746 for ; Tue, 16 Apr 2002 09:58:28 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id JAA17314 for sip-archive@odin.ietf.org; Tue, 16 Apr 2002 09:58:32 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA12885; Tue, 16 Apr 2002 09:13:10 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA12843 for ; Tue, 16 Apr 2002 09:13:04 -0400 (EDT) Received: from magus.nostrum.com (root@magus.nostrum.com [66.119.225.66]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA01541 for ; Tue, 16 Apr 2002 09:13:00 -0400 (EDT) Received: from txbcampbell (root@magus.nostrum.com [66.119.225.66]) by magus.nostrum.com (8.11.0/8.11.0) with SMTP id g3GDCaX44345; Tue, 16 Apr 2002 08:12:36 -0500 (CDT) From: "Ben Campbell" To: "Mark Watson" , "Chiou, Mark" , "Dean Willis" , , Subject: RE: Summary of RE: [Sip] Comment, SIP Privacy draft Date: Tue, 16 Apr 2002 08:12:12 -0500 Message-ID: MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_00E7_01C1E51E.6964D540" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Importance: Normal Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org This is a multi-part message in MIME format. ------=_NextPart_000_00E7_01C1E51E.6964D540 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message -----Original Message----- From: Mark Watson [mailto:mwatson@nortelnetworks.com] Sent: Tuesday, April 16, 2002 4:21 AM To: 'Ben Campbell'; Chiou, Mark; Dean Willis; Mpierce1@aol.com; sip@ietf.org Subject: RE: Summary of RE: [Sip] Comment, SIP Privacy draft Ben wrote: Which then allows the user to decide whether or not to continue according to policy, or just not make the call. Otherwise, the network seems to be in the business of deciding that the user really does not mind if the call is anonymous. That seems fairly benign in this particular case, but not generically (what if the policy was _no_ anonymous calls.) A 'no anonymous calls' policy would be in breach of the users right to make anonymous calls. It is not the network that is deciding that the user does not mind if the call is anonymous, it is the subscriber, and they have a legal right to do this. The subscribe must be able to control what information the network reveals about them. The user does not have the right to ask the network to reveal information that the subscriber does not want revealed - although the use can of course reveal the information themselves. I was referring to a no anonymous calls policy on the part of the subscriber. 2) Even with a well-crafted UA, why is the _user_ expected to re-configure their client because of the _subscriber's_ wishes. And when the policy changes, how will we indicate to all the users that they should now re-configure their clients again ? They don't have to. Doing so just cuts down on the reject-due-to-policy-violation-oops-retry cycles. Now, I assume the user must have some relationship with the subscriber (else how does he have credentials), and the subscriber _could_ just tell the user. Not everything has to be automatic. Frequent reject-due-to- policy-violation-oops-retry cycles are just unaceptable for wireless environments. There must be a 'works first time' solution. If you think the user needs to be informed that their call has become anonymous, then fine, let's standardise this indication. A wireless network is one in which the network tends to excercise a lot more control over the UA than might be typical for other environments. It this case, the network is likely to be able to push configuration to the phone itself (i.e. the config for "what default privacy option to use". (This of course makes the b2bua changing From headers more feasible as well, as wireless providers tend to have fewer qualms about asserting this level of control.) I hope all the Service Providers wanting to launch SIP services have got their list of client requirements worked out. If your subscriber asks for this anonymity service they will not be impressed if they have to upgrade/re-configure all their clients. If you didn't inform them in advance that the clients needed these capabilities, then they could refuse to upgrade and still demand the anonymity service. Well, once the idea of an anonymity service is fully formed (presumably what we are doing here) it makes sense that it is a feature that a client can support or not support. (Maybe even a supported or requires tag?) Then it is reasonable for a service provider to say you can make anonymous calls if your client supports anonymity. If a subscriber has a policy of _only_ anonymous calls, and a user has a client that cannot make anonymous calls, then he is SOL. I don't see why this is any different than any _other_ situation where an optional client feature might be required by SP or subscriber policy. Again, the alternative is a presumption on the networks part that it knows what the user _really_ means to do better than the user does. Such an presumption on policy violations scares me in the generic sense. It's different because the 'subscriber policy' feature is not just a groovy addition to the service, but something that the Service Provide must provide for the subscriber 'by a simple means' (in the words of the European legislation) by which they mean I make a phone call to my Service Provider and ask. Upgrading possibly hundreds of clients might not be considered a 'simple means'. Again, not a question of knowing what the user 'wants' - in this case the subscribers wishe's overrule the users wishe's - we know the user wants to reveal their identity but in this case the user is 'SOL'. ...Mark ------=_NextPart_000_00E7_01C1E51E.6964D540 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Message

-----Original Message-----
From: Mark Watson=20 [mailto:mwatson@nortelnetworks.com]
Sent: Tuesday, April 16, = 2002=20 4:21 AM
To: 'Ben Campbell'; Chiou, Mark; Dean Willis;=20 Mpierce1@aol.com; sip@ietf.org
Subject: RE: Summary of RE: = [Sip]=20 Comment, SIP Privacy draft

Ben wrote:

Which=20 then allows the user to decide whether or not to continue = according=20 to policy, or just not make the call. Otherwise, the network seems = to=20 be in the business of deciding that the user really does = not mind if the call is anonymous. That seems fairly benign = in this=20 particular case, but not generically (what if the policy was _no_=20 anonymous=20 = calls.)

A 'no anonymous calls' policy would be in breach of = the users=20 right to make anonymous calls. It is not the network that is deciding = that the=20 user does not mind if the call is anonymous, it is the subscriber, and = they=20 have a legal right to do this. The subscribe must be able to control = what=20 information the network reveals about them. The user does not have the = right=20 to ask the network to reveal information that the subscriber does not = want=20 revealed - although the use can of course reveal the information=20 themselves.

I was=20 referring to a no anonymous calls policy on the part of the=20 subscriber.

2) Even with a well-crafted UA, why is the _user_ = expected=20 to re-configure their client because of the _subscriber's_ wishes. = And=20 when the policy changes, how will we indicate to all the users = that they=20 should now re-configure their clients again ?

They=20 don't have to. Doing so just cuts down on the=20 reject-due-to-policy-violation-oops-retry cycles. Now, I assume = the user=20 must have some relationship with the subscriber (else = how does he=20 have credentials), and the subscriber _could_ just tell the = user. Not=20 everything has to be=20 = automatic.

Frequent=20 reject-due-to- policy-violation-oops-retry cycles = are just=20 unaceptable for wireless environments. There must be a 'works first = time'=20 solution. If you think the user needs to be informed that their call = has=20 become anonymous, then fine, let's standardise this indication.

A wireless network is one in which the network tends to = excercise a lot=20 more control over the UA than might be typical for other environments. = It this case, the network is likely to be able to push = configuration to=20 the phone itself (i.e. the config for "what default privacy option to=20 use". (This of course makes the b2bua changing From headers more = feasible=20 as well, as wireless providers tend to have fewer qualms = about=20 asserting this level of=20 control.)

I hope all the Service Providers wanting to launch = SIP=20 services have got their list of client requirements worked out. If = your=20 subscriber asks for this anonymity service they will not be = impressed if=20 they have to upgrade/re-configure all their clients. If you didn't = inform=20 them in advance that the clients needed these capabilities, then = they=20 could refuse to upgrade and still demand the anonymity = service.

Well, once the idea of an anonymity service is fully = formed=20 (presumably what we are doing here) it makes sense that it is = a=20 feature that a client can support or not support. (Maybe even = a=20 supported or requires tag?) Then it is reasonable for a = service=20 provider to say you can make anonymous calls if your client = supports=20 anonymity. If a subscriber has a policy of _only_=20 anonymous calls, and a user has a client that cannot = make=20 anonymous calls, then he is SOL. =20 I don't see why this is any different than any _other_ situation = where an=20 optional client feature might be required by SP or subscriber = policy.=20 Again, the alternative is a presumption on the networks part that = it knows=20 what the user _really_ means to do better than the user does. Such = an=20 presumption on policy violations scares me in the generic=20 sense.

It's different=20 because the 'subscriber policy' feature is not just a groovy = addition to=20 the service, but something that the Service Provide must = provide for=20 the subscriber 'by a simple means' (in the words of the European = legislation)=20 by which they mean I make a phone call to my Service Provider and ask. = Upgrading possibly hundreds of clients might not be = considered a=20 'simple means'.

Again, not a=20 question of knowing what the user 'wants' - in this case the = subscribers=20 wishe's overrule the users wishe's - we know the user wants to reveal = their=20 identity but in this case the user is=20 'SOL'.

...Mark
------=_NextPart_000_00E7_01C1E51E.6964D540-- _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@ns.ietf.org Tue Apr 16 10:04:41 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA05120 for ; Tue, 16 Apr 2002 10:04:40 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id KAA18194 for sip-archive@odin.ietf.org; Tue, 16 Apr 2002 10:04:43 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA12729; Tue, 16 Apr 2002 09:12:12 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA12683 for ; Tue, 16 Apr 2002 09:12:05 -0400 (EDT) Received: from lohi.eng.song.fi (lohi.eng.song.fi [195.10.149.18]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA01528 for ; Tue, 16 Apr 2002 09:12:01 -0400 (EDT) From: jh@lohi.eng.song.fi Received: from harjus.eng.song.fi ([195.10.149.20]) by lohi.eng.song.fi with esmtp (Exim 3.34 #1 (Debian)) id 16xSkY-0004gn-00; Tue, 16 Apr 2002 16:11:58 +0300 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15548.8990.883536.879546@harjus.eng.song.fi> Date: Tue, 16 Apr 2002 16:11:58 +0300 To: "Mark Watson" Cc: "'Ben Campbell'" , "Chiou, Mark" , Dean Willis , Mpierce1@aol.com, sip@ietf.org Subject: RE: Summary of RE: [Sip] Comment, SIP Privacy draft In-Reply-To: References: X-Mailer: VM 7.01 under Emacs 21.1.1 Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit Mark Watson writes: > The subscriber is a company - the company has made a contract with you as > service provider for the provision of the service. > The user is an employee of the company - the user may be 'subscriber' in the > technical sense to your system, but they are not the subscriber as defined > in the definition below - they do not have any contract with you, the > contract is with the company. i don't see how "who pays for the service for a set of users" has any relevance to the privacy discussion. > If you insist on individual contracts with the employees of a company to > which you offer service, then you are equating user and subscriber, but I > doubt the company or its employees would be very happy with this mode of > operation. i do insist individual usernames and passwords. if you do not have that, then there is no way to figure out who made the calls, which is a VERY big problem both for the company and for system in general. -- juha _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@ns.ietf.org Tue Apr 16 10:05:31 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA05178 for ; Tue, 16 Apr 2002 10:05:30 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id KAA18226 for sip-archive@odin.ietf.org; Tue, 16 Apr 2002 10:05:34 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA13870; Tue, 16 Apr 2002 09:24:40 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA13807 for ; Tue, 16 Apr 2002 09:24:33 -0400 (EDT) Received: from bdsl.66.12.12.130.gte.net (bdsl.66.12.12.130.gte.net [66.12.12.130]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA02426; Tue, 16 Apr 2002 09:24:28 -0400 (EDT) Received: from C1893415A (bdsl.greycouncil.com [127.0.0.1]) by bdsl.66.12.12.130.gte.net (8.11.6/8.11.6) with SMTP id g3GDNrd23221; Tue, 16 Apr 2002 08:23:53 -0500 Message-ID: <00af01c1e549$f453caf0$133fed0c@C1893415A> From: "Dean Willis" To: "Rohan Mahy" , , , "James M. Polk" References: <4.1.20020415103657.016784e0@localhost> Subject: Re: [Sip] Re: [Sipping] SIP/SIPPING Interim Meeting Date: Tue, 16 Apr 2002 08:23:53 -0500 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_00AC_01C1E520.0B345DE0" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org This is a multi-part message in MIME format. ------=_NextPart_000_00AC_01C1E520.0B345DE0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable I don't recall whether this has been explicitly mentioned, but the = Pulver SIP Summit occurs in conjunction with Interop. So many of the SIP = people of the world are already in Vegas this week for SIP Summit. We = might as well get together formally. And yes, I was able to book a room at the Riviera, 0.6 miles from the = convention center, for $90 a night, on the web yesterday afternoon. -- Dean ----- Original Message -----=20 From: James M. Polk=20 To: Rohan Mahy ; sip@ietf.org ; sipping@ietf.org=20 Sent: Monday, April 15, 2002 11:10 AM Subject: [Sip] Re: [Sipping] SIP/SIPPING Interim Meeting At 01:39 PM 4/13/2002 -0700, Rohan Mahy wrote: >Hi, > >I'd like to announce a joint SIP/SIPPING interim meeting May 6-7 in = Las >Vegas, Nevada. =20 You chose the week of InterOp Las Vegas, plan on having the meeting = *at* the same location as that convention, and have really confirmed = that there are rooms available at the hotel attached to the convention = center?! Seems even if you've picked a location that does have the room, that = you couldn't have picked a more hectic week or place to have it in = (except maybe CES week in Januarys)... Or was this a plan to have during InterOp? >this date and location were changed (with AD approval) >as a fallback due to conflicts with the previously proposed time and = place >(Boston, the following week). ************************************* "People generally demand more respect for their own rights than they = are willing to allow for others" James M. Polk Consulting Engineer Office of the CTO Cisco Systems 2200 East President George Bush Turnpike=20 Richardson, TX 75082 USA w) 972.813.5208 f) 972.813.5280 www.cisco.com=20 ------=_NextPart_000_00AC_01C1E520.0B345DE0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
I don't recall whether this has been = explicitly=20 mentioned, but the Pulver SIP Summit occurs in conjunction with Interop. = So many=20 of the SIP people of the world are already in Vegas this week for SIP=20 Summit. We might as well get together formally.

And yes, I was able to book a room at = the Riviera,=20 0.6 miles from the convention center, for $90 a night, on the web = yesterday=20 afternoon.

--
Dean

----- Original Message -----
From:=20 James M. = Polk=20

To: Rohan Mahy ; sip@ietf.org ; sipping@ietf.org

Sent: Monday, April 15, 2002 = 11:10=20 AM

Subject: [Sip] Re: [Sipping] = SIP/SIPPING=20 Interim Meeting

At 01:39 PM = 4/13/2002 -0700,=20 Rohan Mahy wrote:
>Hi,
>
>I'd like to announce a = joint=20 SIP/SIPPING interim meeting May 6-7 in Las
>Vegas, Nevada. =

You chose the week of InterOp Las Vegas, plan on having = the=20 meeting *at* the same location as that convention, and have really = confirmed=20 that there are rooms available at the hotel attached to the convention = center?!

Seems even if you've picked a location that does have = the=20 room, that you couldn't have picked a more hectic week or place to = have it in=20 (except maybe CES week in Januarys)...

Or was this a plan to = have=20 during InterOp?

>this date and location were changed (with = AD=20 approval)
>as a fallback due to conflicts with the previously = proposed=20 time and place
>(Boston, the following week).

*************************************
"People = generally=20 demand more respect for their own rights than they are willing to = allow for=20 others"

James M. Polk
Consulting Engineer
Office of = the=20 CTO

Cisco Systems
2200 East President George Bush Turnpike=20
Richardson, TX 75082 USA
w) 972.813.5208
f) =20 972.813.5280
www.cisco.com
------=_NextPart_000_00AC_01C1E520.0B345DE0-- _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@ns.ietf.org Tue Apr 16 10:13:49 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA05569 for ; Tue, 16 Apr 2002 10:13:49 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id KAA18670 for sip-archive@odin.ietf.org; Tue, 16 Apr 2002 10:13:53 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA14653; Tue, 16 Apr 2002 09:30:54 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA14572 for ; Tue, 16 Apr 2002 09:30:46 -0400 (EDT) Received: from bdsl.66.12.12.130.gte.net (bdsl.66.12.12.130.gte.net [66.12.12.130]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA02732; Tue, 16 Apr 2002 09:30:40 -0400 (EDT) Received: from C1893415A (bdsl.greycouncil.com [127.0.0.1]) by bdsl.66.12.12.130.gte.net (8.11.6/8.11.6) with SMTP id g3GDUDd23269; Tue, 16 Apr 2002 08:30:13 -0500 Message-ID: <00b901c1e54a$d6ba51c0$133fed0c@C1893415A> From: "Dean Willis" To: , "Sipping $E-mail$" Date: Tue, 16 Apr 2002 08:30:13 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Content-Transfer-Encoding: 7bit Subject: [Sip] Request: Posting Formats -- Use Plain Text Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit I've noticed a lot of people posting messages in Microsoft Rich Text or MHTML formats. This is painful and hard to reply to, and makes it hard to follow the thread of conversation. And it makes the messages nearly IMPOSSIBLE to read on smaller-format devices. Please: 1) Set your email program up to use plain text if at all possible. There were guidelines for this on IETF Announce last year. 2) Don't just copy in the whole body of a message when you're responding to a small section of it. Just include the relevant text and an attribution to the original author -- like "Dean wrote:". Thanks. -- Dean We could probably dig up the USENET etiquette FAQ if anyone would find that useful. _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@ns.ietf.org Tue Apr 16 10:15:16 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA05612 for ; Tue, 16 Apr 2002 10:15:16 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id KAA18718 for sip-archive@odin.ietf.org; Tue, 16 Apr 2002 10:15:19 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA15370; Tue, 16 Apr 2002 09:34:33 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA15324 for ; Tue, 16 Apr 2002 09:34:25 -0400 (EDT) Received: from zctfs063.nortelnetworks.com (zctfs063.nortelnetworks.com [47.164.128.120]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA03129 for ; Tue, 16 Apr 2002 09:34:04 -0400 (EDT) Received: from zwcwc012.europe.nortel.com (zwcwc012.europe.nortel.com [47.73.112.187]) by zctfs063.nortelnetworks.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id g3GDVQL10170; Tue, 16 Apr 2002 15:31:26 +0200 (MEST) Received: by zwcwc012.europe.nortel.com with Internet Mail Service (5.5.2653.19) id ; Tue, 16 Apr 2002 14:31:26 +0100 Message-ID: From: "Mark Watson" To: "'jh@lohi.eng.song.fi'" Cc: "'Ben Campbell'" , "Chiou, Mark" , Dean Willis , Mpierce1@aol.com, sip@ietf.org Subject: RE: Summary of RE: [Sip] Comment, SIP Privacy draft Date: Tue, 16 Apr 2002 14:31:25 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C1E54B.019456F2" Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C1E54B.019456F2 Content-Type: text/plain Juha wrote: > i don't see how "who pays for the service for a set of users" has any > relevance to the privacy discussion. > Then you should take this up with the European Commission, and other legislative organisations in the rest of the world. The identity of the user is considered by them to (potentially) reveal Personal Data of the subscriber. Personal Data is protected by 'Data Protection' laws which you are free to disobey if you don't mind the fines. [It's not 'who pays', is it who has legally contracted for provision of the service (usually the same person who pays).] > i do insist individual usernames and passwords. if you do not have > that, then there is no way to figure out who made the calls, > which is a > VERY big problem both for the company and for system in general. The requirement is not about usernames, passwords, UAs, SIP, packets, IP, clients, proxies, networks etc. etc. This requirement is about services, service providers, Personal Data, subscribers, users and the protection of their data according to the law. ...Mark ------_=_NextPart_001_01C1E54B.019456F2 Content-Type: text/html Content-Transfer-Encoding: quoted-printable RE: Summary of RE: [Sip] Comment, SIP Privacy draft

Juha wrote:
> i don't see how "who pays for the service = for a set of users" has any
> relevance to the privacy discussion.
>

Then you should take this up with the European = Commission, and other legislative organisations in the rest of the = world.

The identity of the user is considered by them to = (potentially) reveal Personal Data of the subscriber. Personal Data is = protected by 'Data Protection' laws which you are free to disobey if = you don't mind the fines.

[It's not 'who pays', is it who has legally = contracted for provision of the service (usually the same person who = pays).]

> i do insist individual usernames and = passwords. if you do not have
> that, then there is no way to figure out who = made the calls,
> which is a
> VERY big problem both for the company and for = system in general.

The requirement is not about usernames, passwords, = UAs, SIP, packets, IP, clients, proxies, networks etc. etc. This = requirement is about services, service providers, Personal Data, = subscribers, users and the protection of their data according to the = law.

...Mark
------_=_NextPart_001_01C1E54B.019456F2-- _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@ns.ietf.org Tue Apr 16 10:15:35 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA05642 for ; Tue, 16 Apr 2002 10:15:34 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id KAA18750 for sip-archive@odin.ietf.org; Tue, 16 Apr 2002 10:15:38 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA15525; Tue, 16 Apr 2002 09:36:01 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA15494 for ; Tue, 16 Apr 2002 09:35:57 -0400 (EDT) Received: from MHPA8R1C (proxy8.netz.sbs.de [192.35.17.27]) by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA03326 for ; Tue, 16 Apr 2002 09:35:53 -0400 (EDT) From: "Salva Rey Calatayud" To: sip@ietf.org Date: Sun, 16 Apr 2000 15:48:06 +0200 MIME-Version: 1.0 Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: 7BIT Reply-to: salreyca@teleco.upv.es Message-ID: <38F9E0B6.12797.677C4E2@localhost> Priority: normal X-mailer: Pegasus Mail for Win32 (v3.12cDE) X-SMTP-Server: PostCast Server 1.0.0 Content-Transfer-Encoding: 7BIT Subject: [Sip] manyfolks Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7BIT Hi Gonzalo, This is Salva Rey, from Siemens CT in Munich. How are you doing? I wanted to comment you a couple of things about manyfolks. For what I see in manyfolks it seems that two aspects are being defined jointly: 1. QoS capability exchange signalling and interaction with the offer/answer model(through methods and headers) 2. QoS requirements (in SDP fields) Point #1 will be always managed by the UA, but maybe #2 is let to the application... this has never been mentioned, but are we aware of this? will manyfolks provide any support for QoS capability exchange signalling in case that the format for media stream descriptor is other than sdp, let's say here sdpng or xml? my concern is that maybe these two aspects are woven too tightly, and later on manyfolks cannot be used if a format different to sdp is used. regards, Salva _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@ns.ietf.org Tue Apr 16 10:23:34 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA05964 for ; Tue, 16 Apr 2002 10:23:34 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id KAA19262 for sip-archive@odin.ietf.org; Tue, 16 Apr 2002 10:23:38 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA16170; Tue, 16 Apr 2002 09:45:13 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA16136 for ; Tue, 16 Apr 2002 09:45:07 -0400 (EDT) Received: from zctfs063.nortelnetworks.com (zctfs063.nortelnetworks.com [47.164.128.120]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA03917 for ; Tue, 16 Apr 2002 09:45:02 -0400 (EDT) Received: from zwcwc012.europe.nortel.com (zwcwc012.europe.nortel.com [47.73.112.187]) by zctfs063.nortelnetworks.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id g3GDhxL12360; Tue, 16 Apr 2002 15:44:00 +0200 (MEST) Received: by zwcwc012.europe.nortel.com with Internet Mail Service (5.5.2653.19) id ; Tue, 16 Apr 2002 14:43:59 +0100 Message-ID: From: "Mark Watson" To: "'Ben Campbell'" , "Chiou, Mark" , Dean Willis , Mpierce1@aol.com, sip@ietf.org Subject: RE: Summary of RE: [Sip] Comment, SIP Privacy draft Date: Tue, 16 Apr 2002 14:43:49 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C1E54C.BD18090E" Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C1E54C.BD18090E Content-Type: text/plain; charset="iso-8859-1" A 'no anonymous calls' policy would be in breach of the users right to make anonymous calls. It is not the network that is deciding that the user does not mind if the call is anonymous, it is the subscriber, and they have a legal right to do this. The subscribe must be able to control what information the network reveals about them. The user does not have the right to ask the network to reveal information that the subscriber does not want revealed - although the use can of course reveal the information themselves. I was referring to a no anonymous calls policy on the part of the subscriber. I know you were. I no anonymous calls policy on the part of the _subscriber_ would breach the _users_ right to make anonymous calls. Frequent reject-due-to- policy-violation-oops-retry cycles are just unaceptable for wireless environments. There must be a 'works first time' solution. If you think the user needs to be informed that their call has become anonymous, then fine, let's standardise this indication. A wireless network is one in which the network tends to excercise a lot more control over the UA than might be typical for other environments. It this case, the network is likely to be able to push configuration to the phone itself (i.e. the config for "what default privacy option to use". (This of course makes the b2bua changing From headers more feasible as well, as wireless providers tend to have fewer qualms about asserting this level of control.) Indeed. If I have to specify special client behaviour not defined in RFC2543, then I might as well assume bis compliance, and then I can modify From/To without needing to keep state and modify them back on responses - easy. However, my personal view is that we should minimise the requirements on SIP clients in order for them to work on the wireless network. The more wireless-specific requirements or worse, requirements specific to a particular wireless system, then the less SIP clients will be developed for that environment, which is a bad thing. The problem with the 'config push' option is that it makes it hard to develop more complex policies on behalf of the subscriber (e.g. based on destination), because the whole policy is dictated by the flexibility of the configuration that you can push to the user, which is limited by what is standardised. OK, so we could use 'config push' for the regulatory requirement for an 'always anonymous' service, and do more complex things with B2BUAs. But I would like a single solution and anyway you are arguing that From/To modification is NEVER required. ...Mark ------_=_NextPart_001_01C1E54C.BD18090E Content-Type: text/html; charset="iso-8859-1" Message

A 'no anonymous calls' policy would be in breach of the users right to make anonymous calls. It is not the network that is deciding that the user does not mind if the call is anonymous, it is the subscriber, and they have a legal right to do this. The subscribe must be able to control what information the network reveals about them. The user does not have the right to ask the network to reveal information that the subscriber does not want revealed - although the use can of course reveal the information themselves.

I was referring to a no anonymous calls policy on the part of the subscriber.

I know you were. I no anonymous calls policy on the part of the _subscriber_ would breach the _users_ right to make anonymous calls.

Frequent reject-due-to- policy-violation-oops-retry cycles are just unaceptable for wireless environments. There must be a 'works first time' solution. If you think the user needs to be informed that their call has become anonymous, then fine, let's standardise this indication.

A wireless network is one in which the network tends to excercise a lot more control over the UA than might be typical for other environments. It this case, the network is likely to be able to push configuration to the phone itself (i.e. the config for "what default privacy option to use". (This of course makes the b2bua changing From headers more feasible as well, as wireless providers tend to have fewer qualms about asserting this level of control.)

Indeed. If I have to specify special client behaviour not defined in RFC2543, then I might as well assume bis compliance, and then I can modify From/To without needing to keep state and modify them back on responses - easy.

However, my personal view is that we should minimise the requirements on SIP clients in order for them to work on the wireless network. The more wireless-specific requirements or worse, requirements specific to a particular wireless system, then the less SIP clients will be developed for that environment, which is a bad thing.

The problem with the 'config push' option is that it makes it hard to develop more complex policies on behalf of the subscriber (e.g. based on destination), because the whole policy is dictated by the flexibility of the configuration that you can push to the user, which is limited by what is standardised.

OK, so we could use 'config push' for the regulatory requirement for an 'always anonymous' service, and do more complex things with B2BUAs. But I would like a single solution and anyway you are arguing that From/To modification is NEVER required.

...Mark
------_=_NextPart_001_01C1E54C.BD18090E-- _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@ns.ietf.org Tue Apr 16 10:23:36 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA05978 for ; Tue, 16 Apr 2002 10:23:36 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id KAA19245 for sip-archive@odin.ietf.org; Tue, 16 Apr 2002 10:23:36 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA16287; Tue, 16 Apr 2002 09:45:35 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA16227 for ; Tue, 16 Apr 2002 09:45:29 -0400 (EDT) Received: from lohi.eng.song.fi (lohi.eng.song.fi [195.10.149.18]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA03932 for ; Tue, 16 Apr 2002 09:45:24 -0400 (EDT) From: jh@lohi.eng.song.fi Received: from harjus.eng.song.fi ([195.10.149.20]) by lohi.eng.song.fi with esmtp (Exim 3.34 #1 (Debian)) id 16xTGr-0004i9-00; Tue, 16 Apr 2002 16:45:21 +0300 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15548.10993.48769.844163@harjus.eng.song.fi> Date: Tue, 16 Apr 2002 16:45:21 +0300 To: "Mark Watson" Cc: "'Ben Campbell'" , "Chiou, Mark" , Dean Willis , Mpierce1@aol.com, sip@ietf.org Subject: RE: Summary of RE: [Sip] Comment, SIP Privacy draft In-Reply-To: References: X-Mailer: VM 7.01 under Emacs 21.1.1 Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit Mark Watson writes: > The identity of the user is considered by them to (potentially) reveal > Personal Data of the subscriber. Personal Data is protected by 'Data > Protection' laws which you are free to disobey if you don't mind the fines. huh. i have never said that i don't honor someone's privacy wish. > The requirement is not about usernames, passwords, UAs, SIP, packets, IP, > clients, proxies, networks etc. etc. This requirement is about services, > service providers, Personal Data, subscribers, users and the protection of > their data according to the law. fine and i don't have any problem with any of that. the display string does protect the privacy of the user according to his/her wish either on call by call basis or for all calls. -- juha _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@ns.ietf.org Tue Apr 16 10:40:32 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA06521 for ; Tue, 16 Apr 2002 10:40:32 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id KAA20518 for sip-archive@odin.ietf.org; Tue, 16 Apr 2002 10:40:36 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA17424; Tue, 16 Apr 2002 09:59:57 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA17392 for ; Tue, 16 Apr 2002 09:59:52 -0400 (EDT) Received: from zctfs063.nortelnetworks.com (zctfs063.nortelnetworks.com [47.164.128.120]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA04862 for ; Tue, 16 Apr 2002 09:59:43 -0400 (EDT) Received: from zwcwc012.europe.nortel.com (zwcwc012.europe.nortel.com [47.73.112.187]) by zctfs063.nortelnetworks.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id g3GDwID16562; Tue, 16 Apr 2002 15:58:19 +0200 (MEST) Received: by zwcwc012.europe.nortel.com with Internet Mail Service (5.5.2653.19) id ; Tue, 16 Apr 2002 14:58:09 +0100 Message-ID: From: "Mark Watson" To: "'jh@lohi.eng.song.fi'" Cc: "'Ben Campbell'" , "Chiou, Mark" , Dean Willis , Mpierce1@aol.com, sip@ietf.org Subject: RE: Summary of RE: [Sip] Comment, SIP Privacy draft Date: Tue, 16 Apr 2002 14:58:01 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C1E54E.B8FD9B84" Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C1E54E.B8FD9B84 Content-Type: text/plain > fine and i don't have any problem with any of that. the > display string > does protect the privacy of the user according to his/her > wish either on > call by call basis or for all calls. > You have to honour the wishes of the SUBSCRIBER as well. I've explained why, but that does not seem to be not enough for you, so look up the law (97/66/EC) on the EU website (http://www.europa.eu.int/) For clarity, I am not saying that I know this law to be 100% applicable to SIP services - I am not a law court, so I could not do this - I am arguing that it is likely that this or very similar requirements will apply, so we should know how to deal with them. The proposed revision of this document contains considerations about the unsatisfactory situation with respect to email and Data Protection and urges the electronic communications industry to pay more attention to Data Protection. There are fairly explicit 'threats' that if things remain (in their view) unsatisfactory, then further legislative measures will be considered. Paying attention to this stuff at this stage of system development is one way that we *avoid* the need for *more* regulations to be imposed. ...Mark ------_=_NextPart_001_01C1E54E.B8FD9B84 Content-Type: text/html Content-Transfer-Encoding: quoted-printable RE: Summary of RE: [Sip] Comment, SIP Privacy draft

> fine and i don't have any problem with any of = that. the
> display string
> does protect the privacy of the user according = to his/her
> wish either on
> call by call basis or for all calls.
>

You have to honour the wishes of the SUBSCRIBER as = well. I've explained why, but that does not seem to be not enough for = you, so look up the law (97/66/EC) on the EU website (http://www.europa.eu.int/)

For clarity, I am not saying that I know this law to = be 100% applicable to SIP services - I am not a law court, so I could = not do this - I am arguing that it is likely that this or very similar = requirements will apply, so we should know how to deal with = them.

The proposed revision of this document contains = considerations about the unsatisfactory situation with respect to email = and Data Protection and urges the electronic communications industry to = pay more attention to Data Protection. There are fairly explicit = 'threats' that if things remain (in their view) unsatisfactory, then = further legislative measures will be considered.

Paying attention to this stuff at this stage of = system development is one way that we *avoid* the need for *more* = regulations to be imposed.

...Mark
------_=_NextPart_001_01C1E54E.B8FD9B84-- _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@ns.ietf.org Tue Apr 16 10:43:18 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA06670 for ; Tue, 16 Apr 2002 10:43:18 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id KAA20722 for sip-archive@odin.ietf.org; Tue, 16 Apr 2002 10:43:22 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA18397; Tue, 16 Apr 2002 10:08:14 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA18360 for ; Tue, 16 Apr 2002 10:08:09 -0400 (EDT) Received: from sj-msg-core-2.cisco.com (sj-msg-core-2.cisco.com [171.69.24.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA05353 for ; Tue, 16 Apr 2002 10:08:05 -0400 (EDT) Received: from mira-sjc5-9.cisco.com (IDENT:mirapoint@mira-sjc5-9.cisco.com [171.71.163.32]) by sj-msg-core-2.cisco.com (8.12.2/8.12.2) with ESMTP id g3GE7a9C019669; Tue, 16 Apr 2002 07:07:36 -0700 (PDT) Received: from OranLT ([161.44.238.53]) by mira-sjc5-9.cisco.com (Mirapoint) with ESMTP id ACQ54793; Tue, 16 Apr 2002 07:07:46 -0700 (PDT) From: "David R. Oran" To: "'Mark Watson'" , Subject: RE: Summary of RE: [Sip] Comment, SIP Privacy draft Date: Tue, 16 Apr 2002 09:59:59 -0400 Organization: Cisco Systems Message-ID: <006901c1e54f$000af620$35ee2ca1@OranLT> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.3416 In-Reply-To: Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit Mark, I must admit that I am not following at all what you are saying. As far as I know, the privacy laws and regulations are meant to protect personal information disclosed by the person *to his service provider*, either via the act of subscribing, and/or by the act of invoking the service. I think that the vast majority of the information the user puts in SIP messages (either header or body) are no more "information disclosed to the service provider" than the contents of files he FTPs, or dirty pictures in a jpeg MIME body. They are information disclosed TO THE RECIPIENT, which the service provider just happens to see going by, or acts on to provide services for the user. If it were required that the service provider not disclose this information, they'd all be getting sued for not encrypting all the traffic going by. The exception are things specifically for the consumption of the service provider, such as proxy-authenticate tokens and the like. I think the information that is of relevance to this discussion is stuff that was *NOT* inserted by the user, but was instead inserted by the service provider based on things the user had previously disclosed to the service provider. These are the things which in fact do need some level of protection, which is why we have this complicated applicability statement on the privacy draft and why (I at least) would argue that the only reasonable design is one in which any identifying information inserted by the service provider be encrypted or otherwise protected from disclosure to other parties (including the callee) unless the customer explicitly requests it not to be. This last, is of course, just a matter of the default setting of the privacy: header, which can be handled by default UA configuration and need not be the subject of protocol standardization. Dave. -----Original Message----- From: sip-admin@ietf.org [mailto:sip-admin@ietf.org] On Behalf Of Mark Watson Sent: Tuesday, April 16, 2002 9:31 AM To: 'jh@lohi.eng.song.fi' Cc: 'Ben Campbell'; Chiou, Mark; Dean Willis; Mpierce1@aol.com; sip@ietf.org Subject: RE: Summary of RE: [Sip] Comment, SIP Privacy draft Juha wrote: > i don't see how "who pays for the service for a set of users" has any > relevance to the privacy discussion. > Then you should take this up with the European Commission, and other legislative organisations in the rest of the world. The identity of the user is considered by them to (potentially) reveal Personal Data of the subscriber. Personal Data is protected by 'Data Protection' laws which you are free to disobey if you don't mind the fines. [It's not 'who pays', is it who has legally contracted for provision of the service (usually the same person who pays).] > i do insist individual usernames and passwords. if you do not have > that, then there is no way to figure out who made the calls, > which is a > VERY big problem both for the company and for system in general. The requirement is not about usernames, passwords, UAs, SIP, packets, IP, clients, proxies, networks etc. etc. This requirement is about services, service providers, Personal Data, subscribers, users and the protection of their data according to the law. ...Mark _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@ns.ietf.org Tue Apr 16 11:41:15 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA08585 for ; Tue, 16 Apr 2002 11:41:15 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id LAA24123 for sip-archive@odin.ietf.org; Tue, 16 Apr 2002 11:41:19 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA21756; Tue, 16 Apr 2002 11:02:05 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA21712 for ; Tue, 16 Apr 2002 11:01:58 -0400 (EDT) Received: from magus.nostrum.com (root@magus.nostrum.com [66.119.225.66]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA07360 for ; Tue, 16 Apr 2002 11:01:53 -0400 (EDT) Received: from txbcampbell (root@magus.nostrum.com [66.119.225.66]) by magus.nostrum.com (8.11.0/8.11.0) with SMTP id g3GF1qX53316; Tue, 16 Apr 2002 10:01:52 -0500 (CDT) From: "Ben Campbell" To: "Dean Willis" , Cc: , , Date: Tue, 16 Apr 2002 10:01:30 -0500 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) In-Reply-To: <006301c1e256$946cfd00$0100a8c0@TXDWILLIS2> Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Content-Transfer-Encoding: 7bit Subject: [Sip] Closure on Message draft? (was RE: Correction:SIP Message Draft Fast WGLC) Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit As of this morning, the only feedback I have on the message draft is some nits from Rohan. Are we done? If I don't get additional negative feedback by midnight tonight (CDT), I will cut a new release fixing the nits, and recommend we send it to the IESG for IETF last call. > -----Original Message----- > From: Dean Willis [mailto:dean.willis@softarmor.com] > Sent: Friday, April 12, 2002 2:17 PM > To: sip@ietf.org > Cc: brian.rosen@maroni.com; rohan@cisco.com; jo@ipdialog.com; > bcampbell@dynamicsoft.com > Subject: Correction:SIP Message Draft Fast WGLC > > > > Oops. > > Please review : > > http://www.softarmor.com/sipwg/drafts/draft-ietf-sip-message-02.txt > > Until the -02 makes it into the draft repository. They're not as fast as > I'm wishing for (ok, light speed is too slow, while we're at it!) > > Thanks, > > -- > Dean > > > Original message: > ------------- > We need to quickly review the SIM Message Method Extension. This draft > has been widely discussed, iterated several times in SIMPLE, and is on > its 2nd revision in SIP. The draft does not appear to be controversial. > > See: > > http://search.ietf.org/internet-drafts/draft-ietf-sip-message-01.txt > > We expect to move to IETF last call next week, so please raise any > issues immediately. > > Ben Campbell will coordinate for the draft editors. > > ----------------- _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@ns.ietf.org Tue Apr 16 12:19:30 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA13694 for ; Tue, 16 Apr 2002 12:19:30 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id MAA27074 for sip-archive@odin.ietf.org; Tue, 16 Apr 2002 12:19:35 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA21077; Tue, 16 Apr 2002 10:51:46 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA21043 for ; Tue, 16 Apr 2002 10:51:42 -0400 (EDT) Received: from imo-d01.mx.aol.com (imo-d01.mx.aol.com [205.188.157.33]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA07054 for ; Tue, 16 Apr 2002 10:51:37 -0400 (EDT) From: Mpierce1@aol.com Received: from Mpierce1@aol.com by imo-d01.mx.aol.com (mail_out_v32.5.) id c.12f.fe535f3 (4207); Tue, 16 Apr 2002 10:50:46 -0400 (EDT) Message-ID: <12f.fe535f3.29ed9446@aol.com> Date: Tue, 16 Apr 2002 10:50:46 EDT Subject: Re: Summary of RE: [Sip] Comment, SIP Privacy draft To: oran@cisco.com, mwatson@nortelnetworks.com, sip@ietf.org MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="part1_12f.fe535f3.29ed9446_boundary" X-Mailer: AOL 6.0 for Windows US sub 10524 Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org --part1_12f.fe535f3.29ed9446_boundary Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit In a message dated 4/16/02 10:09:55 AM Eastern Daylight Time, oran@cisco.com writes: > I think the information that is of relevance to this discussion is stuff > that was *NOT* inserted by the user, but was instead inserted by the > service provider based on things the user had previously disclosed to > the service provider. These are the things which in fact do need some > level of protection, which is why we have this complicated applicability > statement on the privacy draft and why (I at least) would argue that the > only reasonable design is one in which any identifying information > inserted by the service provider be encrypted or otherwise protected > from disclosure to other parties (including the callee) unless the > customer explicitly requests it not to be. > > I think you have to add to the first sentence above "and information inserted by the user that is required by the Service Provider as a prerequisite for service". If the service provider requires that the user enter a valid ID, then it must be protected the same as an ID that the Service Provider inserted. Mike --part1_12f.fe535f3.29ed9446_boundary Content-Type: text/html; charset="US-ASCII" Content-Transfer-Encoding: 7bit In a message dated 4/16/02 10:09:55 AM Eastern Daylight Time, oran@cisco.com writes:

I think the information that is of relevance to this discussion is stuff
that was *NOT* inserted by the user, but was instead inserted by the
service provider based on things the user had previously disclosed to
the service provider. These are the things which in fact do need some
level of protection, which is why we have this complicated applicability
statement on the privacy draft and why (I at least) would argue that the
only reasonable design is one in which any identifying information
inserted by the service provider be encrypted or otherwise protected
from disclosure to other parties (including the callee) unless the
customer explicitly requests it not to be.

I think you have to add to the first sentence above "and information inserted by the user that is required by the Service Provider as a prerequisite for service". If the service provider requires that the user enter a valid ID, then it must be protected the same as an ID that the Service Provider inserted.

Mike
--part1_12f.fe535f3.29ed9446_boundary-- _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@ns.ietf.org Tue Apr 16 12:52:53 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA18652 for ; Tue, 16 Apr 2002 12:52:53 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id MAA29052 for sip-archive@odin.ietf.org; Tue, 16 Apr 2002 12:52:56 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA27059; Tue, 16 Apr 2002 12:18:44 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA27029 for ; Tue, 16 Apr 2002 12:18:40 -0400 (EDT) Received: from zctfs063.nortelnetworks.com (zctfs063.nortelnetworks.com [47.164.128.120]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA13601 for ; Tue, 16 Apr 2002 12:18:33 -0400 (EDT) Received: from znsgs01r.europe.nortel.com (znsgs01r.europe.nortel.com [47.137.129.92]) by zctfs063.nortelnetworks.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id g3GGI5D20793; Tue, 16 Apr 2002 18:18:05 +0200 (MEST) Received: from zwcwc012.europe.nortel.com (zwcwc012.europe.nortel.com [47.73.112.187]) by znsgs01r.europe.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id g3GGHQH14886; Tue, 16 Apr 2002 17:17:26 +0100 (BST) Received: by zwcwc012.europe.nortel.com with Internet Mail Service (5.5.2653.19) id ; Tue, 16 Apr 2002 17:18:03 +0100 Message-ID: From: "Mark Watson" To: "'David R. Oran'" , sip@ietf.org Subject: RE: Summary of RE: [Sip] Comment, SIP Privacy draft Date: Tue, 16 Apr 2002 17:17:54 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C1E562.43BAC496" Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C1E562.43BAC496 Content-Type: text/plain Dave, I agree entirely with what you have written below, with three clarifications: 1) If the user is *required* by the Service Provider to insert certain information, then, for this discussion, it is the same as the Service Provider inserting it - i.e. it doesn't matter which piece of physical equipment inserts it if the information *has to be there* for the service to work. In Juha's service the From field is like this, because unless you put in 'anonymous' you MUST put your correct identity. 2) We must consider the *subscriber's* privacy request as well as the user's. The subscriber may be a *different person* from the user. Either we have to automatically get the subscriber's privacy policy to the UA, or the network has to modify the fields which were network inserted, or inserted by the user 'on behalf of' the network as per (1) 3) Personally, I go further than (1) and argue that information *expected* (but not strictly *required*) by the Service Provider has similar status. The SHOULD in the SIP spec wrt the contents of From/To is enough to mean that a credible subscriber anonymity service should consider these fields. So, my argument is that EITHER modification of the From/To fields may be required in the network OR standardisation is required to reliably get the subscriber's policy to the UA & deal with other similar problems. To date I've seen no credible proposals for the latter, so I'm arguing we should assume the former. **The effect for the IETF SIP group** is only that it becomes a 'non-assumption' that the From/To fields are immutable within the network. Future capabilities should be designed with this non-assumption wherever possible, so that they are not broken by devices which do this. This is all I am arguing about. There will, of course, be some services which *are* broken by such devices. ...Mark > -----Original Message----- > From: David R. Oran [mailto:oran@cisco.com] > Sent: 16 April 2002 15:00 > To: Watson, Mark [MDN05:EP10:EXCH]; sip@ietf.org > Subject: RE: Summary of RE: [Sip] Comment, SIP Privacy draft > > > Mark, > > I must admit that I am not following at all what you are > saying. As far > as I know, the privacy laws and regulations are meant to protect > personal information disclosed by the person *to his service > provider*, > either via the act of subscribing, and/or by the act of invoking the > service. > > I think that the vast majority of the information the user puts in SIP > messages (either header or body) are no more "information disclosed to > the service provider" than the contents of files he FTPs, or dirty > pictures in a jpeg MIME body. They are information disclosed TO THE > RECIPIENT, which the service provider just happens to see going by, or > acts on to provide services for the user. If it were required that the > service provider not disclose this information, they'd all be getting > sued for not encrypting all the traffic going by. The exception are > things specifically for the consumption of the service > provider, such as > proxy-authenticate tokens and the like. > > I think the information that is of relevance to this > discussion is stuff > that was *NOT* inserted by the user, but was instead inserted by the > service provider based on things the user had previously disclosed to > the service provider. These are the things which in fact do need some > level of protection, which is why we have this complicated > applicability > statement on the privacy draft and why (I at least) would > argue that the > only reasonable design is one in which any identifying information > inserted by the service provider be encrypted or otherwise protected > from disclosure to other parties (including the callee) unless the > customer explicitly requests it not to be. > > This last, is of course, just a matter of the default setting of the > privacy: header, which can be handled by default UA configuration and > need not be the subject of protocol standardization. > > Dave. > > > -----Original Message----- > From: sip-admin@ietf.org [mailto:sip-admin@ietf.org] On Behalf Of Mark > Watson > Sent: Tuesday, April 16, 2002 9:31 AM > To: 'jh@lohi.eng.song.fi' > Cc: 'Ben Campbell'; Chiou, Mark; Dean Willis; Mpierce1@aol.com; > sip@ietf.org > Subject: RE: Summary of RE: [Sip] Comment, SIP Privacy draft > > > > > Juha wrote: > > i don't see how "who pays for the service for a set of > users" has any > > relevance to the privacy discussion. > > > Then you should take this up with the European Commission, and other > legislative organisations in the rest of the world. > The identity of the user is considered by them to (potentially) reveal > Personal Data of the subscriber. Personal Data is protected by 'Data > Protection' laws which you are free to disobey if you don't mind the > fines. > [It's not 'who pays', is it who has legally contracted for > provision of > the service (usually the same person who pays).] > > i do insist individual usernames and passwords. if you do not have > > that, then there is no way to figure out who made the calls, > > which is a > > VERY big problem both for the company and for system in general. > The requirement is not about usernames, passwords, UAs, SIP, packets, > IP, clients, proxies, networks etc. etc. This requirement is about > services, service providers, Personal Data, subscribers, users and the > protection of their data according to the law. > ...Mark > > ------_=_NextPart_001_01C1E562.43BAC496 Content-Type: text/html Content-Transfer-Encoding: quoted-printable RE: Summary of RE: [Sip] Comment, SIP Privacy draft
Dave,

I agree entirely with what you have written below, = with three clarifications:

1) If the user is *required* by the Service Provider = to insert certain information, then, for this discussion, it is the = same as the Service Provider inserting it - i.e. it doesn't matter = which piece of physical equipment inserts it if the information *has to = be there* for the service to work. In Juha's service the From field is = like this, because unless you put in 'anonymous' you MUST put your = correct identity.

2) We must consider the *subscriber's* privacy = request as well as the user's. The subscriber may be a *different = person* from the user. Either we have to automatically get the = subscriber's privacy policy to the UA, or the network has to modify the = fields which were network inserted, or inserted by the user 'on behalf = of' the network as per (1)

3) Personally, I go further than (1) and argue that = information *expected* (but not strictly *required*) by the Service = Provider has similar status. The SHOULD in the SIP spec wrt the = contents of From/To is enough to mean that a credible subscriber = anonymity service should consider these fields.

So, my argument is that EITHER modification of the = From/To fields may be required in the network OR standardisation is = required to reliably get the subscriber's policy to the UA & deal = with other similar problems.

To date I've seen no credible proposals for the = latter, so I'm arguing we should assume the former.

**The effect for the IETF SIP group** is only that it = becomes a 'non-assumption' that the From/To fields are immutable within = the network. Future capabilities should be designed with this = non-assumption wherever possible, so that they are not broken by = devices which do this. This is all I am arguing about.

There will, of course, be some services which *are* = broken by such devices.

...Mark

> -----Original Message-----
> From: David R. Oran [mailto:oran@cisco.com]
> Sent: 16 April 2002 15:00
> To: Watson, Mark [MDN05:EP10:EXCH]; = sip@ietf.org
> Subject: RE: Summary of RE: [Sip] Comment, SIP = Privacy draft
>
>
> Mark,
>
> I must admit that I am not following at all = what you are
> saying. As far
> as I know, the privacy laws and regulations are = meant to protect
> personal information disclosed by the person = *to his service
> provider*,
> either via the act of subscribing, and/or by = the act of invoking the
> service.
>
> I think that the vast majority of the = information the user puts in SIP
> messages (either header or body) are no more = "information disclosed to
> the service provider" than the contents of = files he FTPs, or dirty
> pictures in a jpeg MIME body. They are = information disclosed TO THE
> RECIPIENT, which the service provider just = happens to see going by, or
> acts on to provide services for the user. If it = were required that the
> service provider not disclose this information, = they'd all be getting
> sued for not encrypting all the traffic going = by. The exception are
> things specifically for the consumption of the = service
> provider, such as
> proxy-authenticate tokens and the like.
>
> I think the information that is of relevance to = this
> discussion is stuff
> that was *NOT* inserted by the user, but was = instead inserted by the
> service provider based on things the user had = previously disclosed to
> the service provider. These are the things = which in fact do need some
> level of protection, which is why we have this = complicated
> applicability
> statement on the privacy draft and why (I at = least) would
> argue that the
> only reasonable design is one in which any = identifying information
> inserted by the service provider be encrypted = or otherwise protected
> from disclosure to other parties (including the = callee) unless the
> customer explicitly requests it not to = be.
>
> This last, is of course, just a matter of the = default setting of the
> privacy: header, which can be handled by = default UA configuration and
> need not be the subject of protocol = standardization.
>
> Dave.
>
>
> -----Original Message-----
> From: sip-admin@ietf.org [mailto:sip-admin@ietf.org] On = Behalf Of Mark
> Watson
> Sent: Tuesday, April 16, 2002 9:31 AM
> To: 'jh@lohi.eng.song.fi'
> Cc: 'Ben Campbell'; Chiou, Mark; Dean Willis; = Mpierce1@aol.com;
> sip@ietf.org
> Subject: RE: Summary of RE: [Sip] Comment, SIP = Privacy draft
>
>
>
>
> Juha wrote:
> > i don't see how "who pays for the = service for a set of
> users" has any
> > relevance to the privacy discussion. =
> >
> Then you should take this up with the European = Commission, and other
> legislative organisations in the rest of the = world.
> The identity of the user is considered by them = to (potentially) reveal
> Personal Data of the subscriber. Personal Data = is protected by 'Data
> Protection' laws which you are free to disobey = if you don't mind the
> fines.
> [It's not 'who pays', is it who has legally = contracted for
> provision of
> the service (usually the same person who = pays).]
> > i do insist individual usernames and = passwords. if you do not have
> > that, then there is no way to figure out = who made the calls,
> > which is a
> > VERY big problem both for the company and = for system in general.
> The requirement is not about usernames, = passwords, UAs, SIP, packets,
> IP, clients, proxies, networks etc. etc. This = requirement is about
> services, service providers, Personal Data, = subscribers, users and the
> protection of their data according to the = law.
> ...Mark
>
>
------_=_NextPart_001_01C1E562.43BAC496-- _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@ns.ietf.org Tue Apr 16 13:48:02 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA25418 for ; Tue, 16 Apr 2002 13:48:01 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id NAA02326 for sip-archive@odin.ietf.org; Tue, 16 Apr 2002 13:48:03 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA00772; Tue, 16 Apr 2002 13:23:11 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA00741 for ; Tue, 16 Apr 2002 13:23:07 -0400 (EDT) Received: from bdsl.66.12.12.130.gte.net (bdsl.66.12.12.130.gte.net [66.12.12.130]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA22275 for ; Tue, 16 Apr 2002 13:23:05 -0400 (EDT) Received: from TXDWILLIS2 (bdsl.greycouncil.com [127.0.0.1]) by bdsl.66.12.12.130.gte.net (8.11.6/8.11.6) with ESMTP id g3GHLLd25014; Tue, 16 Apr 2002 12:21:21 -0500 From: "Dean Willis" To: , , , Subject: RE: Summary of RE: [Sip] Comment, SIP Privacy draft Date: Tue, 16 Apr 2002 12:21:10 -0500 Message-ID: <002f01c1e56b$1ac87250$bb036e3f@TXDWILLIS2> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.3416 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 In-Reply-To: <12f.fe535f3.29ed9446@aol.com> Importance: Normal Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit In a message dated 4/16/02 10:09:55 AM Eastern Daylight Time, oran@cisco.com writes: --------- I think the information that is of relevance to this discussion is stuff that was *NOT* inserted by the user, but was instead inserted by the service provider based on things the user had previously disclosed to the service provider. These are the things which in fact do need some level of protection, which is why we have this complicated applicability statement on the privacy draft and why (I at least) would argue that the only reasonable design is one in which any identifying information inserted by the service provider be encrypted or otherwise protected from disclosure to other parties (including the callee) unless the customer explicitly requests it not to be. __________ I think Dave's generally right, with the one caveat noted by Mark below: And Mark responded: ------------------ I think you have to add to the first sentence above "and information inserted by the user that is required by the Service Provider as a prerequisite for service". If the service provider requires that the user enter a valid ID, then it must be protected the same as an ID that the Service Provider inserted. ------------------ I agree mostly with Mark here -- which is why I'm continuing to push back on an approach that "requires" the From: field to be specific user-identifying information or suggests that it is more significant than a "display name" which might optionally be used by some nodes for some sort of lightweight filtering and displayed at the end point. From bis: ----- 8.1.1.3 From The From header field indicates the logical identity of the initiator of the request, possibly the user's address-of-record. Like the To header field, it contains a URI and optionally a display name. It is used by SIP elements to determine which processing rules to apply to a request (for example, automatic call rejection). As such, it is very important that the From URI not contain IP addresses or the FQDN of the host on which the UA is running, since these are not logical names. The From header field allows for a display name. A UAC SHOULD use the display name "Anonymous", along with a syntactically correct, but otherwise meaningless URI (like sip:thisis@anonymous.invalid), if the identity of the client is to remain hidden. ----- Note that the strongest requirements statement about usage here is a "SHOULD" class statement on anonymity, and guidelines include "possibly the user's address-of-record" on content in general. The SIP spec does NOT mandate that the From field: contain any specific information. This is in some measure intended to prevent the regulatoryistic (I just made that up) abuse of the field. Let us also consider the phrase "very important that the From URI not contain IP addresses or the FQDN of the host on which the UA is running, since these are not logical names." This clearly indicates that the From field is intended to provide a LOGICAL reference, not a DIRECT reference. "Logical" is a broad term, and implies that the field should be completed in a manner logically consistent with the role in which the completor expects to use that field or have that field used by target nodes. -- Dean _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@ns.ietf.org Tue Apr 16 14:33:38 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA00427 for ; Tue, 16 Apr 2002 14:33:38 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id OAA05809 for sip-archive@odin.ietf.org; Tue, 16 Apr 2002 14:33:40 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA04144; Tue, 16 Apr 2002 14:05:04 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA04109 for ; Tue, 16 Apr 2002 14:04:54 -0400 (EDT) Received: from zctfs063.nortelnetworks.com (zctfs063.nortelnetworks.com [47.164.128.120]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA27376 for ; Tue, 16 Apr 2002 14:04:51 -0400 (EDT) Received: from znsgs01r.europe.nortel.com (znsgs01r.europe.nortel.com [47.137.129.92]) by zctfs063.nortelnetworks.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id g3GI4LD12932; Tue, 16 Apr 2002 20:04:22 +0200 (MEST) Received: from zwcwc012.europe.nortel.com (zwcwc012.europe.nortel.com [47.73.112.187]) by znsgs01r.europe.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id g3GI3hH26298; Tue, 16 Apr 2002 19:03:44 +0100 (BST) Received: by zwcwc012.europe.nortel.com with Internet Mail Service (5.5.2653.19) id ; Tue, 16 Apr 2002 19:04:20 +0100 Message-ID: From: "Mark Watson" To: "'Dean Willis'" , Mpierce1@aol.com, oran@cisco.com, sip@ietf.org Subject: RE: Summary of RE: [Sip] Comment, SIP Privacy draft Date: Tue, 16 Apr 2002 19:04:19 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C1E571.212B6322" Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C1E571.212B6322 Content-Type: text/plain Dean wrote > From bis: > > ----- > 8.1.1.3 From The From header field ... > It is used by SIP elements to determine which processing rules > to apply to a request (for example, automatic call rejection).... > ----- > > Note that the strongest requirements statement about usage here is a > "SHOULD" class statement on anonymity, and guidelines include > "possibly > the user's address-of-record" on content in general. The SIP spec does > NOT mandate that the From field: contain any specific > information. This > is in some measure intended to prevent the regulatoryistic (I > just made > that up) abuse of the field. It doesn't mandate, sure, but the *implication* is important. The fact that it might be used for services, processing rules, etc., gives (some) people a strong feeling that it ought to be accurate. Of course, on the Internet, no one can hear you scream 'you lied about your identity!' In a Service Provider environment people have different expectations, which is why even SHOULD level requirements like that above lead to a feeling that the Service Provider must check the value of the field. ...Mark ------_=_NextPart_001_01C1E571.212B6322 Content-Type: text/html Content-Transfer-Encoding: quoted-printable RE: Summary of RE: [Sip] Comment, SIP Privacy draft

Dean wrote
> From bis:
>
> -----
> 8.1.1.3 From The From header field ...
> It is used by SIP elements to determine which = processing rules
> to apply to a request (for example, automatic = call rejection)....
> -----
>
> Note that the strongest requirements statement = about usage here is a
> "SHOULD" class statement on = anonymity, and guidelines include
> "possibly
> the user's address-of-record" on content = in general. The SIP spec does
> NOT mandate that the From field: contain any = specific
> information. This
> is in some measure intended to prevent the = regulatoryistic (I
> just made
> that up) abuse of the field.

It doesn't mandate, sure, but the *implication* is = important. The fact that it might be used for services, processing = rules, etc., gives (some) people a strong feeling that it ought to be = accurate.

Of course, on the Internet, no one can hear you = scream 'you lied about your identity!'

In a Service Provider environment people have = different expectations, which is why even SHOULD level requirements = like that above lead to a feeling that the Service Provider must check = the value of the field.

...Mark
------_=_NextPart_001_01C1E571.212B6322-- _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@ns.ietf.org Tue Apr 16 15:07:00 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA05104 for ; Tue, 16 Apr 2002 15:07:00 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id PAA07828 for sip-archive@odin.ietf.org; Tue, 16 Apr 2002 15:07:02 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA06126; Tue, 16 Apr 2002 14:39:36 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA06095 for ; Tue, 16 Apr 2002 14:39:32 -0400 (EDT) Received: from cs.columbia.edu (cs.columbia.edu [128.59.16.20]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA01136 for ; Tue, 16 Apr 2002 14:39:25 -0400 (EDT) Received: from opus.cs.columbia.edu (opus.cs.columbia.edu [128.59.20.100]) by cs.columbia.edu (8.9.3/8.9.3) with ESMTP id OAA10047; Tue, 16 Apr 2002 14:39:17 -0400 (EDT) Received: from cs.columbia.edu (slip-32-102-22-19.md.us.prserv.net [32.102.22.19]) (authenticated bits=0) by opus.cs.columbia.edu (8.12.1/8.12.1) with ESMTP id g3GIdBPm000859 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Tue, 16 Apr 2002 14:39:14 -0400 (EDT) Message-ID: <3CBC6FA2.8D3277A7@cs.columbia.edu> Date: Tue, 16 Apr 2002 14:38:26 -0400 From: Henning Schulzrinne Organization: Columbia University X-Mailer: Mozilla 4.76 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Mpierce1@aol.com CC: oran@cisco.com, mwatson@nortelnetworks.com, sip@ietf.org Subject: Re: Summary of RE: [Sip] Comment, SIP Privacy draft References: <12f.fe535f3.29ed9446@aol.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit > I think the information that is of relevance to this discussion is stuff > that was *NOT* inserted by the user, but was instead inserted by the > service provider based on things the user had previously disclosed to > the service provider. These are the things which in fact do need some > level of protection, which is why we have this complicated applicability > statement on the privacy draft and why (I at least) would argue that the > only reasonable design is one in which any identifying information > inserted by the service provider be encrypted or otherwise protected > from disclosure to other parties (including the callee) unless the > customer explicitly requests it not to be. > > > > I think you have to add to the first sentence above "and information inserted by the user that is required by the > Service Provider as a prerequisite for service". If the service provider requires that the user enter a valid ID, then it > must be protected the same as an ID that the Service Provider inserted. No reasonable provider should put that requirement on From, for the reasons Dean mentioned. This leaves the proxy-authentication data. Interesting question is whether the proxy-authentication data needs to be stripped after it has been "used", as it may well apply to several down-stream proxies. _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@ns.ietf.org Tue Apr 16 15:40:46 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA08942 for ; Tue, 16 Apr 2002 15:40:45 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id PAA10103 for sip-archive@odin.ietf.org; Tue, 16 Apr 2002 15:40:48 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA08566; Tue, 16 Apr 2002 15:17:44 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA05677 for ; Tue, 16 Apr 2002 14:32:45 -0400 (EDT) Received: from webmail3.rediffmail.com (webmail3.rediffmail.com [202.54.124.148] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA00329 for ; Tue, 16 Apr 2002 14:32:42 -0400 (EDT) Received: (qmail 5606 invoked by uid 510); 16 Apr 2002 18:33:08 -0000 Date: 16 Apr 2002 18:33:08 -0000 Message-ID: <20020416183308.5605.qmail@webmail3.rediffmail.com> Received: from unknown (152.1.214.14) by rediffmail.com via HTTP; 16 Apr 2002 18:33:08 -0000 MIME-Version: 1.0 From: "ruhiya mahalati" Reply-To: "ruhiya mahalati" To: sip@ietf.org Content-type: text/plain; format=flowed Content-Disposition: inline Subject: [Sip] SIP protocol failure scenarios Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Hi, I am a graduate student and am working on the control memory, design and proof of correctness for SIP as my course project. I had a few doubts and would be grateful if anyone could answer them. 1: How is a duplicate BYE or a CANCEL generated, is it at timeout or only whenever the application requests? 2: Are there any cases may be because of lost messages or delayed or incorrect messages which may result in the failure of the protocol ie exceptional cases which the protocol is not capable of handling. 3:CSEQ feild is incremented for each request within a dialog.Is it increased for the responses also? and will the retansmission of a request contain the same CSEQ value or an incremented one? thanks and regards, ruhiya _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Tue Apr 16 21:08:43 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA15086 for ; Tue, 16 Apr 2002 21:08:42 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id VAA25133 for sip-archive@odin.ietf.org; Tue, 16 Apr 2002 21:08:46 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id UAA23778; Tue, 16 Apr 2002 20:42:14 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id UAA23747 for ; Tue, 16 Apr 2002 20:42:09 -0400 (EDT) Received: from sj-msg-core-2.cisco.com (sj-msg-core-2.cisco.com [171.69.24.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA12525 for ; Tue, 16 Apr 2002 20:42:05 -0400 (EDT) Received: from imop.cisco.com (IDENT:mirapoint@imop.cisco.com [171.69.11.44]) by sj-msg-core-2.cisco.com (8.12.2/8.12.2) with ESMTP id g3H0fT9C018592; Tue, 16 Apr 2002 17:41:29 -0700 (PDT) Received: from localhost (ssh-sjc-1.cisco.com [171.68.225.134]) by imop.cisco.com (Mirapoint) with ESMTP id ACV93688; Tue, 16 Apr 2002 17:41:27 -0700 (PDT) Date: Tue, 16 Apr 2002 17:38:33 -0700 (Pacific Daylight Time) From: Rohan Mahy To: Mark Watson cc: "'jh@lohi.eng.song.fi'" , "'Ben Campbell'" , "Chiou, Mark" , Dean Willis , , Subject: RE: Summary of RE: [Sip] Comment, SIP Privacy draft In-Reply-To: Message-ID: X-X-Sender: rmahy@imop.cisco.com MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Mark, I have a real problem with the way you have defined or envisioned a privacy service. Please see below... On Tue, 16 Apr 2002, Mark Watson wrote: > The client capability issue was for the case where the user does not wish to > remain anonymous, but the subscriber does. > > Without a network modification of the From field then: > > 1) The user includes their identity, and the session is rejected. There is > no reject code which clearly indicates what action the user/UA should take. > There will be no current UAs which would know to auto-retry with > 'Anonymous', so this will require user intervention on all calls. > Auto-retrys are no good for wireless anyway. > > 2) It was suggested that the client should have a 'always anonymous' option > which the user can set, so that all calls via this subscription will be > anonymous. Again, current clients may or may not have this, so relying on > this to provide the 'subscriber anonymity' service without the retrys of (1) > is not such a good idea unless you have clearly told subscribers - before > they subscribe - that such a capability is needed. > > Service Providers need to be well aware of the client capabilities needed to > implement the regulatory services they have to provide, so that they can > make it clear to potential subscribers what those required client > capabilities are. > > Even so, I really can't see all the above being realistic. Imagine a > subscriber goes to their service provider and requests anonymity. A user who wants privacy of their self-revealed information has two very reasonable choices, both of which are possible using baseline SIP (either 2543 or 3261). Note that this is a very separate problem from network-asserted identity used for PSTN interop, call trace, and call return services. 1) The subscriber can configure their user agent not to reveal most types of private information. 2) A provider can insert an anonymizing B2BUA (with or without media anonymity) into the signaling path before forwarding outside its network. I do not buy the argument that we need the network to provide this service, but that it is somehow a burden for the network to implement this service using a B2BUA. thanks, -rohan > The first > thing that happens is that all calls through the subscription start failing > with some 'Privacy violation' response code. 'Oh sorry,' says the Service > Provider, 'but you asked for all calls to be anonymous and then carried on > trying to make non-anonymous calls. You'll need to tell all the users to > change their settings to anonymous'. > > Whilst heamoraging money due to lost business, as none of their employees > can make calls, the subscriber makes the not unreasonable point that they > could tell all their users to switch to anonymous calls anyway, without > asking the Service Provider, so what is the point of their regulatory right > to an anonymity service ?? > > It has to work in a manner which is transparent and simple to the users and > subscriber. If you want a client-based solution to this service, then you > need to standardise a way of automatically informing & updating clients > about the subscription anonymity policy. Still doesn't work for forwarding > users. > > The alternative is to accept that From/To modification in the network is > required to implement these services & no standardisation is required. > > ....Mark > > > > -----Original Message----- > > From: jh@lohi.eng.song.fi [mailto:jh@lohi.eng.song.fi] > > Sent: 16 April 2002 11:10 > > To: Watson, Mark [MDN05:EP10:EXCH] > > Cc: 'Ben Campbell'; Chiou, Mark; Dean Willis; Mpierce1@aol.com; > > sip@ietf.org > > Subject: RE: Summary of RE: [Sip] Comment, SIP Privacy draft > > > > > > the current bis-09 text says: > > > > The From header field allows for a display name. A UAC SHOULD use the > > display name Anonymous , along with a syntactically correct, but > > otherwise meaningless URI (like sip:thisis@anonymous.invalid), if > > the identity of the client is to remain hidden. > > > > this is all that is needed except that in my service the uri must be > > meaningful. > > > > most UAs on the market support this. so fail to see what the > > issue is. > > > > -- juha > > > > > _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Tue Apr 16 23:13:16 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA27688 for ; Tue, 16 Apr 2002 23:13:16 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id XAA00014 for sip-archive@odin.ietf.org; Tue, 16 Apr 2002 23:13:19 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id WAA28976; Tue, 16 Apr 2002 22:48:16 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id WAA28945 for ; Tue, 16 Apr 2002 22:48:11 -0400 (EDT) Received: from mail-blue.research.att.com (mail-blue.research.att.com [135.207.30.102]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA25543 for ; Tue, 16 Apr 2002 22:48:06 -0400 (EDT) Received: from alliance.research.att.com (alliance.research.att.com [135.207.26.26]) by mail-blue.research.att.com (Postfix) with ESMTP id 54CBB4CE7B for ; Tue, 16 Apr 2002 22:48:09 -0400 (EDT) Received: from fish.research.att.com (fish.research.att.com [135.207.27.137]) by alliance.research.att.com (8.8.7/8.8.7) with ESMTP id WAA01297; Tue, 16 Apr 2002 22:48:06 -0400 (EDT) From: William Marshall Received: (from wtm@localhost) by fish.research.att.com (SGI-8.9.3/8.8.5) id WAA40877; Tue, 16 Apr 2002 22:47:35 -0400 (EDT) Date: Tue, 16 Apr 2002 22:47:35 -0400 (EDT) Message-Id: <200204170247.WAA40877@fish.research.att.com> To: sip@ietf.org Subject: [Sip] z9hG4bK forever ??? Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Subject: was Re: Screened FromL and Privacy Subject: was Re: Summary of RE: [Sip] Comment, SIP Privacy draft Subject: was lots of others, too All this discussion of proxy modification of the From and To headers, and the need for a B2BUA, seems to me to be a short-term problem only. RFC3261 (2543bis-09) specifies matching of dialog-ids based only on Call-ID and tags, not on display-name or on addr-spec. So when all endpoints are compliant with RFC3261, there will be no problem with a proxy modifying the display-name or addr-spec in the From header. It is only during a transition period, when endpoints that conform to RFC2543 are supported as well as newer ones. How long will this be? How long will a proxy need to handle a UAC that doesn't supply a Contact header? How long will a proxy need to handle a Record-Route header without the "lr" tag? How long will a UAS need to handle a BYE received prior to sending 2xx? How long will the comparison be coded into the proxies and UAs looking for "z9hG4bK"? In all cases, my hope is not too long. And, at the point when these "conversion aids" no longer need to be present in SIP implementations, it will be safe for proxies to modify the From header to provide anonymity, if the subscriber, or the user, or the regulator, (or others?), says that it should. In cases like 3GPP, where (IIRC) release 5 does not include IMS connections outside of the wireless operator's network, the problem is even simpler. Since 3GPP required RFC3261 everywhere, modification of the From header can be done immediately. I would hope this transition period and the need for "conversion aids" would be over before 3GPP release 6 is deployed. My conclusion from all of this is that 3GPP can require the UE to insert a valid user identifier in the From header, and the S-CSCF can change it if privacy is desired, on a session-by-session basis, based on whatever rules the S-CSCF wants to follow. Comments? Bill Marshall wtm@research.att.com _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Wed Apr 17 05:44:13 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA13324 for ; Wed, 17 Apr 2002 05:44:12 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id FAA28109 for sip-archive@odin.ietf.org; Wed, 17 Apr 2002 05:44:16 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id FAA26727; Wed, 17 Apr 2002 05:15:23 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id FAA26694 for ; Wed, 17 Apr 2002 05:15:18 -0400 (EDT) Received: from zctfs063.nortelnetworks.com (zctfs063.nortelnetworks.com [47.164.128.120]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA13021 for ; Wed, 17 Apr 2002 05:14:42 -0400 (EDT) Received: from zwcwc012.europe.nortel.com (zwcwc012.europe.nortel.com [47.73.112.187]) by zctfs063.nortelnetworks.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id g3H9Cqe29886; Wed, 17 Apr 2002 11:12:52 +0200 (MEST) Received: by zwcwc012.europe.nortel.com with Internet Mail Service (5.5.2653.19) id ; Wed, 17 Apr 2002 10:12:55 +0100 Message-ID: From: "Mark Watson" To: "'Rohan Mahy'" Cc: "'jh@lohi.eng.song.fi'" , "'Ben Campbell'" , "Chiou, Mark" , Dean Willis , Mpierce1@aol.com, sip@ietf.org Subject: RE: Summary of RE: [Sip] Comment, SIP Privacy draft Date: Wed, 17 Apr 2002 10:12:49 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C1E5EF.A1C2BA84" Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C1E5EF.A1C2BA84 Content-Type: text/plain Rohan wrote: > I do not buy the argument that we need the network to provide this > service, but that it is somehow a burden for the network to > implement this > service using a B2BUA. > This is not what I have been arguing. I agree that this type of anonymity service will require more than a plain proxy (which by some definitions means it's a B2BUA). I know this will break (some) services. I want to minimise the (future) services that break, by avoiding the assumption that such devices do not exist. Regards...Mark ------_=_NextPart_001_01C1E5EF.A1C2BA84 Content-Type: text/html Content-Transfer-Encoding: quoted-printable RE: Summary of RE: [Sip] Comment, SIP Privacy draft
Rohan wrote:

> I do not buy the argument that we need the = network to provide this
> service, but that it is somehow a burden for = the network to
> implement this
> service using a B2BUA.
>

This is not what I have been arguing. I agree that = this type of anonymity service will require more than a plain proxy = (which by some definitions means it's a B2BUA).

I know this will break (some) services.

I want to minimise the (future) services that break, = by avoiding the assumption that such devices do not exist.

Regards...Mark
------_=_NextPart_001_01C1E5EF.A1C2BA84-- _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Wed Apr 17 06:18:15 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA13768 for ; Wed, 17 Apr 2002 06:18:15 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id GAA29731 for sip-archive@odin.ietf.org; Wed, 17 Apr 2002 06:18:17 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id FAA28396; Wed, 17 Apr 2002 05:50:16 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id FAA28365 for ; Wed, 17 Apr 2002 05:50:11 -0400 (EDT) Received: from penguin.wise.edt.ericsson.se (penguin-ext.wise.edt.ericsson.se [193.180.251.48]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA13396 for ; Wed, 17 Apr 2002 05:50:07 -0400 (EDT) Received: from fogerty.lmf.ericsson.se (fogerty.lmf.ericsson.se [131.160.11.6]) by penguin.wise.edt.ericsson.se (8.12.1/8.12.1/WIREfire-1.4) with ESMTP id g3H9o9s7009021; Wed, 17 Apr 2002 11:50:09 +0200 (MEST) Received: from ericsson.com (3NJPI0013L1IJOG.lmf.ericsson.se [131.160.30.48]) by fogerty.lmf.ericsson.se (8.12.1/8.12.1/lmf.8.12.1.jcs) with ESMTP id g3H9o7o5024462; Wed, 17 Apr 2002 12:50:07 +0300 (EET DST) Message-ID: <3CBD454F.CE30FBF9@ericsson.com> Date: Wed, 17 Apr 2002 12:50:07 +0300 From: "Miguel A. Garcia" Organization: OY LM Ericsson AB X-Mailer: Mozilla 4.74 [en] (Windows NT 5.0; U) X-Accept-Language: es,en MIME-Version: 1.0 To: William Marshall CC: sip@ietf.org Subject: Re: [Sip] z9hG4bK forever ??? References: <200204170247.WAA40877@fish.research.att.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit Hi Bill: This is just to state that you made a very good summary of the situation with 3GPP and I agree with your final conclusion. If we don't go for such a solution we may risk the case when neither the user nor the network (or regulator) required privacy. If we require the endpoints to start sessions anonymously, just in case... then the session will be anonymous even when not needed. Therefore, I would like to see a consensus on Bill's proposal: Users identify theirselves in the From (UAC), the proxy MAY anonymize the From if the policy (or the regulator) requires it. /Miguel William Marshall wrote: > > Subject: was Re: Screened FromL and Privacy > Subject: was Re: Summary of RE: [Sip] Comment, SIP Privacy draft > Subject: was lots of others, too > > All this discussion of proxy modification of the From and To headers, > and the need for a B2BUA, seems to me to be a short-term problem only. > > RFC3261 (2543bis-09) specifies matching of dialog-ids based only > on Call-ID and tags, not on display-name or on addr-spec. So > when all endpoints are compliant with RFC3261, there will be no > problem with a proxy modifying the display-name or addr-spec in > the From header. > > It is only during a transition period, when endpoints that conform > to RFC2543 are supported as well as newer ones. How long will > this be? How long will a proxy need to handle a UAC that doesn't > supply a Contact header? How long will a proxy need to handle > a Record-Route header without the "lr" tag? How long will a > UAS need to handle a BYE received prior to sending 2xx? How long > will the comparison be coded into the proxies and UAs looking > for "z9hG4bK"? > > In all cases, my hope is not too long. And, at the point when > these "conversion aids" no longer need to be present in SIP > implementations, it will be safe for proxies to modify the From > header to provide anonymity, if the subscriber, or the user, or the > regulator, (or others?), says that it should. > > In cases like 3GPP, where (IIRC) release 5 does not include > IMS connections outside of the wireless operator's network, the > problem is even simpler. Since 3GPP required RFC3261 everywhere, > modification of the From header can be done immediately. I would > hope this transition period and the need for "conversion aids" would > be over before 3GPP release 6 is deployed. > > My conclusion from all of this is that 3GPP can require the UE to > insert a valid user identifier in the From header, and the S-CSCF can > change it if privacy is desired, on a session-by-session basis, > based on whatever rules the S-CSCF wants to follow. > > Comments? > > Bill Marshall > wtm@research.att.com > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip -- Miguel-Angel Garcia Oy LM Ericsson AB Jorvas, Finland mailto:Miguel.A.Garcia@ericsson.com Phone: +358 9 299 3553 mailto:Miguel.A.Garcia@piuha.net Mobile: +358 40 5140002 _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Wed Apr 17 06:24:27 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA13866 for ; Wed, 17 Apr 2002 06:24:26 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id GAA29892 for sip-archive@odin.ietf.org; Wed, 17 Apr 2002 06:24:28 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id FAA28747; Wed, 17 Apr 2002 05:57:08 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id FAA28717 for ; Wed, 17 Apr 2002 05:57:03 -0400 (EDT) Received: from zctfs063.nortelnetworks.com (zctfs063.nortelnetworks.com [47.164.128.120]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA13544 for ; Wed, 17 Apr 2002 05:56:46 -0400 (EDT) Received: from zwcwc012.europe.nortel.com (zwcwc012.europe.nortel.com [47.73.112.187]) by zctfs063.nortelnetworks.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id g3H9uDe10767; Wed, 17 Apr 2002 11:56:17 +0200 (MEST) Received: by zwcwc012.europe.nortel.com with Internet Mail Service (5.5.2653.19) id ; Wed, 17 Apr 2002 10:56:16 +0100 Message-ID: From: "Mark Watson" To: "'William Marshall'" , sip@ietf.org Subject: RE: [Sip] z9hG4bK forever ??? Date: Wed, 17 Apr 2002 10:56:14 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C1E5F6.1C749A26" Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C1E5F6.1C749A26 Content-Type: text/plain Bill, Indeed, this approach seems good to me too. But expect people to argue the following points: 1) Proxies as defined in RFC3261 cannot modify the From field. Sure, it is a small extension, but strictly speaking it is more than a pure proxy does. 2) This modification does break some services. It would be best to avoid it except when necessary e.g. if the *user* requires privacy, then still put Anonymous in the From field. 3) verification of the From field is either 'required for consistent service in a Service Provider environment' (myself, probably most of 3GPP, Juha, others ? ...) OR 'contrary to the definition of the From field as an end-to-end user asserted field' (Dean, Dave, others ? ...) - we have no consensus on this. The only compromise I can see on this is: a) Those who want to verify the From: field do b) Those who don't want to don't c) In the absence of trust relationships the From: field is completely untrusted (like everything else!). If you have a trust relationship, then as part of this you will agree whether From: can be trusted or not. d) The contents of the From field MAY be modified by devices in the network. So we should design new services and features with this assumption where possible (d) is a logical consequence of (a) - don't try and argue out (d) unless you think you can exclude (a) too. ...Mark > -----Original Message----- > From: William Marshall [mailto:wtm@research.att.com] > Sent: 17 April 2002 03:48 > To: sip@ietf.org > Subject: [Sip] z9hG4bK forever ??? > > > Subject: was Re: Screened FromL and Privacy > Subject: was Re: Summary of RE: [Sip] Comment, SIP Privacy draft > Subject: was lots of others, too > > All this discussion of proxy modification of the From and To headers, > and the need for a B2BUA, seems to me to be a short-term problem only. > > RFC3261 (2543bis-09) specifies matching of dialog-ids based only > on Call-ID and tags, not on display-name or on addr-spec. So > when all endpoints are compliant with RFC3261, there will be no > problem with a proxy modifying the display-name or addr-spec in > the From header. > > It is only during a transition period, when endpoints that conform > to RFC2543 are supported as well as newer ones. How long will > this be? How long will a proxy need to handle a UAC that doesn't > supply a Contact header? How long will a proxy need to handle > a Record-Route header without the "lr" tag? How long will a > UAS need to handle a BYE received prior to sending 2xx? How long > will the comparison be coded into the proxies and UAs looking > for "z9hG4bK"? > > In all cases, my hope is not too long. And, at the point when > these "conversion aids" no longer need to be present in SIP > implementations, it will be safe for proxies to modify the From > header to provide anonymity, if the subscriber, or the user, or the > regulator, (or others?), says that it should. > > In cases like 3GPP, where (IIRC) release 5 does not include > IMS connections outside of the wireless operator's network, the > problem is even simpler. Since 3GPP required RFC3261 everywhere, > modification of the From header can be done immediately. I would > hope this transition period and the need for "conversion aids" would > be over before 3GPP release 6 is deployed. > > My conclusion from all of this is that 3GPP can require the UE to > insert a valid user identifier in the From header, and the S-CSCF can > change it if privacy is desired, on a session-by-session basis, > based on whatever rules the S-CSCF wants to follow. > > Comments? > > Bill Marshall > wtm@research.att.com > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip > ------_=_NextPart_001_01C1E5F6.1C749A26 Content-Type: text/html Content-Transfer-Encoding: quoted-printable RE: [Sip] z9hG4bK forever ???
Bill,

Indeed, this approach seems good to me too. But = expect people to argue the following points:
1) Proxies as defined in RFC3261 cannot modify the = From field. Sure, it is a small extension, but strictly speaking it is = more than a pure proxy does.

2) This modification does break some services. It = would be best to avoid it except when necessary e.g. if the *user* = requires privacy, then still put Anonymous in the From = field.

3) verification of the From field is either 'required = for consistent service in a Service Provider environment' (myself, = probably most of 3GPP, Juha, others ? ...) OR 'contrary to the = definition of the From field as an end-to-end user asserted field' = (Dean, Dave, others ? ...) - we have no consensus on this.

The only compromise I can see on this is:
a) Those who want to verify the From: field = do
b) Those who don't want to don't
c) In the absence of trust relationships the From: = field is completely untrusted (like everything else!). If you have a = trust relationship, then as part of this you will agree whether From: = can be trusted or not.

d) The contents of the From field MAY be modified by = devices in the network. So we should design new services and features = with this assumption where possible

(d) is a logical consequence of (a) - don't try and = argue out (d) unless you think you can exclude (a) too.

...Mark

> -----Original Message-----
> From: William Marshall [mailto:wtm@research.att.com]
> Sent: 17 April 2002 03:48
> To: sip@ietf.org
> Subject: [Sip] z9hG4bK forever ???
>
>
> Subject: was Re: Screened FromL and = Privacy
> Subject: was Re: Summary of RE: [Sip] Comment, = SIP Privacy draft
> Subject: was lots of others, too
>
> All this discussion of proxy modification of = the From and To headers,
> and the need for a B2BUA, seems to me to be a = short-term problem only.
>
> RFC3261 (2543bis-09) specifies matching of = dialog-ids based only
> on Call-ID and tags, not on display-name or on = addr-spec. So
> when all endpoints are compliant with RFC3261, = there will be no
> problem with a proxy modifying the display-name = or addr-spec in
> the From header.
>
> It is only during a transition period, when = endpoints that conform
> to RFC2543 are supported as well as newer = ones. How long will
> this be? How long will a proxy need to = handle a UAC that doesn't
> supply a Contact header? How long will a = proxy need to handle
> a Record-Route header without the = "lr" tag? How long will a
> UAS need to handle a BYE received prior to = sending 2xx? How long
> will the comparison be coded into the proxies = and UAs looking
> for "z9hG4bK"?
>
> In all cases, my hope is not too long. = And, at the point when
> these "conversion aids" no longer = need to be present in SIP
> implementations, it will be safe for proxies to = modify the From
> header to provide anonymity, if the subscriber, = or the user, or the
> regulator, (or others?), says that it = should.
>
> In cases like 3GPP, where (IIRC) release 5 does = not include
> IMS connections outside of the wireless = operator's network, the
> problem is even simpler. Since 3GPP = required RFC3261 everywhere,
> modification of the From header can be done = immediately. I would
> hope this transition period and the need for = "conversion aids" would
> be over before 3GPP release 6 is = deployed.
>
> My conclusion from all of this is that 3GPP can = require the UE to
> insert a valid user identifier in the From = header, and the S-CSCF can
> change it if privacy is desired, on a = session-by-session basis,
> based on whatever rules the S-CSCF wants to = follow.
>
> Comments?
>
> Bill Marshall
> wtm@research.att.com
>
> = _______________________________________________
> Sip mailing list https://www1.ietf.org/mailman/listinfo/sip
> This list is for NEW development of the core = SIP Protocol
> Use sip-implementors@cs.columbia.edu for = questions on current sip
> Use sipping@ietf.org for new developments on = the application of sip
>
------_=_NextPart_001_01C1E5F6.1C749A26-- _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Wed Apr 17 07:49:42 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA14960 for ; Wed, 17 Apr 2002 07:49:42 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id HAA03546 for sip-archive@odin.ietf.org; Wed, 17 Apr 2002 07:49:45 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id HAA02316; Wed, 17 Apr 2002 07:20:36 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id HAA02285 for ; Wed, 17 Apr 2002 07:20:32 -0400 (EDT) Received: from zctfs063.nortelnetworks.com (zctfs063.nortelnetworks.com [47.164.128.120]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA14527 for ; Wed, 17 Apr 2002 07:20:28 -0400 (EDT) Received: from zwcwc012.europe.nortel.com (zwcwc012.europe.nortel.com [47.73.112.187]) by zctfs063.nortelnetworks.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id g3HBIie24438; Wed, 17 Apr 2002 13:18:44 +0200 (MEST) Received: by zwcwc012.europe.nortel.com with Internet Mail Service (5.5.2653.19) id ; Wed, 17 Apr 2002 12:18:47 +0100 Message-ID: From: "Mark Watson" To: "'Henning Schulzrinne'" , Mpierce1@aol.com Cc: oran@cisco.com, sip@ietf.org Subject: RE: Summary of RE: [Sip] Comment, SIP Privacy draft Date: Wed, 17 Apr 2002 12:18:40 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C1E601.A08513DA" Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C1E601.A08513DA Content-Type: text/plain Henning wrote: > No reasonable provider should put that requirement on From, for the > reasons Dean mentioned. This leaves the proxy-authentication data. > Interesting question is whether the proxy-authentication data needs to > be stripped after it has been "used", as it may well apply to several > down-stream proxies. > I believe the view amongst providers in 3GPP is that they would expect such a requirement to be placed on the From field, if any information is to go in there at all. They are _mostly_ reasonable in 3GPP :-) If the proxy-authentication data could include the plain-text (user)name of the user, and if the user or the subscriber has requested privacy, then the information certainly could not be passed on. I suppose you could pass it on to a 'trusted' entity, assuming that this entity could reliably determine the intersection of the subscribers and users privacy requirements so it knew what to do next. Regards, Mark ------_=_NextPart_001_01C1E601.A08513DA Content-Type: text/html Content-Transfer-Encoding: quoted-printable RE: Summary of RE: [Sip] Comment, SIP Privacy draft
Henning wrote:

> No reasonable provider should put that = requirement on From, for the
> reasons Dean mentioned. This leaves the = proxy-authentication data.
> Interesting question is whether the = proxy-authentication data needs to
> be stripped after it has been "used", = as it may well apply to several
> down-stream proxies.
>

I believe the view amongst providers in 3GPP is that = they would expect such a requirement to be placed on the From field, if = any information is to go in there at all. They are _mostly_ reasonable = in 3GPP :-)

If the proxy-authentication data could include the = plain-text (user)name of the user, and if the user or the subscriber = has requested privacy, then the information certainly could not be = passed on.

I suppose you could pass it on to a 'trusted' entity, = assuming that this entity could reliably determine the intersection of = the subscribers and users privacy requirements so it knew what to do = next.

Regards,

Mark
------_=_NextPart_001_01C1E601.A08513DA-- _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Wed Apr 17 08:41:07 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA15896 for ; Wed, 17 Apr 2002 08:41:07 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id IAA06476 for sip-archive@odin.ietf.org; Wed, 17 Apr 2002 08:40:58 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id IAA04756; Wed, 17 Apr 2002 08:10:42 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id IAA04724 for ; Wed, 17 Apr 2002 08:10:38 -0400 (EDT) Received: from mail-green.research.att.com (mail-green.research.att.com [135.207.30.103]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA15244 for ; Wed, 17 Apr 2002 08:10:35 -0400 (EDT) Received: from alliance.research.att.com (alliance.research.att.com [135.207.26.26]) by mail-green.research.att.com (Postfix) with ESMTP id 32FC11E00F for ; Wed, 17 Apr 2002 08:10:27 -0400 (EDT) Received: from fish.research.att.com (fish.research.att.com [135.207.27.137]) by alliance.research.att.com (8.8.7/8.8.7) with ESMTP id IAA05947; Wed, 17 Apr 2002 08:10:23 -0400 (EDT) From: William Marshall Received: (from wtm@localhost) by fish.research.att.com (SGI-8.9.3/8.8.5) id IAA33585; Wed, 17 Apr 2002 08:10:11 -0400 (EDT) Date: Wed, 17 Apr 2002 08:10:11 -0400 (EDT) Message-Id: <200204171210.IAA33585@fish.research.att.com> To: sip@ietf.org Subject: RE: [Sip] z9hG4bK forever ??? Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Mark Watson pointed out: > d) The contents of the From field MAY be modified by devices in the network. > So we should design new services and features with this assumption where > possible I would go even a few steps farther. We have now identified TWO cases where un-proxy-like behavior will be done in real networks. The first, a few months ago, was where a firewall control proxy modified the Contact header, and possibly also modified the addresses and ports in the SDP. The second is here, where a privacy proxy modifies the From header (and quite probably, others). So my recommendations: 1) It is worthwhile recognizing these situations in draft-ietf-sip-rfc3261bis, and including text that limits the message transformations that such network elements can perform. Essentially this means defining the previously coined term "transparent B2BUA". 2) New serivces MUST be designed with the assumption that such "transparent B2BUAs" will be in the path, minimize the ways they will fail with such message transformations, and discuss the recovery action that a UA may take in such failure cases. In the same way that new services MUST be designed knowing that forking may happen. (draft-ietf-sip-guidelines?) An example where (2) has already been followed is draft-ietf-sip-replaces; it uses to-tag and from-tag, rather than full contents of From and To. Bill Marshall wtm@research.att.com _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Wed Apr 17 10:30:46 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA20374 for ; Wed, 17 Apr 2002 10:30:46 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id KAA13691 for sip-archive@odin.ietf.org; Wed, 17 Apr 2002 10:30:50 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA10640; Wed, 17 Apr 2002 09:55:19 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA10597 for ; Wed, 17 Apr 2002 09:55:12 -0400 (EDT) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA17773; Wed, 17 Apr 2002 09:55:08 -0400 (EDT) Message-Id: <200204171355.JAA17773@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; CC: sip@ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Date: Wed, 17 Apr 2002 09:55:08 -0400 Subject: [Sip] I-D ACTION:draft-spbs-sip-negotiate-01.txt Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : The SIP Negotiate Method Author(s) : S. Parameswar, B. Stucker Filename : draft-spbs-sip-negotiate-01.txt Pages : Date : 16-Apr-02 There is a need to negotiate a multitude of parameters, settings, and algorithms when setting up sessions using Session Initiated Protocol (SIP). While SIP itself provides mechanisms for negotiation of these parameters on a per-session basis through the use of the INVITE method, it does not provide a ready mechanism for meta-session negotiation. The closest mechanism provided is the REGISTER method, however, this method is directed towards the registrar alone, and cannot be used to conduct negotiation of parameters between any two arbitrary SIP nodes. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-spbs-sip-negotiate-01.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-spbs-sip-negotiate-01.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-spbs-sip-negotiate-01.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <20020416152501.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-spbs-sip-negotiate-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-spbs-sip-negotiate-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20020416152501.I-D@ietf.org> --OtherAccess-- --NextPart-- _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Wed Apr 17 11:15:43 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA22547 for ; Wed, 17 Apr 2002 11:15:43 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id LAA25073 for sip-archive@odin.ietf.org; Wed, 17 Apr 2002 11:15:47 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA14592; Wed, 17 Apr 2002 10:43:52 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA08299 for ; Wed, 17 Apr 2002 09:18:49 -0400 (EDT) Received: from bt0g2p.god.bel.alcatel.be (alc250.alcatel.be [195.207.101.250]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA16605 for ; Wed, 17 Apr 2002 09:18:44 -0400 (EDT) Received: from bemta001.net.alcatel.be (relay3 [127.0.0.1]) by bt0g2p.god.bel.alcatel.be (8.11.0/8.11.4) with SMTP id g3HDH5g18773 for ; Wed, 17 Apr 2002 15:17:05 +0200 Received: from alcatel.be ([138.203.208.66]) by bemta001.net.alcatel.be (Lotus SMTP MTA v4.6.7 (934.1 12-30-1999)) with SMTP id C1256B9E.00490FFE; Wed, 17 Apr 2002 15:18:02 +0200 Message-ID: <3CBD760A.B3C15FB9@alcatel.be> Date: Wed, 17 Apr 2002 15:18:02 +0200 From: Diether De Praetere Organization: Alcatel Telecom - Next Generation Networks X-Mailer: Mozilla 4.76 [en] (X11; U; SunOS 5.7 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: sip@ietf.org Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [Sip] Retry-After header Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit "14.2 UAS Behaviour" mentions that a 500 (Server Internal Error) needs to include a Retry-After header field ico. the 2nd invite is received before the final response of the 1st INVITE is not sent yet. "20.33 Retry-After" this header field can be used with 503, 404, 413, 480, 486, 600 or 603. I assume that this list should include the 500 too? [rfc2543bis-09] Thanks, Diether. _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Wed Apr 17 12:36:34 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA25911 for ; Wed, 17 Apr 2002 12:36:34 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id MAA28256 for sip-archive@odin.ietf.org; Wed, 17 Apr 2002 12:36:35 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA07967; Wed, 17 Apr 2002 11:53:31 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA07899 for ; Wed, 17 Apr 2002 11:53:26 -0400 (EDT) Received: from bdsl.66.12.12.130.gte.net (bdsl.66.12.12.130.gte.net [66.12.12.130]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA24078 for ; Wed, 17 Apr 2002 11:53:22 -0400 (EDT) Received: from C1893415A (bdsl.greycouncil.com [127.0.0.1]) by bdsl.66.12.12.130.gte.net (8.11.6/8.11.6) with SMTP id g3HFktd01142; Wed, 17 Apr 2002 10:46:55 -0500 Message-ID: <012901c1e627$1a7a9a00$133fed0c@C1893415A> From: "Dean Willis" To: "William Marshall" , References: <200204171210.IAA33585@fish.research.att.com> Subject: Re: [Sip] z9hG4bK forever ??? Date: Wed, 17 Apr 2002 10:46:55 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit Bill said: > We have now identified TWO cases where un-proxy-like behavior will be > done in real networks. The first, a few months ago, was where a > firewall control proxy modified the Contact header, and possibly > also modified the addresses and ports in the SDP. The second is here, > where a privacy proxy modifies the From header (and quite probably, others). Proxies in any form cannot modify bodies, and B2BUAs are likely to break things if they try to. SIP security relies greatly on smime-protected bodies. What you fail to distinguish is that like identity, there are two sorts of privacy: 1) UA asserted 2) Network asserted UA asserted privacy requires that the network NOT tamper with what the UA has done, nor insert additional information that compromises the privacy of the UA. Network asserted privacy requires a full, non-transparent B2BUA. I see this as an OPTIONAL service, EXTERNAL to the proxy-like CSCF elements. In other words, an anonymizer application. -- Dean _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Wed Apr 17 12:58:52 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA27018 for ; Wed, 17 Apr 2002 12:58:52 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id MAA29632 for sip-archive@odin.ietf.org; Wed, 17 Apr 2002 12:58:54 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA28240; Wed, 17 Apr 2002 12:36:15 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA28209 for ; Wed, 17 Apr 2002 12:36:09 -0400 (EDT) Received: from bdsl.66.12.12.130.gte.net (bdsl.66.12.12.130.gte.net [66.12.12.130]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA25905 for ; Wed, 17 Apr 2002 12:36:07 -0400 (EDT) Received: from C1893415A (bdsl.greycouncil.com [127.0.0.1]) by bdsl.66.12.12.130.gte.net (8.11.6/8.11.6) with SMTP id g3HGZbd01530; Wed, 17 Apr 2002 11:35:37 -0500 Message-ID: <001d01c1e62d$e882d650$133fed0c@C1893415A> From: "Dean Willis" To: "William Marshall" , References: <200204170247.WAA40877@fish.research.att.com> Subject: Re: [Sip] z9hG4bK forever ??? Date: Wed, 17 Apr 2002 11:35:38 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit Baill said: > All this discussion of proxy modification of the From and To headers, > and the need for a B2BUA, seems to me to be a short-term problem only. > > RFC3261 (2543bis-09) specifies matching of dialog-ids based only > on Call-ID and tags, not on display-name or on addr-spec. So > when all endpoints are compliant with RFC3261, there will be no > problem with a proxy modifying the display-name or addr-spec in > the From header. I disagree. I don't want the network mangling my user-to-user headers unless I've specifically requested it to do so. Specifically, the non-authenticated, non-mangled, non-protected From: field offers utility which is DIFFERENT than that provided by network authenticated calling party ID, and I don't want to sacrifice that utility just because this is a capability the widely-deployed PSTN (as opposed to say Q.SIG) didn't have . . . -- Dean _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@ns.ietf.org Wed Apr 17 16:20:12 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA05873 for ; Wed, 17 Apr 2002 16:20:11 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id QAA14370 for sip-archive@odin.ietf.org; Wed, 17 Apr 2002 16:20:14 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA12957; Wed, 17 Apr 2002 15:58:00 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA12926 for ; Wed, 17 Apr 2002 15:57:56 -0400 (EDT) Received: from mail1.dynamicsoft.com (mail1.dynamicsoft.com [63.113.40.10]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA04778 for ; Wed, 17 Apr 2002 15:57:52 -0400 (EDT) Received: from DYN-EXCH-001.dynamicsoft.com (dyn-exch-001 [63.113.44.7]) by mail1.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id g3HJsUDE023107; Wed, 17 Apr 2002 15:54:30 -0400 (EDT) Received: from dynamicsoft.com (NJ-AKRISTENSEN.dynamicsoft.com [63.113.46.198]) by DYN-EXCH-001.dynamicsoft.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id 2QA0CCGS; Wed, 17 Apr 2002 15:56:55 -0400 Message-ID: <3CBDD384.30500@dynamicsoft.com> Date: Wed, 17 Apr 2002 15:56:52 -0400 From: Anders Kristensen User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:0.9.9) Gecko/20020311 X-Accept-Language: en-us, en MIME-Version: 1.0 To: sip@ietf.org, sip-implementors@cs.columbia.edu Content-Type: multipart/mixed; boundary="------------050405000505060806020004" Subject: [Sip] SIP Servlet API draft [Fwd: JSR 116: Public Review (repost)] Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org This is a multi-part message in MIME format. --------------050405000505060806020004 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit FYI... In addition to the PDF draft, javadoc API and a jar file should be available from the JCP site in a day or two. Anders --------------050405000505060806020004 Content-Type: message/rfc822; name="JSR 116: Public Review (repost)" Content-Disposition: inline; filename="JSR 116: Public Review (repost)" X-Mozilla-Status2: 00000000 Received: from mail2.dynamicsoft.com (192.168.4.31 [192.168.4.31]) by DYN-EXCH-001.dynamicsoft.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id 2QA0CCDS; Wed, 17 Apr 2002 15:41:25 -0400 Received: from swjscmail2.java.sun.com (swjscmail2.Sun.COM [192.18.99.108]) by mail2.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id g3HJdFUH013200 for ; Wed, 17 Apr 2002 15:39:16 -0400 (EDT) Received: from swjscmail1 (swjscmail1.Sun.COM [192.18.99.107]) by swjscmail2.java.sun.com (Postfix) with ESMTP id 4FE24238A7; Wed, 17 Apr 2002 13:39:25 -0600 (MDT) Received: from JAVA.SUN.COM by JAVA.SUN.COM (LISTSERV-TCP/IP release 1.8d) with spool id 1549311 for JCP-INTEREST@JAVA.SUN.COM; Wed, 17 Apr 2002 13:38:12 -0600 Received: from nwkea-mail-1.sun.com (nwkea-mail-1.sun.com [192.18.42.13]) by swjscmail1.java.sun.com (Postfix) with ESMTP id E721E480D for ; Wed, 17 Apr 2002 13:31:31 -0600 (MDT) Received: from sunmail2.Sun.COM ([129.150.166.10]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id MAA21549 for ; Wed, 17 Apr 2002 12:34:28 -0700 (PDT) Received: from ha3sca-mail1.SFBay.Sun.COM (phys-ha3sca-2.SFBay.Sun.COM [129.145.155.72]) by sunmail2.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1-Sun.COM.mod.2) with ESMTP id MAA10750 for ; Wed, 17 Apr 2002 12:34:58 -0700 (PDT) Received: from sr1-usca-04 (sr1-usca-04 [129.145.155.136]) by ha3sca-mail1.SFBay.Sun.COM (8.10.2+Sun/8.10.2/ENSMAIL,v2.1p1) with SMTP id g3HJYQG25517 for ; Wed, 17 Apr 2002 12:34:26 -0700 (PDT) Approved-By: harold.ogle@SUN.COM Delivered-To: jcp-interest@java.sun.com MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Content-MD5: hBklhV/7w0ZbuaY7BAWd7A== X-Mailer: dtmail 1.3.0 @(#)CDE Version 1.4.2 SunOS 5.8 sun4u sparc Message-ID: <200204171934.g3HJYQG25517@ha3sca-mail1.SFBay.Sun.COM> Date: Wed, 17 Apr 2002 12:34:27 -0700 Reply-To: "Java Community Process (JCP) general information/announcement list" From: Harold Ogle Subject: JSR 116: Public Review (repost) To: JCP-INTEREST@JAVA.SUN.COM The Expert Group of the following Specification development effort JSR-000116 SIP Servlet API has released a draft specification for Public Review. http://jcp.org/jsr/stage/public.jsp The Public Review closes 9 May 2002. =========================================================================== To unsubscribe, send email to listserv@java.sun.com and include in the body of the message "signoff JCP-INTEREST". For general help, send email to listserv@java.sun.com and include in the body of the message "help". --------------050405000505060806020004-- _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@ns.ietf.org Wed Apr 17 16:34:38 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA06494 for ; Wed, 17 Apr 2002 16:34:38 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id QAA15755 for sip-archive@odin.ietf.org; Wed, 17 Apr 2002 16:34:42 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA13909; Wed, 17 Apr 2002 16:08:11 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA13878 for ; Wed, 17 Apr 2002 16:08:07 -0400 (EDT) Received: from dgesmtp02.wcom.com (dgesmtp02.wcom.com [199.249.16.17]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA05361 for ; Wed, 17 Apr 2002 16:08:03 -0400 (EDT) Received: from CONVERSION-DAEMON by firewall.wcom.com (PMDF V5.2-33 #42261) id <0GUQ00B01AKG04@firewall.wcom.com> for sip@ietf.org; Wed, 17 Apr 2002 20:07:30 +0000 (GMT) Received: from dgismtp04.wcomnet.com ([166.38.58.144]) by firewall.wcom.com (PMDF V5.2-33 #42261) with ESMTP id <0GUQ00A2MAKGT8@firewall.wcom.com>; Wed, 17 Apr 2002 20:07:28 +0000 (GMT) Received: from dgismtp04.wcomnet.com by dgismtp04.wcomnet.com (iPlanet Messaging Server 5.1 (built May 7 2001)) with SMTP id <0GUQ00J01AIUTD@dgismtp04.wcomnet.com>; Wed, 17 Apr 2002 20:07:28 +0000 (GMT) Received: from hsinnreich2 ([166.35.224.250]) by dgismtp04.wcomnet.com (iPlanet Messaging Server 5.1 (built May 7 2001)) with ESMTP id <0GUQ00IFXAJPFV@dgismtp04.wcomnet.com>; Wed, 17 Apr 2002 20:07:01 +0000 (GMT) Date: Wed, 17 Apr 2002 15:07:00 -0500 From: Henry Sinnreich Subject: RE: [Sip] Cookies or State In-reply-to: <313680C9A886D511A06000204840E1CF57CE71@whq-msgusr-02.pit.comms.marconi.com> To: "'Rosen, Brian'" , sip@ietf.org Message-id: <003101c1e64b$6f9e1010$fae023a6@hsinnreich2> Organization: WorldCom, Inc. MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 X-Mailer: Microsoft Outlook, Build 10.0.3416 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7bit Importance: Normal X-Priority: 3 (Normal) X-MSMail-priority: Normal Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit >The question is, should we > base it on State or Cookies? I like the cookies better, since they mirror a successful web approach. >To our > consternation, the same IP claims were then made against Cookies! Consternation is the right word. Henry > -----Original Message----- > From: sip-admin@ietf.org [mailto:sip-admin@ietf.org] On > Behalf Of Rosen, Brian > Sent: Wednesday, April 17, 2002 2:28 PM > To: 'sip@ietf.org' > Subject: [Sip] Cookies or State > > > There are two drafts that define how to save state in a UA > for subsequent use by a Proxy Server - State and Cookies. > > State is part of the DCS work. Cookies arose when IP assertions were > made against State. Cookies attempted to get around the IP > issues by defining it as exactly like HTTP cookies. To our > consternation, the same IP claims were then made against Cookies! > > We need to get this capability. The question is, should we > base it on State or Cookies? > > In my personal (biased) opinion we are better off with > Cookies. If anyone did want to fight the IP claim, you would > clearly be better off with 75% same language as HTTP cookies. > > Brian > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current > sip Use sipping@ietf.org for new developments on the > application of sip > _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@ns.ietf.org Wed Apr 17 16:49:33 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA07191 for ; Wed, 17 Apr 2002 16:49:32 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id QAA16701 for sip-archive@odin.ietf.org; Wed, 17 Apr 2002 16:49:36 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA14891; Wed, 17 Apr 2002 16:27:30 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA14859 for ; Wed, 17 Apr 2002 16:27:26 -0400 (EDT) Received: from magus.nostrum.com (root@magus.nostrum.com [66.119.225.66]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA06220 for ; Wed, 17 Apr 2002 16:27:21 -0400 (EDT) Received: from txbcampbell (root@magus.nostrum.com [66.119.225.66]) by magus.nostrum.com (8.11.0/8.11.0) with SMTP id g3HKRDX85157; Wed, 17 Apr 2002 15:27:13 -0500 (CDT) From: "Ben Campbell" To: "Rosen, Brian" , Subject: RE: [Sip] Cookies or State Date: Wed, 17 Apr 2002 15:26:49 -0500 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) In-reply-to: <313680C9A886D511A06000204840E1CF57CE71@whq-msgusr-02.pit.comms.marconi.com> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Importance: Normal Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit Cookie!! (says the blue furry guy...) > -----Original Message----- > From: sip-admin@ietf.org [mailto:sip-admin@ietf.org]On Behalf Of Rosen, > Brian > Sent: Wednesday, April 17, 2002 2:28 PM > To: 'sip@ietf.org' > Subject: [Sip] Cookies or State > > > There are two drafts that define how to save state in a UA for subsequent > use by a Proxy Server - State and Cookies. > > State is part of the DCS work. Cookies arose when IP assertions were > made against State. Cookies attempted to get around the IP issues > by defining it as exactly like HTTP cookies. To our consternation, > the same IP claims were then made against Cookies! > > We need to get this capability. The question is, should we > base it on State or Cookies? > > In my personal (biased) opinion we are better off with Cookies. > If anyone did want to fight the IP claim, you would clearly > be better off with 75% same language as HTTP cookies. > > Brian > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@ns.ietf.org Wed Apr 17 17:02:00 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA07709 for ; Wed, 17 Apr 2002 17:01:59 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id RAA18339 for sip-archive@odin.ietf.org; Wed, 17 Apr 2002 17:02:03 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA10250; Wed, 17 Apr 2002 15:28:21 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA10219 for ; Wed, 17 Apr 2002 15:28:16 -0400 (EDT) Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA03090 for ; Wed, 17 Apr 2002 15:28:12 -0400 (EDT) Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id PAA05256 for ; Wed, 17 Apr 2002 15:27:42 -0400 (EDT) Received: from whq-msgrtr-01.pit.comms.marconi.com (whq-msgrtr-01.pit.comms.marconi.com [169.144.2.221]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id PAA11844 for ; Wed, 17 Apr 2002 15:27:39 -0400 (EDT) Received: by whq-msgrtr-01.pit.comms.marconi.com with Internet Mail Service (5.5.2650.21) id ; Wed, 17 Apr 2002 15:27:30 -0400 Message-ID: <313680C9A886D511A06000204840E1CF57CE71@whq-msgusr-02.pit.comms.marconi.com> From: "Rosen, Brian" To: "'sip@ietf.org'" Date: Wed, 17 Apr 2002 15:27:37 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="ISO-8859-1" Subject: [Sip] Cookies or State Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org There are two drafts that define how to save state in a UA for subsequent use by a Proxy Server - State and Cookies. State is part of the DCS work. Cookies arose when IP assertions were made against State. Cookies attempted to get around the IP issues by defining it as exactly like HTTP cookies. To our consternation, the same IP claims were then made against Cookies! We need to get this capability. The question is, should we base it on State or Cookies? In my personal (biased) opinion we are better off with Cookies. If anyone did want to fight the IP claim, you would clearly be better off with 75% same language as HTTP cookies. Brian _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@ns.ietf.org Wed Apr 17 17:30:06 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA08521 for ; Wed, 17 Apr 2002 17:30:06 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id RAA19727 for sip-archive@odin.ietf.org; Wed, 17 Apr 2002 17:30:09 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA18148; Wed, 17 Apr 2002 17:01:31 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA18099 for ; Wed, 17 Apr 2002 17:01:26 -0400 (EDT) Received: from ierw.net.avaya.com (ierw.net.avaya.com [198.152.13.101]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA07665 for ; Wed, 17 Apr 2002 17:01:20 -0400 (EDT) Received: from ierw.net.avaya.com (localhost [127.0.0.1]) by ierw.net.avaya.com (8.9.3+Sun/8.9.3) with ESMTP id QAA22467 for ; Wed, 17 Apr 2002 16:59:47 -0400 (EDT) Received: from cof110avexu1.global.avaya.com (h135-9-6-16.avaya.com [135.9.6.16]) by ierw.net.avaya.com (8.9.3+Sun/8.9.3) with ESMTP id QAA22463 for ; Wed, 17 Apr 2002 16:59:47 -0400 (EDT) X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: [Sip] Cookies or State Date: Wed, 17 Apr 2002 15:02:05 -0600 Message-ID: Thread-Topic: [Sip] Cookies or State Thread-Index: AcHmSebLcBILcaphQlSpQOq/1Sa1OwAB0snQ From: "Zmolek, Andrew (Andrew)" To: "Rosen, Brian" , Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id RAA18100 Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 8bit > In my personal (biased) opinion we are better off with Cookies. > If anyone did want to fight the IP claim, you would clearly > be better off with 75% same language as HTTP cookies. There are some good reasons to stick with an HTTP cookies approach, although I don't have a strong preference as long as we pick one. IANAL, but I'm sure the IPR issue won't go away by copying HTTP cookie language. On the other hand, appropriate substitution of normative references might deflect the claim. In any case, kludge-free SIP state mechanisms are long overdue. --Andy Zmolek Technology & Standards Engineer CTO Standards Avaya Inc. zmolek@avaya.com +1 720 444 4001 _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@ns.ietf.org Wed Apr 17 19:44:23 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA11138 for ; Wed, 17 Apr 2002 19:44:23 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id TAA27687 for sip-archive@odin.ietf.org; Wed, 17 Apr 2002 19:44:25 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id TAA26479; Wed, 17 Apr 2002 19:24:58 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id TAA26451 for ; Wed, 17 Apr 2002 19:24:55 -0400 (EDT) Received: from bdsl.66.12.12.130.gte.net (bdsl.66.12.12.130.gte.net [66.12.12.130]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA10790 for ; Wed, 17 Apr 2002 19:24:52 -0400 (EDT) Received: from C1893415A (bdsl.greycouncil.com [127.0.0.1]) by bdsl.66.12.12.130.gte.net (8.11.6/8.11.6) with SMTP id g3HNOOd04331 for ; Wed, 17 Apr 2002 18:24:24 -0500 Message-ID: <035701c1e667$05a08370$133fed0c@C1893415A> From: "Dean Willis" To: Date: Wed, 17 Apr 2002 18:24:29 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Content-Transfer-Encoding: 7bit Subject: [Sip] new drafts relating to privacy and identity concepts posted Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit Please review: http://www.softarmor.com/sipwg/drafts/draft-peterson-sip-privacy-longter m-00.txt http://www.softarmor.com/sipwg/drafts/draft-peterson-sip-identity-00.txt They've been sent into the internet-drafts repository and should appear there shortly. -- Dean _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@ns.ietf.org Wed Apr 17 19:45:59 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA11166 for ; Wed, 17 Apr 2002 19:45:54 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id TAA27714 for sip-archive@odin.ietf.org; Wed, 17 Apr 2002 19:45:55 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id TAA26192; Wed, 17 Apr 2002 19:21:56 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id TAA26133 for ; Wed, 17 Apr 2002 19:21:52 -0400 (EDT) Received: from imo-d10.mx.aol.com (imo-d10.mx.aol.com [205.188.157.42]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA10698 for ; Wed, 17 Apr 2002 19:21:49 -0400 (EDT) From: Mpierce1@aol.com Received: from Mpierce1@aol.com by imo-d10.mx.aol.com (mail_out_v32.5.) id e.f5.1a7959cd (25511); Wed, 17 Apr 2002 19:21:13 -0400 (EDT) Message-ID: Date: Wed, 17 Apr 2002 19:21:12 EDT Subject: Re: [Sip] Cookies or State To: Brian.Rosen@marconi.com, sip@ietf.org MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="part1_f5.1a7959cd.29ef5d68_boundary" X-Mailer: AOL 6.0 for Windows US sub 10524 Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org --part1_f5.1a7959cd.29ef5d68_boundary Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit In a message dated 4/17/02 3:32:15 PM Eastern Daylight Time, Brian.Rosen@marconi.com writes: > There are two drafts that define how to save state in a UA for subsequent > use by a Proxy Server - State and Cookies. > > State is part of the DCS work. Cookies arose when IP assertions were > made against State. Cookies attempted to get around the IP issues > by defining it as exactly like HTTP cookies. To our consternation, > the same IP claims were then made against Cookies! > > We need to get this capability. The question is, should we > base it on State or Cookies? > > In my personal (biased) opinion we are better off with Cookies. > If anyone did want to fight the IP claim, you would clearly > be better off with 75% same language as HTTP cookies. > I presume the reference for "Cookies" is still draft-willis-sip-cookies-00 of July 2001. I haven't seen any further discussion on this draft or responses to the comments I submitted Nov 19. From that draft, it appears there are significant security concerns with the use of "Cookies" in a fashion similar to HTTP as proposed in this draft. State would appear to have fewer security concerns if it is simply a value stored in the UA for the beniefit of the proxy to fetch and use later. It is presumed that the lack of a standard definition of this state value would preclude its use by a different proxy than the one which stored it (at least by a proxy of a different design). It continues to escape me why it would not be better for the proxy to simply stored this "state" in its own storage, rather than using every UA as a distributed storage device. This concept seems to go back to the days when memory was limited (the first telephone switch I was involved in designing had 64k bytes of memory!) When one can buy 512M bytes of memory for less than $100, this should no longer be an issue. The "state" draft seems to indicate that the only reason for doing this is so that "proxy servers can remain stateless for the duration of the call", but I have never heard a reason why this is desirable. (Note that bis-09 defines the term "call-stateful proxy".) Why don't we just admit that it is required in some cases to keep the call state in the proxy and stop trying to invent ways around this, all of which have security and performance problems? Mike --part1_f5.1a7959cd.29ef5d68_boundary Content-Type: text/html; charset="US-ASCII" Content-Transfer-Encoding: 7bit In a message dated 4/17/02 3:32:15 PM Eastern Daylight Time, Brian.Rosen@marconi.com writes:

There are two drafts that define how to save state in a UA for subsequent
use by a Proxy Server - State and Cookies.

State is part of the DCS work. Cookies arose when IP assertions were
made against State. Cookies attempted to get around the IP issues
by defining it as exactly like HTTP cookies. To our consternation,
the same IP claims were then made against Cookies!

We need to get this capability. The question is, should we
base it on State or Cookies?

In my personal (biased) opinion we are better off with Cookies.
If anyone did want to fight the IP claim, you would clearly
be better off with 75% same language as HTTP cookies.

I presume the reference for "Cookies" is still draft-willis-sip-cookies-00 of July 2001. I haven't seen any further discussion on this draft or responses to the comments I submitted Nov 19. From that draft, it appears there are significant security concerns with the use of "Cookies" in a fashion similar to HTTP as proposed in this draft.

State would appear to have fewer security concerns if it is simply a value stored in the UA for the beniefit of the proxy to fetch and use later. It is presumed that the lack of a standard definition of this state value would preclude its use by a different proxy than the one which stored it (at least by a proxy of a different design).

It continues to escape me why it would not be better for the proxy to simply stored this "state" in its own storage, rather than using every UA as a distributed storage device. This concept seems to go back to the days when memory was limited (the first telephone switch I was involved in designing had 64k bytes of memory!) When one can buy 512M bytes of memory for less than $100, this should no longer be an issue. The "state" draft seems to indicate that the only reason for doing this is so that "proxy servers can remain stateless for the duration of the call", but I have never heard a reason why this is desirable. (Note that bis-09 defines the term "call-stateful proxy".) Why don't we just admit that it is required in some cases to keep the call state in the proxy and stop trying to invent ways around this, all of which have security and performance problems?

Mike
--part1_f5.1a7959cd.29ef5d68_boundary-- _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@ns.ietf.org Wed Apr 17 19:48:21 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA11197 for ; Wed, 17 Apr 2002 19:48:21 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id TAA27751 for sip-archive@odin.ietf.org; Wed, 17 Apr 2002 19:48:24 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id TAA26292; Wed, 17 Apr 2002 19:22:31 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id TAA26260 for ; Wed, 17 Apr 2002 19:22:27 -0400 (EDT) Received: from imo-r03.mx.aol.com (imo-r03.mx.aol.com [152.163.225.99]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA10734 for ; Wed, 17 Apr 2002 19:22:24 -0400 (EDT) From: Mpierce1@aol.com Received: from Mpierce1@aol.com by imo-r03.mx.aol.com (mail_out_v32.5.) id 7.94.24e62d2e (25511); Wed, 17 Apr 2002 19:21:20 -0400 (EDT) Message-ID: <94.24e62d2e.29ef5d6f@aol.com> Date: Wed, 17 Apr 2002 19:21:19 EDT Subject: Re: Summary of RE: [Sip] Comment, SIP Privacy draft To: hgs@cs.columbia.edu CC: sip@ietf.org MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="part1_94.24e62d2e.29ef5d6f_boundary" X-Mailer: AOL 6.0 for Windows US sub 10524 Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org --part1_94.24e62d2e.29ef5d6f_boundary Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit In a message dated 4/16/02 2:39:47 PM Eastern Daylight Time, hgs@cs.columbia.edu writes: > > [Oran] I think the information that is of relevance to this discussion is > stuff > > that was *NOT* inserted by the user, but was instead inserted by the > > service provider based on things the user had previously disclosed to > > the service provider. These are the things which in fact do need some > > level of protection, which is why we have this complicated > applicability > > statement on the privacy draft and why (I at least) would argue that > the > > only reasonable design is one in which any identifying information > > inserted by the service provider be encrypted or otherwise protected > > from disclosure to other parties (including the callee) unless the > > customer explicitly requests it not to be. > > > > > > > > [Mike Pierce] I think you have to add to the first sentence above "and > information inserted by the user that is required by the > > Service Provider as a prerequisite for service". If the service provider > requires that the user enter a valid ID, then it > > must be protected the same as an ID that the Service Provider inserted. > > [HGS] No reasonable provider should put that requirement on From, for the > reasons Dean mentioned. This leaves the proxy-authentication data. > Interesting question is whether the proxy-authentication data needs to > be stripped after it has been "used", as it may well apply to several > down-stream proxies. > I think this shows how far we are from any agreement on anything. In his e-mail of Apr 15, Dean "mostly" agreed with my statement (although crediting it to Mark). While my statement was "If the service provider requires..." and I believe there have been a number of comments that certain service providers must require this to support mandated tracing, etc., your comment argues that "No reasonable provider should put that requirement on From..." The issue again is what type of "service provider" is being talked about. It is clear that some may require this (a valid ID in From) and some may not. So my statement is true. If it's not the "From" field that must be provided, it is whatever field the discussion ends up with that provides the functionality that many presumed was the purpose of "From". Mike --part1_94.24e62d2e.29ef5d6f_boundary Content-Type: text/html; charset="US-ASCII" Content-Transfer-Encoding: 7bit In a message dated 4/16/02 2:39:47 PM Eastern Daylight Time, hgs@cs.columbia.edu writes:

> [Oran] I think the information that is of relevance to this discussion is stuff
>   that was *NOT* inserted by the user, but was instead inserted by the
>   service provider based on things the user had previously disclosed to
>   the service provider. These are the things which in fact do need some
>   level of protection, which is why we have this complicated applicability
>   statement on the privacy draft and why (I at least) would argue that the
>   only reasonable design is one in which any identifying information
>   inserted by the service provider be encrypted or otherwise protected
>   from disclosure to other parties (including the callee) unless the
>   customer explicitly requests it not to be.
>
>
>
> [Mike Pierce] I think you have to add to the first sentence above "and information inserted by the user that is required by the
> Service Provider as a prerequisite for service". If the service provider requires that the user enter a valid ID, then it
> must be protected the same as an ID that the Service Provider inserted.

[HGS] No reasonable provider should put that requirement on From, for the
reasons Dean mentioned. This leaves the proxy-authentication data.
Interesting question is whether the proxy-authentication data needs to
be stripped after it has been "used", as it may well apply to several
down-stream proxies.

I think this shows how far we are from any agreement on anything. In his e-mail of Apr 15, Dean "mostly" agreed with my statement (although crediting it to Mark).

While my statement was "If the service provider requires..." and I believe there have been a number of comments that certain service providers must require this to support mandated tracing, etc., your comment argues that "No reasonable provider should put that requirement on From..."

The issue again is what type of "service provider" is being talked about. It is clear that some may require this (a valid ID in From) and some may not. So my statement is true. If it's not the "From" field that must be provided, it is whatever field the discussion ends up with that provides the functionality that many presumed was the purpose of "From".

Mike
--part1_94.24e62d2e.29ef5d6f_boundary-- _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@ns.ietf.org Wed Apr 17 20:04:08 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA11491 for ; Wed, 17 Apr 2002 20:04:08 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id UAA28883 for sip-archive@odin.ietf.org; Wed, 17 Apr 2002 20:04:10 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id TAA27515; Wed, 17 Apr 2002 19:40:10 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id TAA27452 for ; Wed, 17 Apr 2002 19:40:04 -0400 (EDT) Received: from pine.neustar.com (pine.neustar.com [209.173.57.70]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA11071; Wed, 17 Apr 2002 19:40:01 -0400 (EDT) Received: from chiimc01.il.neustar.com (chih650b-s3p2.il.neustar.com [209.173.57.65]) by pine.neustar.com (8.11.0/8.11.0) with ESMTP id g3HNdYZ18819; Wed, 17 Apr 2002 18:39:34 -0500 Received: by chiimc01.il.neustar.com with Internet Mail Service (5.5.2653.19) id ; Wed, 17 Apr 2002 18:39:29 -0500 Message-ID: <70565611B164D511957A001083FCDD5601870224@va02.va.neustar.com> From: "Peterson, Jon" To: "'sip@ietf.org'" , "'sipping@ietf.org'" Date: Wed, 17 Apr 2002 18:39:28 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Subject: [Sip] new I-Ds on privacy and identity Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Sorry for the cross-post. I've submitted some new Internet-Drafts on SIP privacy and identity. I hope that these drafts can serve as a good starting point for discussion about long-term cryptographic approaches to privacy and identity that will be generally serviceable for the SIP protocol. As Dean's note to the SIP WG list suggested, they are now available on softarmor. Any comments on the drafts would be appreciated, and I hope we'll have a chance to discuss them at the interim meeting. The abstracts of the two drafts follow: Privacy: This document defines new mechanisms for the Session Initiation Protocol (SIP) in support of privacy. Specifically, guidelines are provided for the creation of messages that do not divulge personal identity information. A new "privacy service" logical role for intermediaries is defined to answer some privacy requirements that user agents cannot satisfy themselves. Finally, means are presented by which a user can request particular functions from a privacy service. Identity: The existing mechanisms for expressing identity in the Session Initiation Protocol do not currently permit an administrative domain to securely verify the identity of the originator of a request. This document recommends practices and conventions for authenticating end users, and proposes a way to distribute secure authenticated identities within SIP messages. Jon Peterson NeuStar, Inc. _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@ns.ietf.org Wed Apr 17 20:13:19 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA11557 for ; Wed, 17 Apr 2002 20:13:18 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id UAA29165 for sip-archive@odin.ietf.org; Wed, 17 Apr 2002 20:13:21 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id TAA27880; Wed, 17 Apr 2002 19:49:59 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id TAA27849 for ; Wed, 17 Apr 2002 19:49:55 -0400 (EDT) Received: from bdsl.66.12.12.130.gte.net (bdsl.66.12.12.130.gte.net [66.12.12.130]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA11245 for ; Wed, 17 Apr 2002 19:49:52 -0400 (EDT) Received: from C1893415A (bdsl.greycouncil.com [127.0.0.1]) by bdsl.66.12.12.130.gte.net (8.11.6/8.11.6) with SMTP id g3HNnNd04510; Wed, 17 Apr 2002 18:49:23 -0500 Message-ID: <041601c1e66a$8391b210$133fed0c@C1893415A> From: "Dean Willis" To: Cc: References: <94.24e62d2e.29ef5d6f@aol.com> Subject: Re: Summary of RE: [Sip] Comment, SIP Privacy draft Date: Wed, 17 Apr 2002 18:49:28 -0500 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0413_01C1E640.9A7EA110" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org This is a multi-part message in MIME format. ------=_NextPart_000_0413_01C1E640.9A7EA110 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable M said: --------- I think this shows how far we are from any agreement on anything. In his = e-mail of Apr 15, Dean "mostly" agreed with my statement (although = crediting it to Mark).=20 -------- whoops, sorry -- I guess I'll stick to initials. Detangling mhtml = postings is hard. M said also: -------- While my statement was "If the service provider requires..." and I = believe there have been a number of comments that certain service = providers must require this to support mandated tracing, etc., your = comment argues that "No reasonable provider should put that requirement = on From..."=20 The issue again is what type of "service provider" is being talked = about. It is clear that some may require this (a valid ID in From) and = some may not. So my statement is true. If it's not the "From" field that = must be provided, it is whatever field the discussion ends up with that = provides the functionality that many presumed was the purpose of "From". = --------- And speaking of discussion, it looks like Jon Peterson just published a = new draft on this very topic. -- Dean ------=_NextPart_000_0413_01C1E640.9A7EA110 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

M said:

---------

I think this shows how far we are from any = agreement on=20 anything. In his e-mail of Apr 15, Dean "mostly" agreed with my = statement=20 (although crediting it to Mark).
--------

whoops, sorry -- I guess I'll stick to initials. = Detangling=20 mhtml postings is hard.

M said also:

--------
While my statement was "If the service provider = requires..."=20 and I believe there have been a number of comments that certain service=20 providers must require this to support mandated tracing, etc., your = comment=20 argues that "No reasonable provider should put that requirement on = From..."=20

The issue again is what type of "service provider" is being = talked=20 about. It is clear that some may require this (a valid ID in From) and = some may=20 not. So my statement is true. If it's not the "From" field that must be=20 provided, it is whatever field the discussion ends up with that provides = the=20 functionality that many presumed was the purpose of "From". =
---------

And speaking of discussion, it looks like Jon Peterson just = published a new=20 draft on this very topic.

--

Dean
------=_NextPart_000_0413_01C1E640.9A7EA110-- _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@ns.ietf.org Wed Apr 17 20:20:43 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA11717 for ; Wed, 17 Apr 2002 20:20:43 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id UAA29474 for sip-archive@odin.ietf.org; Wed, 17 Apr 2002 20:20:45 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id TAA28086; Wed, 17 Apr 2002 19:57:00 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id TAA28055 for ; Wed, 17 Apr 2002 19:56:56 -0400 (EDT) Received: from mail1.dynamicsoft.com (mail1.dynamicsoft.com [63.113.40.10]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA11369 for ; Wed, 17 Apr 2002 19:56:53 -0400 (EDT) Received: from DYN-EXCH-001.dynamicsoft.com (dyn-exch-001 [63.113.44.7]) by mail1.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id g3HNs1DE024890; Wed, 17 Apr 2002 19:54:01 -0400 (EDT) Received: by DYN-EXCH-001.dynamicsoft.com with Internet Mail Service (5.5.2653.19) id <2QA0CDDP>; Wed, 17 Apr 2002 19:56:25 -0400 Message-ID: <9BF66EBF6BEFD942915B4D4D45C051F36B470F@DYN-TX-EXCH-001.dynamicsoft.com> From: Andrew Allen To: "'Rosen, Brian'" , "'sip@ietf.org'" Subject: RE: [Sip] Cookies or State Date: Wed, 17 Apr 2002 19:56:20 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org My vote is for cookie as well - it is more generic and might be used for other applications other than those in the DCS state draft. Andrew > -----Original Message----- > From: Rosen, Brian [mailto:Brian.Rosen@marconi.com] > Sent: Wednesday, April 17, 2002 2:28 PM > To: 'sip@ietf.org' > Subject: [Sip] Cookies or State > > > There are two drafts that define how to save state in a UA > for subsequent > use by a Proxy Server - State and Cookies. > > State is part of the DCS work. Cookies arose when IP assertions were > made against State. Cookies attempted to get around the IP issues > by defining it as exactly like HTTP cookies. To our consternation, > the same IP claims were then made against Cookies! > > We need to get this capability. The question is, should we > base it on State or Cookies? > > In my personal (biased) opinion we are better off with Cookies. > If anyone did want to fight the IP claim, you would clearly > be better off with 75% same language as HTTP cookies. > > Brian > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip > _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@ns.ietf.org Wed Apr 17 20:29:10 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA11808 for ; Wed, 17 Apr 2002 20:29:10 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id UAA29754 for sip-archive@odin.ietf.org; Wed, 17 Apr 2002 20:29:12 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id UAA28444; Wed, 17 Apr 2002 20:00:49 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id UAA28412 for ; Wed, 17 Apr 2002 20:00:45 -0400 (EDT) Received: from bdsl.66.12.12.130.gte.net (bdsl.66.12.12.130.gte.net [66.12.12.130]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA11440 for ; Wed, 17 Apr 2002 20:00:42 -0400 (EDT) Received: from C1893415A (bdsl.greycouncil.com [127.0.0.1]) by bdsl.66.12.12.130.gte.net (8.11.6/8.11.6) with SMTP id g3I008d04586; Wed, 17 Apr 2002 19:00:08 -0500 Message-ID: <042001c1e66c$03c76460$133fed0c@C1893415A> From: "Dean Willis" To: , , References: Subject: Re: [Sip] Cookies or State Date: Wed, 17 Apr 2002 19:00:13 -0500 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_041D_01C1E642.1AAB2BA0" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org This is a multi-part message in MIME format. ------=_NextPart_000_041D_01C1E642.1AAB2BA0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable ----- Original Message -----=20 From: Mpierce1@aol.com=20 I presume the reference for "Cookies" is still = draft-willis-sip-cookies-00 of July 2001. I haven't seen any further = discussion on this draft or responses to the comments I submitted Nov = 19. From that draft, it appears there are significant security concerns = with the use of "Cookies" in a fashion similar to HTTP as proposed in = this draft.=20 State would appear to have fewer security concerns if it is simply a = value stored in the UA for the beniefit of the proxy to fetch and use = later. It is presumed that the lack of a standard definition of this = state value would preclude its use by a different proxy than the one = which stored it (at least by a proxy of a different design).=20 It continues to escape me why it would not be better for the proxy to = simply stored this "state" in its own storage, rather than using every = UA as a distributed storage device. This concept seems to go back to the = days when memory was limited (the first telephone switch I was involved = in designing had 64k bytes of memory!) When one can buy 512M bytes of = memory for less than $100, this should no longer be an issue. The = "state" draft seems to indicate that the only reason for doing this is = so that "proxy servers can remain stateless for the duration of the = call", but I have never heard a reason why this is desirable. (Note that = bis-09 defines the term "call-stateful proxy".) Why don't we just admit = that it is required in some cases to keep the call state in the proxy = and stop trying to invent ways around this, all of which have security = and performance problems?=20 That is the correct reference, although Brian actually edited the draft = based on my rough notes . . . I believe the security concerns are roughly equal -- in both cases, the = UA is given a hunk of stuff that it has to regurgigate on future = messages in this dialog. Both approaches leave the format of the "hunk" open -- it could be = cryptographically protected, just a hash value matching a table stored = on the proxy, or almost anything else. I also believe the security concern is SLIGHTLY less urgent than in = HTTP. As I understand it, both state and cookie drafts indicate a = substantially shorter lifetime for the token. In the case of state, the = lifetime is the duration of the current dialog. In the case of cookie, = it's the current dialog plus any dialog resulting from redirection or = referral of the original dialog.=20 HTTP cookies, on the other hand, persist relatively indefiitely and may = be extracted by any server in the domain of the cookie during any HTTP = interaction with said server for the duraction of the cookie. Now it is certainly true that one COULD put sensitive information in = plain text into a state or cookie token such that other nodes might gain = access to that information. The cookies draft does mention that this is = not a good idea. -- dean ------=_NextPart_000_041D_01C1E642.1AAB2BA0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
----- Original Message -----
From:=20 Mpierce1@aol.com=20

I presume the reference for "Cookies" is still=20 draft-willis-sip-cookies-00 of July 2001. I haven't seen any further=20 discussion on this draft or responses to the comments I submitted Nov = 19. From=20 that draft, it appears there are significant security concerns with = the use of=20 "Cookies" in a fashion similar to HTTP as proposed in this draft.=20

State would appear to have fewer security concerns if it is = simply a=20 value stored in the UA for the beniefit of the proxy to fetch and use = later.=20 It is presumed that the lack of a standard definition of this state = value=20 would preclude its use by a different proxy than the one which stored = it (at=20 least by a proxy of a different design).

It continues to = escape me why=20 it would not be better for the proxy to simply stored this "state" in = its own=20 storage, rather than using every UA as a distributed storage device. = This=20 concept seems to go back to the days when memory was limited (the = first=20 telephone switch I was involved in designing had 64k bytes of memory!) = When=20 one can buy 512M bytes of memory for less than $100, this should no = longer be=20 an issue. The "state" draft seems to indicate that the only reason for = doing=20 this is so that "proxy servers can remain stateless for the duration = of the=20 call", but I have never heard a reason why this is desirable. (Note = that=20 bis-09 defines the term "call-stateful proxy".) Why don't we just = admit that=20 it is required in some cases to keep the call state in the proxy and = stop=20 trying to invent ways around this, all of which have security and = performance=20 problems?

That is the correct reference, although Brian actually edited = the draft=20 based on my rough notes . . .

I believe the security concerns are roughly equal -- in both cases, = the UA is=20 given a hunk of stuff that it has to regurgigate on future messages in = this=20 dialog.

Both approaches leave the format of the "hunk" open -- it could be=20 cryptographically protected, just a hash value matching a table stored = on the=20 proxy, or almost anything else.

I also believe the security concern is SLIGHTLY less urgent than in = HTTP. As=20 I understand it, both state and cookie drafts indicate a substantially = shorter=20 lifetime for the token. In the case of state, the lifetime is the = duration of=20 the current dialog. In the case of cookie, it's the current dialog = plus any=20 dialog resulting from redirection or referral of the original dialog. =

HTTP cookies, on the other hand, persist relatively indefiitely and = may be=20 extracted by any server in the domain of the cookie during any HTTP = interaction=20 with said server for the duraction of the cookie.

Now it is certainly true that one COULD put sensitive information in = plain=20 text into a state or cookie token such that other nodes might gain = access to=20 that information. The cookies draft does mention that this is not a good = idea.

--
dean

------=_NextPart_000_041D_01C1E642.1AAB2BA0-- _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@ns.ietf.org Wed Apr 17 20:40:43 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA11962 for ; Wed, 17 Apr 2002 20:40:43 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id UAA00599 for sip-archive@odin.ietf.org; Wed, 17 Apr 2002 20:40:46 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id UAA29295; Wed, 17 Apr 2002 20:14:49 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id UAA29264 for ; Wed, 17 Apr 2002 20:14:46 -0400 (EDT) Received: from services.dasecurenetworks.com (adsl-64-218-133-75.dsl.rcsntx.swbell.net [64.218.133.75]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA11620 for ; Wed, 17 Apr 2002 20:14:38 -0400 (EDT) Received: from dasecurenetworks.com (main1.localdomain [192.168.0.151]) by services.dasecurenetworks.com (8.11.6/8.9.3) with ESMTP id g3HNikf30646; Wed, 17 Apr 2002 18:44:50 -0500 Message-ID: <3CBE14AA.E954E351@dasecurenetworks.com> Date: Wed, 17 Apr 2002 19:34:50 -0500 From: Chris Martin Reply-To: cmartin@dasecurenetworks.com X-Mailer: Mozilla 4.78 [en] (X11; U; Linux 2.4.7-10enterprise i686) X-Accept-Language: en MIME-Version: 1.0 To: "Chiou, Mark" CC: Dean Willis , Mpierce1@aol.com, sip@ietf.org Subject: Re: Summary of RE: [Sip] Comment, SIP Privacy draft References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit These kinds of questions regarding subject or message body fall into the confidentiality category at that point...which is the next step in providing privacy. The thread to this date has been focusing on identity privacy as seen in the header fields, not the content of the SIP message. I recommend, IMHO, that these items should be addressed separately, and that the initial focus on SIP header privacy (except for the content and related message body) is a good necessary first step to address. The next obvious step should be the idea of confidentiality of the content/message body as well as to the media itself (which I believe is yet another separate issue from teh SIP protocol itself), which I believe will be subject to required regulation when the smoke clears in any event. Confidentiality will of course boil down to the SIPS solution, IPSec possibly, or some other means, but is a separate topic related to the caller/identification privacy. When speaking in terms of privacy provided by a service provider, I believe the act of requesting a UA account to be private to be a customer subscription process separate and not provided as a SIP signaling process. Unless my assumption is incorrect, in the event that it is assumed that SIP will be used as the vehicle to provide the subscription process and that this is the reason why the need for new headers is being pursued within the WG. In that case I understand why this is being pursued but that isnt something that I have seen clearly in the thread. I thought that Mark wanted clear direction for the draft to go, select one of the three choices. The semantics could be hashed out during the progress of the direction chosen. "Chiou, Mark" wrote: > > Coercion <=> consent. > > There is no explicit consent within the signaling of an invidiual > transaction. External contractual issues are outside of the protocol, > and tend to violate the "openness" characteristic of an Internet > protocol. In otherwises, there's a philosophical difference between an > explicit request from the user that a network providing break privacy > for that transaction, and a network that breaks privacy just because I > didn't tell it NOT to. > > Note of course, that we're not talking about PSTN provoders, we're > talking IP to IP usage over the publicaly addressable Internet. > > So, for IP, all the UAs are defaulted to PRIVATE. When a user wishes to make an anonymous calls, SIP needs an indication for the network (i.e. Service Provider) to identify who is calling and translate or retrieve the identity of the calling from the service agreement, then pass the calling identity within the networks without sending the calling identity to the UA of the called party. > > > > Personally, the UA I uset he most writes every last SIP header and the > body to the screen, and copies them all to a log file just in case. One > cannot rely on the called party's software to protect the privacy of the > calling party. > > Agree. So we have to separate the needs for Privacy and the needs for Network, such that the privacy is fully controlled by the UA. On the other hand, the Service Providers have the responsibility to obtain the UA's identify for network usage (i.e. Emergency, Law Enforcement, Call trace, and etc) without breaking the UA's privacy. I means the UA's identity, which is needed by the Network, shall not be delivered to the terminating of the UA. > > Mark Chiou > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@ns.ietf.org Wed Apr 17 21:04:45 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA12309 for ; Wed, 17 Apr 2002 21:04:44 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id VAA01848 for sip-archive@odin.ietf.org; Wed, 17 Apr 2002 21:04:47 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id UAA00571; Wed, 17 Apr 2002 20:37:45 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id UAA00541 for ; Wed, 17 Apr 2002 20:37:42 -0400 (EDT) Received: from services.dasecurenetworks.com (adsl-64-218-133-75.dsl.rcsntx.swbell.net [64.218.133.75]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA11934 for ; Wed, 17 Apr 2002 20:37:38 -0400 (EDT) Received: from dasecurenetworks.com (main1.localdomain [192.168.0.151]) by services.dasecurenetworks.com (8.11.6/8.9.3) with ESMTP id g3I08Af30683; Wed, 17 Apr 2002 19:08:11 -0500 Message-ID: <3CBE1A26.80F57FAC@dasecurenetworks.com> Date: Wed, 17 Apr 2002 19:58:14 -0500 From: Chris Martin Reply-To: cmartin@dasecurenetworks.com X-Mailer: Mozilla 4.78 [en] (X11; U; Linux 2.4.7-10enterprise i686) X-Accept-Language: en MIME-Version: 1.0 To: Christian Huitema CC: sip@ietf.org Subject: Re: Summary of RE: [Sip] Comment, SIP Privacy draft References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit Christian Huitema wrote: > > I have heard many contributors assert that to get real anonymity, one > will have to use a relay, e.g. an "anonymizing B2BUA". I would like to > point out a failure in this line of reasoning: anonymizing relays have > been tried before, for e-mail, and the experience was absolutely not > conclusive. In fact, two different kind of anonymizers have been tried: > free ones, that kept absolutely no record, and subscriber-based, which > kept some records. Both have failed, for different reason. > > The failure mode of a completely free relay is basically spam, and > similar sort of abuse. There is documentation available on the fate for > example of the cypherpunk experiment: this set of relays was set up to > provide true anonymity on the Internet, using a sophisticated mix of > random redirection and cryptography. In theory, the design was > excellent. In practice, the system was quickly overwhelmed by porn > traffic, and the relays dropped one by one out of the system because > they could not bear the resulting congestion. > > Subscriber based relays are relays that keep some state: they actually > identify the sender, before washing out the identity in the outgoing > message. They are more robust to congestion, since they can get some > funding in the process, but they have a different failure mode: lawsuit. > Since they keep some records, the records can be subpoenaed, and the > provider can be forced to disclose the identity of the sending party. In > fact, in many codes, if the providers refuse to do so, they may be > deemed an accomplice of whatever action was carried out in the anonymous > exchange. Many providers have chosen to close their doors rather than > have to defend more lawsuit -- often after a brush with the Church of > Scientology. Privacy, I think, in relation to a service provider is not the same as anonimity to an Internet based user. Privacy is used to mask the original user to the called party, and does not prevent law enforcement from getting the originator of such calls if a law is broken. B2BUA's implemented by an SP need not contain any user account information to provide the level of privacy afforded by the B2BUA (topology hiding) as opposed to the function of privacy which may be implemented by an SP which may alias the users true identity to before sending the packet on to the B2BUA which can then scrub the IP address. You can still track the communication to the SP, but then you must use the proper vehicle to request the proprietary information located in the SP databases to identify the caller. How do SP's of PSTN networks cope with lawsuits today when law enforcement must get this information? I am seriously asking this question not being sarcastic, anyone know the answer? It seems to me that the questions have been answered by the the SPs' of the dinosaurs that we are replacing, we must take some of the lessons learned as a model for answering these questions dont you think? > > If we really want practical anonymity, it has to be based on the UA, and > it should not rely on the help of a third party. We should use a > combination of encryption, pre-paid subscriptions, and anonymous IP > addresses (e.g. IPv6 privacy addresses.) I can see this for publicly non-service provider hosted UA's as a possibility, but for those enterprises, SOHO's serviced by SP's regulations will be developed that require SP's of these types of communications to have more stringent rules and processes. The telecommunications industry today must comply with such regualtions for call traces, wiretaps etc. Every country has some set of regulations that place these requirements on SP's of our particular flavor of communications, which though different from the PSTN world will no doubt adopt many of those same restrictions and regulations for many similar aspects. I am not versed in the regulations or telecommunications but I do know that they exist. Many parties in this list have brought many such examples to the list, which were of great interest to me. I think that implementing it on the UA will be a great idea, and probably will be implemented by many vendors just as NAT and firewall traversal solutions are today, but in the SP realm many of these features will not be required to be active and in many cases will be restricted by policies other than the SP due to the fact that the SP will most likely provide a centralized functin for this service in order to meet regulation as well as to meet security policies implemented by customers of the SP which would look upon such mechanisms as a bypass of such policies, not to mention not very scalable in larger environments. Just my 2 cents Chris > > -- Christian Huitema > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@ns.ietf.org Thu Apr 18 01:59:16 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA18260 for ; Thu, 18 Apr 2002 01:59:16 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id BAA26121 for sip-archive@odin.ietf.org; Thu, 18 Apr 2002 01:59:19 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id BAA25204; Thu, 18 Apr 2002 01:33:57 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id BAA25178 for ; Thu, 18 Apr 2002 01:33:53 -0400 (EDT) Received: from lohi.eng.song.fi (lohi.eng.song.fi [195.10.149.18]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA18105 for ; Thu, 18 Apr 2002 01:33:49 -0400 (EDT) From: jh@lohi.eng.song.fi Received: from harjus.eng.song.fi ([195.10.149.20]) by lohi.eng.song.fi with esmtp (Exim 3.34 #1 (Debian)) id 16y4YH-0005M1-00; Thu, 18 Apr 2002 08:33:49 +0300 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15550.23229.380291.954174@harjus.eng.song.fi> Date: Thu, 18 Apr 2002 08:33:49 +0300 To: Mpierce1@aol.com Cc: hgs@cs.columbia.edu, sip@ietf.org Subject: Re: Summary of RE: [Sip] Comment, SIP Privacy draft In-Reply-To: <94.24e62d2e.29ef5d6f@aol.com> References: <94.24e62d2e.29ef5d6f@aol.com> X-Mailer: VM 7.01 under Emacs 21.1.1 Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit Mpierce1@aol.com writes: > The issue again is what type of "service provider" is being talked > about. It is clear that some may require this (a valid ID in From) > and some may not. to me this is the same thing as verifying the customer's source ip address. we as a service provider DO check that the source ip address of packets that we receive from our subscribers really belong to them. if all service providers would do such checking, dod attacks would be must more easier to trace down. -- juha _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Thu Apr 18 02:35:55 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA27099 for ; Thu, 18 Apr 2002 02:35:54 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id CAA28530 for sip-archive@odin.ietf.org; Thu, 18 Apr 2002 02:35:57 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id CAA27081; Thu, 18 Apr 2002 02:14:08 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id CAA27042 for ; Thu, 18 Apr 2002 02:14:04 -0400 (EDT) Received: from auemail1.firewall.lucent.com (auemail1.lucent.com [192.11.223.161]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA26771 for ; Thu, 18 Apr 2002 02:14:01 -0400 (EDT) Received: from uk0006exch001h.wins.lucent.com (h135-86-160-150.lucent.com [135.86.160.150]) by auemail1.firewall.lucent.com (Switch-2.1.3/Switch-2.1.0) with ESMTP id g3I6DWf21229 for ; Thu, 18 Apr 2002 02:13:32 -0400 (EDT) Received: by uk0006exch001h.uk.lucent.com with Internet Mail Service (5.5.2650.21) id <2GP72ZNV>; Thu, 18 Apr 2002 07:13:31 +0100 Message-ID: <475FF955A05DD411980D00508B6D5FB004CA797F@en0033exch001u.uk.lucent.com> From: "Drage, Keith (Keith)" To: William Marshall , sip@ietf.org Subject: RE: [Sip] z9hG4bK forever ??? Date: Thu, 18 Apr 2002 07:13:29 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Bill's argument breaks down in a few important points. 1) Such a proxy" would not be RFC 3261 compliant. 2) Release 5 does not preclude interworking with other SIP networks. It merely does not specify how it occurs. It does not specify how interworking with R2 might be performed, but I am sure that some wireless network at some point in the future will specify it. The fact that Release 6 might get round to a full specification will not invalidate any proprietary interworking methods. Given the importance that some operators are placing on interworking with enterprise networks, and the fact that most of the enterprise SIP terminals out there are closer to RFC 2543 on this one than to RFC 3261, I do not see it happening. Enterprise terminals also tend to sit around longer than anyone thinks, and even if they are not attached to the network, people still expect to pull them out of the cupboard after a couple of years, plug them into the network, and see them work. 3) In the longer term, with split mobiles, we cannot guarantee that the UA part of the split is RFC 3261 conformant. Similar comments apply to the lifetime of RFC2543 terminals as above. "Short term" in Bill's argument can be 5 years or more. Keith > -----Original Message----- > From: William Marshall [mailto:wtm@research.att.com] > Sent: 17 April 2002 03:48 > To: sip@ietf.org > Subject: [Sip] z9hG4bK forever ??? > > > Subject: was Re: Screened FromL and Privacy > Subject: was Re: Summary of RE: [Sip] Comment, SIP Privacy draft > Subject: was lots of others, too > > All this discussion of proxy modification of the From and To headers, > and the need for a B2BUA, seems to me to be a short-term problem only. > > RFC3261 (2543bis-09) specifies matching of dialog-ids based only > on Call-ID and tags, not on display-name or on addr-spec. So > when all endpoints are compliant with RFC3261, there will be no > problem with a proxy modifying the display-name or addr-spec in > the From header. > > It is only during a transition period, when endpoints that conform > to RFC2543 are supported as well as newer ones. How long will > this be? How long will a proxy need to handle a UAC that doesn't > supply a Contact header? How long will a proxy need to handle > a Record-Route header without the "lr" tag? How long will a > UAS need to handle a BYE received prior to sending 2xx? How long > will the comparison be coded into the proxies and UAs looking > for "z9hG4bK"? > > In all cases, my hope is not too long. And, at the point when > these "conversion aids" no longer need to be present in SIP > implementations, it will be safe for proxies to modify the From > header to provide anonymity, if the subscriber, or the user, or the > regulator, (or others?), says that it should. > > In cases like 3GPP, where (IIRC) release 5 does not include > IMS connections outside of the wireless operator's network, the > problem is even simpler. Since 3GPP required RFC3261 everywhere, > modification of the From header can be done immediately. I would > hope this transition period and the need for "conversion aids" would > be over before 3GPP release 6 is deployed. > > My conclusion from all of this is that 3GPP can require the UE to > insert a valid user identifier in the From header, and the S-CSCF can > change it if privacy is desired, on a session-by-session basis, > based on whatever rules the S-CSCF wants to follow. > > Comments? > > Bill Marshall > wtm@research.att.com > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip > _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Thu Apr 18 02:40:54 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA27207 for ; Thu, 18 Apr 2002 02:40:53 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id CAA28835 for sip-archive@odin.ietf.org; Thu, 18 Apr 2002 02:40:56 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id CAA27219; Thu, 18 Apr 2002 02:16:38 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id CAA27187 for ; Thu, 18 Apr 2002 02:16:35 -0400 (EDT) Received: from mgw-x2.nokia.com (mgw-x2.nokia.com [131.228.20.22]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA26805 for ; Thu, 18 Apr 2002 02:16:31 -0400 (EDT) From: bernhard.honeisen@nokia.com Received: from esvir02nok.ntc.nokia.com (esvir02nokt.ntc.nokia.com [172.21.143.34]) by mgw-x2.nokia.com (Switch-2.2.1/Switch-2.2.0) with ESMTP id g3I6GoF04064 for ; Thu, 18 Apr 2002 09:16:51 +0300 (EET DST) Received: from esebh001.NOE.Nokia.com (unverified) by esvir02nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id for ; Thu, 18 Apr 2002 09:16:31 +0300 Received: from esebe018.NOE.Nokia.com ([172.21.138.57]) by esebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.3779); Thu, 18 Apr 2002 09:16:31 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: [Sip] Correction:SIP Message Draft Fast WGLC Date: Thu, 18 Apr 2002 09:16:31 +0300 Message-ID: Thread-Topic: [Sip] Correction:SIP Message Draft Fast WGLC Thread-Index: AcHiVvIrvlZyf7c8QlW2mKDdzLkBYQESUUpw To: X-OriginalArrivalTime: 18 Apr 2002 06:16:31.0315 (UTC) FILETIME=[9510DA30:01C1E6A0] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id CAA27188 Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 8bit Hi! I have a question related to the message draft: What should be used, if only a URL to the content (e.g. http), but not the content itself is delivered to the receiving UA, so that it is the receiving users decision, whether to download the content of not. This makes sense, if the _bandwidth_is_limited_ and _large_messages_ are sent. This could be even a service (in some network element, e.g. store and forward server) provided to the user, to avoid that the channel down to the user agent gets congested for too long time. Is e.g. the Call-Info header field a good idea? Or should the payload be used for this? Better proposals? cheers, Bernie > -----Original Message----- > From: ext Dean Willis [mailto:dean.willis@softarmor.com] > Sent: 12 April, 2002 22:17 > To: sip@ietf.org > Cc: brian.rosen@maroni.com; rohan@cisco.com; jo@ipdialog.com; > bcampbell@dynamicsoft.com > Subject: [Sip] Correction:SIP Message Draft Fast WGLC > > > > Oops. > > Please review : > > http://www.softarmor.com/sipwg/drafts/draft-ietf-sip-message-02.txt > > Until the -02 makes it into the draft repository. They're not > as fast as > I'm wishing for (ok, light speed is too slow, while we're at it!) > > Thanks, > > -- > Dean > > > Original message: > ------------- > We need to quickly review the SIM Message Method Extension. This draft > has been widely discussed, iterated several times in SIMPLE, and is on > its 2nd revision in SIP. The draft does not appear to be > controversial. > > See: > > http://search.ietf.org/internet-drafts/draft-ietf-sip-message-01.txt > > We expect to move to IETF last call next week, so please raise any > issues immediately. > > Ben Campbell will coordinate for the draft editors. > > ----------------- > > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip > _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Thu Apr 18 02:54:21 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA27392 for ; Thu, 18 Apr 2002 02:54:21 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id CAA29431 for sip-archive@odin.ietf.org; Thu, 18 Apr 2002 02:54:24 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id CAA28351; Thu, 18 Apr 2002 02:32:58 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id CAA28306 for ; Thu, 18 Apr 2002 02:32:54 -0400 (EDT) Received: from lohi.eng.song.fi (lohi.eng.song.fi [195.10.149.18]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA27010 for ; Thu, 18 Apr 2002 02:32:49 -0400 (EDT) From: jh@lohi.eng.song.fi Received: from harjus.eng.song.fi ([195.10.149.20]) by lohi.eng.song.fi with esmtp (Exim 3.34 #1 (Debian)) id 16y5TM-0005N0-00; Thu, 18 Apr 2002 09:32:48 +0300 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15550.26768.853445.970062@harjus.eng.song.fi> Date: Thu, 18 Apr 2002 09:32:48 +0300 To: "Mark Watson" Cc: "'William Marshall'" , sip@ietf.org Subject: RE: [Sip] z9hG4bK forever ??? In-Reply-To: References: X-Mailer: VM 7.01 under Emacs 21.1.1 Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit Mark Watson writes: > The only compromise I can see on this is: > a) Those who want to verify the From: field do > b) Those who don't want to don't > c) In the absence of trust relationships the From: field is completely > untrusted (like everything else!). If you have a trust relationship, then as > part of this you will agree whether From: can be trusted or not. > d) The contents of the From field MAY be modified by devices in the network. > So we should design new services and features with this assumption where > possible the above is consistent with what i have tried to say about this topic and contains nothing new. this whole thread has thus been more or less useless. -- juha _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Thu Apr 18 07:30:54 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA01458 for ; Thu, 18 Apr 2002 07:30:54 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id HAA18127 for sip-archive@odin.ietf.org; Thu, 18 Apr 2002 07:30:56 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id HAA16200; Thu, 18 Apr 2002 07:01:28 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id HAA16076 for ; Thu, 18 Apr 2002 07:01:17 -0400 (EDT) Received: from zctfs063.europe.nortel.com (zctfs063.nortelnetworks.com [47.164.128.120]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA00894 for ; Thu, 18 Apr 2002 07:01:09 -0400 (EDT) Received: from zwcwc012.europe.nortel.com (zwcwc012.europe.nortel.com [47.73.112.187]) by zctfs063.europe.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id g3IB0I021919; Thu, 18 Apr 2002 13:00:19 +0200 (MEST) Received: by zwcwc012.europe.nortel.com with Internet Mail Service (5.5.2653.19) id ; Thu, 18 Apr 2002 12:00:22 +0100 Message-ID: From: "Mark Watson" To: "'Dean Willis'" , William Marshall , sip@ietf.org Subject: RE: [Sip] z9hG4bK forever ??? Date: Thu, 18 Apr 2002 12:00:16 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C1E6C8.38C6BEA2" Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C1E6C8.38C6BEA2 Content-Type: text/plain; charset="iso-8859-1" I think we're about at the end of this one. Two final points from me: 1) Dean's desire to avoid having the From: field mangled unless he has specifically requested it is reasonable. I still think that the subscriber's wishes could overrule this though. This is no different from the ISDN 'Special Arrangement' where the user inserts any number they like in the Calling Party Number field. The network passes it though with no checking, changing, nothing - I think this is analogous to what Dean wants for the From field. But the network still removes this information if the subscriber wants anonymity. The stated purpose of the field is user identity, which implies Personal Data of the subscriber. This is enough to argue that the network must remove it if privacy is required, and this is certainly the application of current legislation to ISDN. What is the stated purpose of the From field - I do not think it is sufficiently different for us to be _sure_ that we can avoid the requirement. So, the munging may still be required, but I certainly agree it should be avoided wherever possible. 2) In formal terms, 'B2BUA == NOT Proxy'. We all know there will be/are devices which behave very much like a proxy, but perform some additional functions, such as these privacy services. This is fine. Everyone should be aware that with only two terms defined 'B2BUA' and 'Proxy', such devices fall into the B2BUA category. ...Mark > -----Original Message----- > From: Dean Willis [mailto:dean.willis@softarmor.com] > Sent: 17 April 2002 17:36 > To: William Marshall; sip@ietf.org > Subject: Re: [Sip] z9hG4bK forever ??? > > > Baill said: > > All this discussion of proxy modification of the From and > To headers, > > and the need for a B2BUA, seems to me to be a short-term > problem only. > > > > RFC3261 (2543bis-09) specifies matching of dialog-ids based only > > on Call-ID and tags, not on display-name or on addr-spec. So > > when all endpoints are compliant with RFC3261, there will be no > > problem with a proxy modifying the display-name or addr-spec in > > the From header. > > I disagree. I don't want the network mangling my user-to-user headers > unless I've specifically requested it to do so. Specifically, the > non-authenticated, non-mangled, non-protected From: field > offers utility > which is DIFFERENT than that provided by network authenticated calling > party ID, and I don't want to sacrifice that utility just because this > is a capability the widely-deployed PSTN (as opposed to say Q.SIG) > didn't have . . . > > -- > Dean > > > > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip > ------_=_NextPart_001_01C1E6C8.38C6BEA2 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [Sip] z9hG4bK forever ???

I think we're about at the end of this one.

Two final points from me:
1) Dean's desire to avoid having the From: field = mangled unless he has specifically requested it is reasonable. I still = think that the subscriber's wishes could overrule this = though.

This is no different from the ISDN 'Special = Arrangement' where the user inserts any number they like in the Calling = Party Number field. The network passes it though with no checking, = changing, nothing - I think this is analogous to what Dean wants for = the From field.

But the network still removes this information if the = subscriber wants anonymity. The stated purpose of the field is user = identity, which implies Personal Data of the subscriber. This is enough = to argue that the network must remove it if privacy is required, and = this is certainly the application of current legislation to = ISDN.

What is the stated purpose of the From field - I do = not think it is sufficiently different for us to be _sure_ that we can = avoid the requirement.

So, the munging may still be required, but I = certainly agree it should be avoided wherever possible.

2) In formal terms, 'B2BUA =3D=3D NOT Proxy'. We all = know there will be/are devices which behave very much like a proxy, but = perform some additional functions, such as these privacy services. This = is fine. Everyone should be aware that with only two terms defined = 'B2BUA' and 'Proxy', such devices fall into the B2BUA = category.

...Mark

> -----Original Message-----
> From: Dean Willis [mailto:dean.willis@softarmor.c= om]
> Sent: 17 April 2002 17:36
> To: William Marshall; sip@ietf.org
> Subject: Re: [Sip] z9hG4bK forever ???
>
>
> Baill said:
> > All this discussion of proxy modification = of the From and
> To headers,
> > and the need for a B2BUA, seems to me to = be a short-term
> problem only.
> >
> > RFC3261 (2543bis-09) specifies matching of = dialog-ids based only
> > on Call-ID and tags, not on display-name = or on addr-spec. So
> > when all endpoints are compliant with = RFC3261, there will be no
> > problem with a proxy modifying the = display-name or addr-spec in
> > the From header.
>
> I disagree. I don't want the network mangling = my user-to-user headers
> unless I've specifically requested it to do so. = Specifically, the
> non-authenticated, non-mangled, non-protected = From: field
> offers utility
> which is DIFFERENT than that provided by = network authenticated calling
> party ID, and I don't want to sacrifice that = utility just because this
> is a capability the widely-deployed PSTN (as = opposed to say Q.SIG)
> didn't have . . .
>
> --
> Dean
>
>
>
>
> = _______________________________________________
> Sip mailing list https://www1.ietf.org/mailman/listinfo/sip
> This list is for NEW development of the core = SIP Protocol
> Use sip-implementors@cs.columbia.edu for = questions on current sip
> Use sipping@ietf.org for new developments on = the application of sip
>

------_=_NextPart_001_01C1E6C8.38C6BEA2-- _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Thu Apr 18 08:34:55 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA02977 for ; Thu, 18 Apr 2002 08:34:54 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id IAA22231 for sip-archive@odin.ietf.org; Thu, 18 Apr 2002 08:34:57 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id IAA20134; Thu, 18 Apr 2002 08:01:15 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id IAA20084 for ; Thu, 18 Apr 2002 08:01:08 -0400 (EDT) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA02082; Thu, 18 Apr 2002 08:01:04 -0400 (EDT) Message-Id: <200204181201.IAA02082@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: sip@ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Date: Thu, 18 Apr 2002 08:01:04 -0400 Subject: [Sip] I-D ACTION:draft-ietf-sip-digest-aka-00.txt Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Session Initiation Protocol Working Group of the IETF. Title : HTTP Digest Authentication Using AKA Author(s) : R. Housley, W. Polk Filename : draft-ietf-sip-digest-aka-00.txt Pages : 17 Date : 17-Apr-02 The Hypertext Transfer Protocol (HTTP) Authentication Framework includes two authentication schemes: Basic and Digest. Both schemes employ a shared secret based mechanism for access authentication. The Authentication and Key Agreement (AKA) mechanism performs user authentication and session key distribution in Universal Mobile Telecommunications System (UMTS) networks. AKA is a challenge- response based mechanism that uses symmetric cryptography. This memo specifies an AKA based one-time password generation mechanism for HTTP Digest access authentication. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-sip-digest-aka-00.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-sip-digest-aka-00.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-sip-digest-aka-00.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <20020417151758.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-sip-digest-aka-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-sip-digest-aka-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20020417151758.I-D@ietf.org> --OtherAccess-- --NextPart-- _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Thu Apr 18 10:06:25 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA06742 for ; Thu, 18 Apr 2002 10:06:24 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id KAA28618 for sip-archive@odin.ietf.org; Thu, 18 Apr 2002 10:06:28 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA23985; Thu, 18 Apr 2002 09:11:36 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA23955 for ; Thu, 18 Apr 2002 09:11:31 -0400 (EDT) Received: from magus.nostrum.com (root@magus.nostrum.com [66.119.225.66]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA04523 for ; Thu, 18 Apr 2002 09:11:26 -0400 (EDT) Received: from txbcampbell (root@magus.nostrum.com [66.119.225.66]) by magus.nostrum.com (8.11.0/8.11.0) with SMTP id g3IDBNX56718; Thu, 18 Apr 2002 08:11:23 -0500 (CDT) From: "Ben Campbell" To: , Subject: RE: [Sip] Correction:SIP Message Draft Fast WGLC Date: Thu, 18 Apr 2002 08:10:57 -0500 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Importance: Normal Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit Hi Bernie, You describe the concept of content indirection. The MESSAGE draft intentionally does not specify that behavior, as it is really a more general problem. It is particularly applicable to NOTIFY, and is probably to _any_ method that can carry a body. Sean Olson recently published a draft collecting requirements for content indirection. I expect work to continue in that are in the near future. > -----Original Message----- > From: sip-admin@ietf.org [mailto:sip-admin@ietf.org]On Behalf Of > bernhard.honeisen@nokia.com > Sent: Thursday, April 18, 2002 1:17 AM > To: sip@ietf.org > Subject: RE: [Sip] Correction:SIP Message Draft Fast WGLC > > > Hi! > > I have a question related to the message draft: > > What should be used, if only a URL to the content (e.g. http), > but not the content itself is delivered to the receiving UA, so > that it is the receiving users decision, whether to download the > content of not. > > This makes sense, if the _bandwidth_is_limited_ > and _large_messages_ are sent. This could be even a service > (in some network element, e.g. store and forward server) > provided to the user, to avoid that the channel down to the > user agent gets congested for too long time. > > Is e.g. the Call-Info header field a good idea? > Or should the payload be used for this? > Better proposals? > > cheers, > Bernie > > > -----Original Message----- > > From: ext Dean Willis [mailto:dean.willis@softarmor.com] > > Sent: 12 April, 2002 22:17 > > To: sip@ietf.org > > Cc: brian.rosen@maroni.com; rohan@cisco.com; jo@ipdialog.com; > > bcampbell@dynamicsoft.com > > Subject: [Sip] Correction:SIP Message Draft Fast WGLC > > > > > > > > Oops. > > > > Please review : > > > > http://www.softarmor.com/sipwg/drafts/draft-ietf-sip-message-02.txt > > > > Until the -02 makes it into the draft repository. They're not > > as fast as > > I'm wishing for (ok, light speed is too slow, while we're at it!) > > > > Thanks, > > > > -- > > Dean > > > > > > Original message: > > ------------- > > We need to quickly review the SIM Message Method Extension. This draft > > has been widely discussed, iterated several times in SIMPLE, and is on > > its 2nd revision in SIP. The draft does not appear to be > > controversial. > > > > See: > > > > http://search.ietf.org/internet-drafts/draft-ietf-sip-message-01.txt > > > > We expect to move to IETF last call next week, so please raise any > > issues immediately. > > > > Ben Campbell will coordinate for the draft editors. > > > > ----------------- > > > > > > _______________________________________________ > > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > > This list is for NEW development of the core SIP Protocol > > Use sip-implementors@cs.columbia.edu for questions on current sip > > Use sipping@ietf.org for new developments on the application of sip > > > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Thu Apr 18 10:21:15 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA07446 for ; Thu, 18 Apr 2002 10:21:15 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id KAA29494 for sip-archive@odin.ietf.org; Thu, 18 Apr 2002 10:21:19 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA27357; Thu, 18 Apr 2002 09:48:02 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA27331 for ; Thu, 18 Apr 2002 09:47:59 -0400 (EDT) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA05954; Thu, 18 Apr 2002 09:47:54 -0400 (EDT) Message-Id: <200204181347.JAA05954@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: sip@ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Date: Thu, 18 Apr 2002 09:47:54 -0400 Subject: [Sip] I-D ACTION:draft-ietf-sip-digest-aka-00.txt Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Session Initiation Protocol Working Group of the IETF. Title : HTTP Digest Authentication Using AKA Author(s) : A. Niemi, J. Arkko, V. Torvinen Filename : draft-ietf-sip-digest-aka-00.txt Pages : 17 Date : 17-Apr-02 The Hypertext Transfer Protocol (HTTP) Authentication Framework includes two authentication schemes: Basic and Digest. Both schemes employ a shared secret based mechanism for access authentication. The Authentication and Key Agreement (AKA) mechanism performs user authentication and session key distribution in Universal Mobile Telecommunications System (UMTS) networks. AKA is a challenge- response based mechanism that uses symmetric cryptography. This memo specifies an AKA based one-time password generation mechanism for HTTP Digest access authentication. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-sip-digest-aka-00.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-sip-digest-aka-00.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-sip-digest-aka-00.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <20020418095520.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-sip-digest-aka-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-sip-digest-aka-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20020418095520.I-D@ietf.org> --OtherAccess-- --NextPart-- _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Thu Apr 18 12:36:52 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA13825 for ; Thu, 18 Apr 2002 12:36:52 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id MAA13923 for sip-archive@odin.ietf.org; Thu, 18 Apr 2002 12:36:55 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA08651; Thu, 18 Apr 2002 11:57:00 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA08618 for ; Thu, 18 Apr 2002 11:56:55 -0400 (EDT) Received: from ierw.net.avaya.com (ierw.net.avaya.com [198.152.13.101]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA11926 for ; Thu, 18 Apr 2002 11:56:50 -0400 (EDT) Received: from ierw.net.avaya.com (localhost [127.0.0.1]) by ierw.net.avaya.com (8.9.3+Sun/8.9.3) with ESMTP id LAA29967 for ; Thu, 18 Apr 2002 11:55:17 -0400 (EDT) Received: from cof110avexu1.global.avaya.com (h135-9-6-16.avaya.com [135.9.6.16]) by ierw.net.avaya.com (8.9.3+Sun/8.9.3) with ESMTP id LAA29955 for ; Thu, 18 Apr 2002 11:55:17 -0400 (EDT) X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: [Sip] z9hG4bK forever ??? Date: Thu, 18 Apr 2002 09:57:35 -0600 Message-ID: Thread-Topic: [Sip] z9hG4bK forever ??? Thread-Index: AcHmpEWT1qN6XoHJQmm1WOCE+nhO8gASRTWw From: "Zmolek, Andrew (Andrew)" To: Cc: Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id LAA08620 Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 8bit > the above is consistent with what i have tried to say about this topic > and contains nothing new. this whole thread has thus been > more or less useless. > > -- juha I couldn't disagree more. Our WG chairs have been enormously patient with the latest batch of rants and tirades on this subject. The quality of discussion has improved measurably since the one-hour RPID rathole in Minneapolis. Since the union of all proposed requirements is the null set, the most effective path forward will of necessity involve difficult compromise against less important requirements in order to satisfy those that will really matter over time. Frankly, Jon Peterson has done an excellent job of taking up this challenge and laying out some concrete proposals to address it. While you are certainly entitled to your opinion, it should be abundantly clear by now that this set of issues is important to many in the sip community and isn't going away just because you would like to dismiss it. Based on list traffic, rough consensus *isn't* saying this is useless and it *isn't* saying we can ignore these issues and move on. --Andy _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Thu Apr 18 15:57:37 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA21207 for ; Thu, 18 Apr 2002 15:57:37 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id PAA28661 for sip-archive@odin.ietf.org; Thu, 18 Apr 2002 15:57:41 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA26701; Thu, 18 Apr 2002 15:28:18 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA26674 for ; Thu, 18 Apr 2002 15:28:15 -0400 (EDT) Received: from mail-blue.research.att.com (H-135-207-30-102.research.att.com [135.207.30.102]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA20185 for ; Thu, 18 Apr 2002 15:28:10 -0400 (EDT) Received: from alliance.research.att.com (alliance.research.att.com [135.207.26.26]) by mail-blue.research.att.com (Postfix) with ESMTP id 227F34CF4C; Thu, 18 Apr 2002 15:28:14 -0400 (EDT) Received: from fish.research.att.com (fish.research.att.com [135.207.27.137]) by alliance.research.att.com (8.8.7/8.8.7) with ESMTP id PAA03735; Thu, 18 Apr 2002 15:28:09 -0400 (EDT) From: William Marshall Received: (from wtm@localhost) by fish.research.att.com (SGI-8.9.3/8.8.5) id PAA61181; Thu, 18 Apr 2002 15:27:51 -0400 (EDT) Date: Thu, 18 Apr 2002 15:27:51 -0400 (EDT) Message-Id: <200204181927.PAA61181@fish.research.att.com> To: Brian.Rosen@marconi.com Cc: sip@ietf.org Subject: [Sip] Re: Cookies or State Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org I don't think the question should be one vs. the other. More a matter of merging the contents. If state is chosen, then the syntax should be changed to be consistent with http cookies, as is recommended in the cookies draft. Also, requirements about sending state tokens for associated calls need to be thought through more carefully. If cookies is chosen, then the "Requires" mechanisms needs to be added, so that a proxy will know whether its cookies will be returned. Also, the rules for UA inserting cookies into requests and responses need to be more carefully defined - the state draft deals with privacy (that ugly word again) concerns about sending cookies when the proxy that needs them is not on the path of the request or response. So I think the real question is which of two paths should be taken, since the destination is the same for both. Bill Marshall wtm@research.att.com -----original message----- From: "Rosen, Brian" To: "'sip@ietf.org'" Date: Wed, 17 Apr 2002 15:27:37 -0400 Subject: [Sip] Cookies or State There are two drafts that define how to save state in a UA for subsequent use by a Proxy Server - State and Cookies. State is part of the DCS work. Cookies arose when IP assertions were made against State. Cookies attempted to get around the IP issues by defining it as exactly like HTTP cookies. To our consternation, the same IP claims were then made against Cookies! We need to get this capability. The question is, should we base it on State or Cookies? In my personal (biased) opinion we are better off with Cookies. If anyone did want to fight the IP claim, you would clearly be better off with 75% same language as HTTP cookies. Brian _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Thu Apr 18 16:09:25 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA21459 for ; Thu, 18 Apr 2002 16:09:25 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id QAA29543 for sip-archive@odin.ietf.org; Thu, 18 Apr 2002 16:09:29 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA27713; Thu, 18 Apr 2002 15:40:31 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA27660 for ; Thu, 18 Apr 2002 15:40:26 -0400 (EDT) Received: from imo-d07.mx.aol.com (imo-d07.mx.aol.com [205.188.157.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA20592 for ; Thu, 18 Apr 2002 15:40:21 -0400 (EDT) From: Mpierce1@aol.com Received: from Mpierce1@aol.com by imo-d07.mx.aol.com (mail_out_v32.5.) id 6.85.1a4bbc3f (4397); Thu, 18 Apr 2002 15:39:48 -0400 (EDT) Message-ID: <85.1a4bbc3f.29f07b04@aol.com> Date: Thu, 18 Apr 2002 15:39:48 EDT Subject: Re: Summary of RE: [Sip] Comment, SIP Privacy draft To: huitema@windows.microsoft.com, sip@ietf.org MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="part1_85.1a4bbc3f.29f07b04_boundary" X-Mailer: AOL 6.0 for Windows US sub 10524 Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org --part1_85.1a4bbc3f.29f07b04_boundary Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit In a message dated 4/15/02 12:15:28 PM Eastern Daylight Time, huitema@windows.microsoft.com writes: > I have heard many contributors assert that to get real anonymity, one > will have to use a relay, e.g. an "anonymizing B2BUA". I would like to > point out a failure in this line of reasoning: anonymizing relays have > been tried before, for e-mail, and the experience was absolutely not > conclusive. In fact, two different kind of anonymizers have been tried: > free ones, that kept absolutely no record, and subscriber-based, which > kept some records. Both have failed, for different reason. > What you said in the rest of the e-mail about the failure of anonymizing B2BUAs sounded pretty "conclusive" to me. (rather than "not conclusive" as you said above). Can we agree that anonymizing B2BUA is not an acceptable answer to any privacy requirements? Mike --part1_85.1a4bbc3f.29f07b04_boundary Content-Type: text/html; charset="US-ASCII" Content-Transfer-Encoding: 7bit In a message dated 4/15/02 12:15:28 PM Eastern Daylight Time, huitema@windows.microsoft.com writes:

I have heard many contributors assert that to get real anonymity, one
will have to use a relay, e.g. an "anonymizing B2BUA". I would like to
point out a failure in this line of reasoning: anonymizing relays have
been tried before, for e-mail, and the experience was absolutely not
conclusive. In fact, two different kind of anonymizers have been tried:
free ones, that kept absolutely no record, and subscriber-based, which
kept some records. Both have failed, for different reason.

What you said in the rest of the e-mail about the failure of anonymizing B2BUAs sounded pretty "conclusive" to me. (rather than "not conclusive" as you said above). Can we agree that anonymizing B2BUA is not an acceptable answer to any privacy requirements?

Mike
--part1_85.1a4bbc3f.29f07b04_boundary-- _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Thu Apr 18 18:55:24 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA24973 for ; Thu, 18 Apr 2002 18:55:24 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id SAA10281 for sip-archive@odin.ietf.org; Thu, 18 Apr 2002 18:55:27 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA09564; Thu, 18 Apr 2002 18:36:16 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA09534 for ; Thu, 18 Apr 2002 18:36:08 -0400 (EDT) Received: from oak.neustar.com (oak.neustar.com [209.173.53.70]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA24739 for ; Thu, 18 Apr 2002 18:36:02 -0400 (EDT) Received: from chiimc01.il.neustar.com (stih650b-s1p2.va.neustar.com [209.173.53.65]) by oak.neustar.com (8.11.0/8.11.0) with ESMTP id g3IMQv809441; Thu, 18 Apr 2002 18:26:57 -0400 Received: by chiimc01.il.neustar.com with Internet Mail Service (5.5.2653.19) id ; Thu, 18 Apr 2002 17:26:52 -0500 Message-ID: <70565611B164D511957A001083FCDD5601870231@va02.va.neustar.com> From: "Peterson, Jon" To: "'Mpierce1@aol.com'" , huitema@windows.microsoft.com, sip@ietf.org Subject: RE: Summary of RE: [Sip] Comment, SIP Privacy draft Date: Thu, 18 Apr 2002 17:26:46 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C1E728.1FCA6330" Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C1E728.1FCA6330 Content-Type: text/plain; charset="iso-8859-1" I wanted to speak to some of these points. I agree that privacy starts with the user agent - populating headers with appropriately private values and so forth. I also agree that getting dynamic, 'anonymous' IP addresses is a way to achieve the privacy that one might otherwise request from an intermediary. I don't agree, however, that this means we should abandon any line of reasoning that uses intermediaries. Although the heyday of penet.fi is long-gone, there are still third-party anonymizer services for SMTP and HTTP in operation today. There are sorts of anonymity that are valuable and which rely on intermediaries. Sometimes, it might not be obvious to users how 'private' their IP addresses are (something you wouldn't want to be wrong about, eh?). Sometimes, users may not have control over how the headers of their messages are populated. Even getting privacy from the same service provider from whom you get SIP registration services makes sense in some cases. If I buy my service from a very large service provider (MSN, say), then simply revealing my service provider is unlikely to reveal my identity - if MSN provided anonymization, I'd feel relatively anonymous using their service. For many sorts of interactions this may be an adequate amount of privacy - sort of like seeing the postmark, with its zip code, on a letter without a return address. Agreed that if the xenuphiles sued MSN for my anonymous wrongdoings, MSN would undoubtedly pony up my name. But if you are doing things with third-party-provided anonymity that will bring legal sanctions against you, then you had better be sure you have a crusading anonymity provider that is willing to become a political prisoner in your stead - even that is, however, not entirely unheard of. So in short, I see no harm in recognizing both anonymous IPs and intermediaries as means to achieve privacy. As it happens, both are mentioned in my new privacy draft. Jon Peterson NeuStar, Inc. -----Original Message----- From: Mpierce1@aol.com [mailto:Mpierce1@aol.com] Sent: Thursday, April 18, 2002 12:40 PM To: huitema@windows.microsoft.com; sip@ietf.org Subject: Re: Summary of RE: [Sip] Comment, SIP Privacy draft In a message dated 4/15/02 12:15:28 PM Eastern Daylight Time, huitema@windows.microsoft.com writes: I have heard many contributors assert that to get real anonymity, one will have to use a relay, e.g. an "anonymizing B2BUA". I would like to point out a failure in this line of reasoning: anonymizing relays have been tried before, for e-mail, and the experience was absolutely not conclusive. In fact, two different kind of anonymizers have been tried: free ones, that kept absolutely no record, and subscriber-based, which kept some records. Both have failed, for different reason. What you said in the rest of the e-mail about the failure of anonymizing B2BUAs sounded pretty "conclusive" to me. (rather than "not conclusive" as you said above). Can we agree that anonymizing B2BUA is not an acceptable answer to any privacy requirements? Mike ------_=_NextPart_001_01C1E728.1FCA6330 Content-Type: text/html; charset="iso-8859-1"

I wanted to speak to some of these points.

I agree that privacy starts with the user agent - populating headers with appropriately private values and so forth. I also agree that getting dynamic, 'anonymous' IP addresses is a way to achieve the privacy that one might otherwise request from an intermediary. I don't agree, however, that this means we should abandon any line of reasoning that uses intermediaries. Although the heyday of penet.fi is long-gone, there are still third-party anonymizer services for SMTP and HTTP in operation today. There are sorts of anonymity that are valuable and which rely on intermediaries. Sometimes, it might not be obvious to users how 'private' their IP addresses are (something you wouldn't want to be wrong about, eh?). Sometimes, users may not have control over how the headers of their messages are populated.

Even getting privacy from the same service provider from whom you get SIP registration services makes sense in some cases. If I buy my service from a very large service provider (MSN, say), then simply revealing my service provider is unlikely to reveal my identity - if MSN provided anonymization, I'd feel relatively anonymous using their service. For many sorts of interactions this may be an adequate amount of privacy - sort of like seeing the postmark, with its zip code, on a letter without a return address. Agreed that if the xenuphiles sued MSN for my anonymous wrongdoings, MSN would undoubtedly pony up my name. But if you are doing things with third-party-provided anonymity that will bring legal sanctions against you, then you had better be sure you have a crusading anonymity provider that is willing to become a political prisoner in your stead - even that is, however, not entirely unheard of.

So in short, I see no harm in recognizing both anonymous IPs and intermediaries as means to achieve privacy. As it happens, both are mentioned in my new privacy draft.

Jon Peterson

NeuStar, Inc.

-----Original Message-----
From: Mpierce1@aol.com [mailto:Mpierce1@aol.com]
Sent: Thursday, April 18, 2002 12:40 PM
To: huitema@windows.microsoft.com; sip@ietf.org
Subject: Re: Summary of RE: [Sip] Comment, SIP Privacy draft

In a message dated 4/15/02 12:15:28 PM Eastern Daylight Time, huitema@windows.microsoft.com writes:

I have heard many contributors assert that to get real anonymity, one
will have to use a relay, e.g. an "anonymizing B2BUA". I would like to
point out a failure in this line of reasoning: anonymizing relays have
been tried before, for e-mail, and the experience was absolutely not
conclusive. In fact, two different kind of anonymizers have been tried:
free ones, that kept absolutely no record, and subscriber-based, which
kept some records. Both have failed, for different reason.

What you said in the rest of the e-mail about the failure of anonymizing B2BUAs sounded pretty "conclusive" to me. (rather than "not conclusive" as you said above). Can we agree that anonymizing B2BUA is not an acceptable answer to any privacy requirements?

Mike

------_=_NextPart_001_01C1E728.1FCA6330-- _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Thu Apr 18 19:32:43 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA25557 for ; Thu, 18 Apr 2002 19:32:43 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id TAA12468 for sip-archive@odin.ietf.org; Thu, 18 Apr 2002 19:32:47 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id TAA11361; Thu, 18 Apr 2002 19:10:14 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id TAA11330 for ; Thu, 18 Apr 2002 19:10:09 -0400 (EDT) Received: from sj-msg-core-3.cisco.com (sj-msg-core-3.cisco.com [171.70.157.152]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA25249 for ; Thu, 18 Apr 2002 19:10:04 -0400 (EDT) Received: from imop.cisco.com (IDENT:mirapoint@imop.cisco.com [171.69.11.44]) by sj-msg-core-3.cisco.com (8.12.2/8.12.2) with ESMTP id g3IN9J2q012394 for ; Thu, 18 Apr 2002 16:09:19 -0700 (PDT) Received: from localhost (ssh-sjc-1.cisco.com [171.68.225.134]) by imop.cisco.com (Mirapoint) with ESMTP id ACX12892; Thu, 18 Apr 2002 16:09:35 -0700 (PDT) Date: Thu, 18 Apr 2002 16:06:40 -0700 (Pacific Daylight Time) From: Rohan Mahy To: sip@ietf.org Message-ID: X-X-Sender: rmahy@imop.cisco.com MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Subject: [Sip] Proposed plan for Network-Asserted ID/Privacy Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Hi, I'd like to propose a concrete plan to move forward with a solution for network-asserted identity and privacy. I'm proposing this as an individual (who is sick of reading about this topic on the mailing list). Below I've listed some of problems that various folks were apparently trying to solve in this space. 1. Provide a Network-Asserted ID a. Within a trusted administrative domain or federation of domains b. For interworking with PSTN mechanisms* c. Usable across administrative boundaries 2. Provide capability for Call Trace a. Within a trusted administrative domain or federation of domains b. For interworking with PSTN mechanisms* c. Usable across administrative boundaries 3. Provide privacy a. by the user directly withholding information from the network b. in the network for user-provided info at the user's request c. in the network for user-provided info based on network policy d. of network-provided information 4. Allow for a user-provided "hint" for Network-Asserted ID *(with gateways in the trusted domain or federation) Most of the snags and disagreements we have had with the existing Remote-Party-ID draft (draft-ietf-sip-privacy-04) are related to problems 1c, 2c, and 4. Even a very scaled-down version of this draft would allow for trusted intermediaries and user agents (including gateways) to exchange network asserted identity and provide the capability for call trace within a domain or federation of trusted domains. The solution is as simple as a single header which carries the identity in clear text, which is added by the first proxy that authenticates the user, and removed before it leaves the trust boundary. This would solve 1a, 1b, 2a, and 2b. Jon Peterson just drafted a Network-Asserted Identity proposal which requires S/MIME signatures on each message. This address the whole category of problems related to 1 and 2 using cryptographic mechanisms. While you could use this mechanism inside trusted networks, the mechanism may be too heavyweight to prove practical for use with every call in every network. However, this is the only proposed mechanism to solve 1c, and 2c in an elegant manner. Jon also took a stab at the "longer-term" privacy requirements. His draft discusses how to solve problems 3a and 3b, and could be extended to support 3d (as proposed in Jon's identity draft). In addition, a network has always been able to introduce an anonymizing B2BUA to solve problem 3c. Finally, we have problem 4. Some folks have proposed that UAs should provide a hint using the same mechanism used to communicate network asserted identity among trusted entities. Others propose that authentication servers that create a network asserted identity accept multiple "usernames" during authentication and use this as the hint. AFAIK these are the only two choices, and we can come up with an answer to this question in a separate thread. The answer does not fundamentally change any of the mechanisms we select to solve the other problems. So, in summary, I'm proposing: No additional work is required to implement 3c Three short term deliverables I) adopt draft-peterson-sip-privacy-longterm as a WG item to solve 3a and 3b II) write an extension to I) as a WG item for requesting privacy of network asserted ID (however it is expressed) to support 3d. This would get used by III and IV. III) pare down the mechanism in draft-ietf-sip-privacy to only address 1a, 1b, 2a, and 2b. quickly get closure on which mechanism we use for 4, and include it in the draft. keep the current applicability statement. One or more longer term deliverables, including IV) draft-peterson-sip-identity ... to address a more general way to solve 1 and 2 including 1c and 2c. Note that this draft is the first step toward providing real cryptographic identity services. I think we also need to address this topic as a charter item. We might also provide an informational document describing how to map privacy and identity between SIP and the PSTN. hope this helps. thanks, -rohan _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@ns.ietf.org Fri Apr 19 00:00:33 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA01497 for ; Fri, 19 Apr 2002 00:00:33 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id AAA25645 for sip-archive@odin.ietf.org; Fri, 19 Apr 2002 00:00:33 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id XAA24832; Thu, 18 Apr 2002 23:37:06 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id XAA24803 for ; Thu, 18 Apr 2002 23:37:01 -0400 (EDT) Received: from wiproecmx2.wipro.com (wiproecmx2.wipro.com [164.164.31.6]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA01241 for ; Thu, 18 Apr 2002 23:36:54 -0400 (EDT) Received: from ecvwall1.wipro.com (venus.easi.soft.net [164.164.23.6]) by wiproecmx2.wipro.com (8.11.3/8.11.3) with SMTP id g3J3aGr27424 for ; Fri, 19 Apr 2002 09:06:16 +0530 (IST) Received: from sreerekha ([192.168.188.203]) by ecmail.mail.wipro.com (Netscape Messaging Server 4.15) with ESMTP id GUSQ0F00.QEP for ; Fri, 19 Apr 2002 09:06:15 +0530 Message-ID: <059901c1e755$351835a0$cbbca8c0@sreerekha> From: "Sreerekha Madhava Shenoy" To: Date: Fri, 19 Apr 2002 09:19:28 +0530 MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_NextPartTM-000-939a1ca1-5321-11d6-a942-00b0d0d06be8" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Subject: [Sip] 'maddr' in Contact Header Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org This is a multi-part message in MIME format. ------=_NextPartTM-000-939a1ca1-5321-11d6-a942-00b0d0d06be8 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit hi We had a doubt about the significance of "maddr" parameter in the Contact header. When the proxy gets the next hop information from the Location Service, should it honour the "maddr" (when present) as the next hop address ? Or should it take the "host" part of the Contact header ? Thanks regards rekha. ------=_NextPartTM-000-939a1ca1-5321-11d6-a942-00b0d0d06be8 Content-Type: text/plain; name="Wipro_Disclaimer.txt" Content-Disposition: attachment; filename="Wipro_Disclaimer.txt" Content-Transfer-Encoding: 7bit **************************Disclaimer************************************ Information contained in this E-MAIL being proprietary to Wipro Limited is 'privileged' and 'confidential' and intended for use only by the individual or entity to which it is addressed. You are notified that any use, copying or dissemination of the information contained in the E-MAIL in any manner whatsoever is strictly prohibited. ******************************************************************** ------=_NextPartTM-000-939a1ca1-5321-11d6-a942-00b0d0d06be8-- _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@ns.ietf.org Fri Apr 19 05:04:04 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA13966 for ; Fri, 19 Apr 2002 05:04:04 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id FAA25121 for sip-archive@odin.ietf.org; Fri, 19 Apr 2002 05:04:06 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id EAA22406; Fri, 19 Apr 2002 04:29:00 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id EAA22329 for ; Fri, 19 Apr 2002 04:28:52 -0400 (EDT) Received: from ns.unisa.it (ns.unisa.it [193.205.160.3]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA13394; Fri, 19 Apr 2002 04:28:49 -0400 (EDT) From: loretosa@vizzavi.it Received: from eeu1itc02904 (alina.diiie.unisa.it [193.205.164.67]) by ns.unisa.it (8.12.0/8.12.0) with SMTP id g3J8DH1Y003379; Fri, 19 Apr 2002 10:13:25 +0200 (MET DST) Message-ID: <00c801c1e77a$468ac350$43a4cdc1@eeu1itc02904> To: , Date: Fri, 19 Apr 2002 10:14:48 +0200 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_00C5_01C1E78B.09591CF0" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4807.1700 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4807.1700 Subject: [Sip] status Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org This is a multi-part message in MIME format. ------=_NextPart_000_00C5_01C1E78B.09591CF0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable hi all, where it's possible find the status of not renewed and the cause... of the inclusion in other draft as draft-sip-rfc2543 thanks sal ------=_NextPart_000_00C5_01C1E78B.09591CF0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

hi all,

where it's possible find the status of = not=20 renewed and the cause...

of the inclusion in other draft as = draft-sip-rfc2543

thanks

sal

------=_NextPart_000_00C5_01C1E78B.09591CF0-- _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@ns.ietf.org Fri Apr 19 05:17:32 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA14153 for ; Fri, 19 Apr 2002 05:17:31 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id FAA25600 for sip-archive@odin.ietf.org; Fri, 19 Apr 2002 05:17:33 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id EAA24348; Fri, 19 Apr 2002 04:55:34 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id EAA24307 for ; Fri, 19 Apr 2002 04:55:28 -0400 (EDT) Received: from bt0g2p.god.bel.alcatel.be (alc250.alcatel.be [195.207.101.250]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA13855 for ; Fri, 19 Apr 2002 04:55:25 -0400 (EDT) Received: from btm16s.se.bel.alcatel.be (relay3 [127.0.0.1]) by bt0g2p.god.bel.alcatel.be (8.11.0/8.11.4) with ESMTP id g3J8reO06946 for ; Fri, 19 Apr 2002 10:53:40 +0200 Received: from se.bel.alcatel.be (s12design13.alcatel.com.tr [138.203.41.29]) by btm16s.se.bel.alcatel.be (8.8.8+Sun/8.8.8+SUN) with ESMTP id KAA02862 for ; Fri, 19 Apr 2002 10:54:50 +0200 (MET DST) Message-ID: <3CBFD503.4CAF2A80@se.bel.alcatel.be> Date: Fri, 19 Apr 2002 11:27:47 +0300 From: Hatice ORBAY Organization: Alcatel X-Mailer: Mozilla 4.5 [en] (X11; I; SunOS 5.6 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: sip Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [Sip] ACK for 4xx in response to OPTIONS Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit Hello, If a response to OPTIONS request is an 4xx message (420 or 486 etc...), then does the UAS wait for an ACK from Proxy ? Or not, ACK is only a part of the INVITE transaction? Thanks in advance, Hatice S. Orbay _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@ns.ietf.org Fri Apr 19 05:53:32 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA14636 for ; Fri, 19 Apr 2002 05:53:32 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id FAA27403 for sip-archive@odin.ietf.org; Fri, 19 Apr 2002 05:53:34 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id FAA25775; Fri, 19 Apr 2002 05:23:22 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id FAA25747 for ; Fri, 19 Apr 2002 05:23:18 -0400 (EDT) Received: from zctfs063.europe.nortel.com (zctfs063.nortelnetworks.com [47.164.128.120]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA14261 for ; Fri, 19 Apr 2002 05:23:11 -0400 (EDT) Received: from znsgs01r.europe.nortel.com (znsgs01r.europe.nortel.com [47.137.129.92]) by zctfs063.europe.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id g3J9MfU08929; Fri, 19 Apr 2002 11:22:41 +0200 (MEST) Received: from zwcwc012.europe.nortel.com (zwcwc012.europe.nortel.com [47.73.112.187]) by znsgs01r.europe.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id g3J9M1v06106; Fri, 19 Apr 2002 10:22:01 +0100 (BST) Received: by zwcwc012.europe.nortel.com with Internet Mail Service (5.5.2653.19) id ; Fri, 19 Apr 2002 10:22:43 +0100 Message-ID: From: "Mark Watson" To: "'Rohan Mahy'" , sip@ietf.org Subject: RE: [Sip] Proposed plan for Network-Asserted ID/Privacy Date: Fri, 19 Apr 2002 10:22:36 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C1E783.B107EF06" Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C1E783.B107EF06 Content-Type: text/plain Good plan. I agree. ...Mark > -----Original Message----- > From: Rohan Mahy [mailto:rohan@cisco.com] > Sent: 19 April 2002 00:07 > To: sip@ietf.org > Subject: [Sip] Proposed plan for Network-Asserted ID/Privacy > > > Hi, > > I'd like to propose a concrete plan to move forward with a > solution for > network-asserted identity and privacy. I'm proposing this as an > individual (who is sick of reading about this topic on the mailing > list). Below I've listed some of problems that various folks were > apparently trying to solve in this space. > > 1. Provide a Network-Asserted ID > a. Within a trusted administrative domain or federation of domains > b. For interworking with PSTN mechanisms* > c. Usable across administrative boundaries > > 2. Provide capability for Call Trace > a. Within a trusted administrative domain or federation of domains > b. For interworking with PSTN mechanisms* > c. Usable across administrative boundaries > > 3. Provide privacy > a. by the user directly withholding information from the network > b. in the network for user-provided info at the user's request > c. in the network for user-provided info based on network policy > d. of network-provided information > > 4. Allow for a user-provided "hint" for Network-Asserted ID > > *(with gateways in the trusted domain or federation) > > Most of the snags and disagreements we have had with the existing > Remote-Party-ID draft (draft-ietf-sip-privacy-04) are related > to problems > 1c, 2c, and 4. Even a very scaled-down version of this draft > would allow > for trusted intermediaries and user agents (including gateways) to > exchange network asserted identity and provide the capability for call > trace within a domain or federation of trusted domains. The > solution is > as simple as a single header which carries the identity in clear text, > which is added by the first proxy that authenticates the user, and > removed before it leaves the trust boundary. This would solve > 1a, 1b, 2a, and 2b. > > Jon Peterson just drafted a Network-Asserted Identity proposal which > requires S/MIME signatures on each message. This address the whole > category of problems related to 1 and 2 using cryptographic > mechanisms. > While you could use this mechanism inside trusted networks, the > mechanism may be too heavyweight to prove practical for use with every > call in every network. However, this is the only proposed mechanism > to solve 1c, and 2c in an elegant manner. > > Jon also took a stab at the "longer-term" privacy > requirements. His draft > discusses how to solve problems 3a and 3b, and could be extended to > support 3d (as proposed in Jon's identity draft). In > addition, a network > has always been able to introduce an anonymizing B2BUA to > solve problem > 3c. > > Finally, we have problem 4. Some folks have proposed that > UAs should provide a hint using the same mechanism used to > communicate network asserted identity among trusted entities. > Others propose that authentication servers that create a > network asserted identity accept multiple "usernames" during > authentication and use this as the hint. AFAIK these are the > only two choices, and we can come up with an answer to this > question in a separate thread. The answer does not fundamentally > change any of the mechanisms we select to solve the other problems. > > So, in summary, I'm proposing: > > No additional work is required to implement 3c > > Three short term deliverables > I) adopt draft-peterson-sip-privacy-longterm as a WG item to solve > 3a and 3b > > II) write an extension to I) as a WG item for requesting privacy of > network asserted ID (however it is expressed) to support 3d. > This would > get used by III and IV. > > III) pare down the mechanism in draft-ietf-sip-privacy to > only address 1a, > 1b, 2a, and 2b. quickly get closure on which mechanism we > use for 4, and > include it in the draft. keep the current applicability statement. > > One or more longer term deliverables, including > IV) draft-peterson-sip-identity ... to address a more general way to > solve 1 and 2 including 1c and 2c. Note that this draft is the first > step toward providing real cryptographic identity services. > I think we > also need to address this topic as a charter item. > > We might also provide an informational document describing how to map > privacy and identity between SIP and the PSTN. > > hope this helps. > thanks, > -rohan > > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip > ------_=_NextPart_001_01C1E783.B107EF06 Content-Type: text/html RE: [Sip] Proposed plan for Network-Asserted ID/Privacy

Good plan. I agree.

...Mark

> -----Original Message-----
> From: Rohan Mahy [mailto:rohan@cisco.com]
> Sent: 19 April 2002 00:07
> To: sip@ietf.org
> Subject: [Sip] Proposed plan for Network-Asserted ID/Privacy
>
>
> Hi,
>
> I'd like to propose a concrete plan to move forward with a
> solution for
> network-asserted identity and privacy. I'm proposing this as an
> individual (who is sick of reading about this topic on the mailing
> list). Below I've listed some of problems that various folks were
> apparently trying to solve in this space.
>
> 1. Provide a Network-Asserted ID
> a.   Within a trusted administrative domain or federation of domains
> b.   For interworking with PSTN mechanisms*
> c.   Usable across administrative boundaries
>
> 2. Provide capability for Call Trace
> a.   Within a trusted administrative domain or federation of domains
> b.   For interworking with PSTN mechanisms*
> c.   Usable across administrative boundaries
>
> 3. Provide privacy
> a.   by the user directly withholding information from the network
> b.   in the network for user-provided info at the user's request
> c.   in the network for user-provided info based on network policy
> d.   of network-provided information
>
> 4. Allow for a user-provided "hint" for Network-Asserted ID
>
> *(with gateways in the trusted domain or federation)
>
> Most of the snags and disagreements we have had with the existing
> Remote-Party-ID draft (draft-ietf-sip-privacy-04) are related
> to problems
> 1c, 2c, and 4. Even a very scaled-down version of this draft
> would allow
> for trusted intermediaries and user agents (including gateways) to
> exchange network asserted identity and provide the capability for call
> trace within a domain or federation of trusted domains. The
> solution is
> as simple as a single header which carries the identity in clear text,
> which is added by the first proxy that authenticates the user, and
> removed before it leaves the trust boundary. This would solve
> 1a, 1b, 2a, and 2b.
>
> Jon Peterson just drafted a Network-Asserted Identity proposal which
> requires S/MIME signatures on each message. This address the whole
> category of problems related to 1 and 2 using cryptographic
> mechanisms.
> While you could use this mechanism inside trusted networks, the
> mechanism may be too heavyweight to prove practical for use with every
> call in every network. However, this is the only proposed mechanism
> to solve 1c, and 2c in an elegant manner.
>
> Jon also took a stab at the "longer-term" privacy
> requirements. His draft
> discusses how to solve problems 3a and 3b, and could be extended to
> support 3d (as proposed in Jon's identity draft). In
> addition, a network
> has always been able to introduce an anonymizing B2BUA to
> solve problem
> 3c.
>
> Finally, we have problem 4. Some folks have proposed that
> UAs should provide a hint using the same mechanism used to
> communicate network asserted identity among trusted entities.
> Others propose that authentication servers that create a
> network asserted identity accept multiple "usernames" during
> authentication and use this as the hint. AFAIK these are the
> only two choices, and we can come up with an answer to this
> question in a separate thread. The answer does not fundamentally
> change any of the mechanisms we select to solve the other problems.
>
> So, in summary, I'm proposing:
>
> No additional work is required to implement 3c
>
> Three short term deliverables
> I) adopt draft-peterson-sip-privacy-longterm as a WG item to solve
>    3a and 3b
>
> II) write an extension to I) as a WG item for requesting privacy of
> network asserted ID (however it is expressed) to support 3d.
> This would
> get used by III and IV.
>
> III) pare down the mechanism in draft-ietf-sip-privacy to
> only address 1a,
> 1b, 2a, and 2b. quickly get closure on which mechanism we
> use for 4, and
> include it in the draft. keep the current applicability statement.
>
> One or more longer term deliverables, including
> IV) draft-peterson-sip-identity ... to address a more general way to
> solve 1 and 2 including 1c and 2c. Note that this draft is the first
> step toward providing real cryptographic identity services.
> I think we
> also need to address this topic as a charter item.
>
> We might also provide an informational document describing how to map
> privacy and identity between SIP and the PSTN.
>
> hope this helps.
> thanks,
> -rohan
>
>
> _______________________________________________
> Sip mailing list https://www1.ietf.org/mailman/listinfo/sip
> This list is for NEW development of the core SIP Protocol
> Use sip-implementors@cs.columbia.edu for questions on current sip
> Use sipping@ietf.org for new developments on the application of sip
>

------_=_NextPart_001_01C1E783.B107EF06-- _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@ns.ietf.org Fri Apr 19 06:11:48 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA15062 for ; Fri, 19 Apr 2002 06:11:47 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id GAA29453 for sip-archive@odin.ietf.org; Fri, 19 Apr 2002 06:11:50 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id FAA26586; Fri, 19 Apr 2002 05:33:54 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id FAA26556 for ; Fri, 19 Apr 2002 05:33:51 -0400 (EDT) Received: from shardagate.mahindrabt.com ([206.102.1.162]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA14368 for ; Fri, 19 Apr 2002 05:33:43 -0400 (EDT) Received: from mahindrabt.com (mailscan.sharda.mahindrabt.com [10.5.0.97]) by shardagate.mahindrabt.com (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id PAA09555 for ; Fri, 19 Apr 2002 15:03:43 +0530 X-SMTP-Sending-IP: 10.5.0.15 Received: from intranet.sharda.mahindrabt.com by mahindrabt.com ; 19 Apr 2002 15:00:18 +0530 Received: from mahindrabt.com ([10.5.4.79]) by intranet.sharda.mahindrabt.com (8.9.3/8.9.3) with ESMTP id PAA22912; Fri, 19 Apr 2002 15:03:36 +0530 Message-ID: <3CBFE3F8.55E711C1@mahindrabt.com> Date: Fri, 19 Apr 2002 15:01:36 +0530 From: Ajit Kalele X-Mailer: Mozilla 4.73 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 To: Hatice ORBAY CC: sip Subject: Re: [Sip] ACK for 4xx in response to OPTIONS References: <3CBFD503.4CAF2A80@se.bel.alcatel.be> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit For 3xx+ responses ACK is part of the INVITE transaction, only for 2xx response its not a part of INVITE transaction. Also, for responses to requests other than INVITE, ACK is not sent. Ajit Hatice ORBAY wrote: > Hello, > If a response to OPTIONS request is an 4xx message (420 or 486 etc...), > then does the UAS wait for an ACK from Proxy ? Or not, ACK is only a > part of the INVITE transaction? > > Thanks in advance, > Hatice S. Orbay > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip ********************************************************* Disclaimer This message (including any attachments) contains confidential information intended for a specific individual and purpose, and is protected by law. If you are not the intended recipient, you should delete this message and are hereby notified that any disclosure, copying, or distribution of this message, or the taking of any action based on it, is strictly prohibited. ********************************************************* Visit us at http://www.mahindrabt.com _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@ns.ietf.org Fri Apr 19 06:12:22 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA15085 for ; Fri, 19 Apr 2002 06:12:22 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id GAA29495 for sip-archive@odin.ietf.org; Fri, 19 Apr 2002 06:12:24 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id FAA26908; Fri, 19 Apr 2002 05:41:01 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id FAA26872 for ; Fri, 19 Apr 2002 05:40:58 -0400 (EDT) Received: from albatross.wise.edt.ericsson.se (albatross-ext.wise.edt.ericsson.se [193.180.251.49]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA14495 for ; Fri, 19 Apr 2002 05:40:54 -0400 (EDT) Received: from fogerty.lmf.ericsson.se (fogerty.lmf.ericsson.se [131.160.11.6]) by albatross.wise.edt.ericsson.se (8.12.1/8.12.1/WIREfire-1.4) with ESMTP id g3J9eo3G011005; Fri, 19 Apr 2002 11:40:50 +0200 (MEST) Received: from lmf.ericsson.se (3OQK900K04BAB3K.lmf.ericsson.se [131.160.30.12]) by fogerty.lmf.ericsson.se (8.12.1/8.12.1/lmf.8.12.1.jcs) with ESMTP id g3J9eoo5022696; Fri, 19 Apr 2002 12:40:50 +0300 (EET DST) Message-ID: <3CBFE629.E81518C3@lmf.ericsson.se> Date: Fri, 19 Apr 2002 12:40:57 +0300 From: Christer Holmberg X-Mailer: Mozilla 4.74 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Hatice ORBAY CC: sip Subject: Re: [Sip] ACK for 4xx in response to OPTIONS References: <3CBFD503.4CAF2A80@se.bel.alcatel.be> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit Hi, ACK is used with INVITEs ONLY. It may, or may not, depending on the status code in the response, be part of the INVITE transaction itself, or a separate transaction. See the spec for more details... Regards, Christer Holmberg Ericsson Finland Hatice ORBAY wrote: > Hello, > If a response to OPTIONS request is an 4xx message (420 or 486 etc...), > then does the UAS wait for an ACK from Proxy ? Or not, ACK is only a > part of the INVITE transaction? > > Thanks in advance, > Hatice S. Orbay > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@ns.ietf.org Fri Apr 19 07:46:54 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA16611 for ; Fri, 19 Apr 2002 07:46:54 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id HAA04108 for sip-archive@odin.ietf.org; Fri, 19 Apr 2002 07:46:55 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id HAA02706; Fri, 19 Apr 2002 07:23:27 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id HAA02678 for ; Fri, 19 Apr 2002 07:23:19 -0400 (EDT) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA16051; Fri, 19 Apr 2002 07:23:15 -0400 (EDT) Message-Id: <200204191123.HAA16051@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: sip@ietf.org, simple@mailman.dynamicsoft.com From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Date: Fri, 19 Apr 2002 07:23:15 -0400 Subject: [Sip] I-D ACTION:draft-ietf-sip-message-03.txt Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Session Initiation Protocol Working Group of the IETF. Title : Session Initiation Protocol Extension for Instant Messaging Author(s) : B. Campbell, J. Rosenberg Filename : draft-ietf-sip-message-03.txt Pages : 19 Date : 18-Apr-02 Instant Messageing (IM) refers to the transfer of messages between users in near real-time. These messages are usually, but not required to be, short. IMs are often used in a conversational mode, that is, the transfer of messages back and forth is fast enough for participants to maintain an interactive conversation. The MESSAGE method is an extension to the Session Initation Protocol (SIP) that allows the transfer of Instant Messages. MESSAGE requests carry the content in the form of MIME body parts. MESSAGE requests do not themselves initiate a SIP dialog; under normal usage each Instant Message stands alone, much like pager messages. MESSAGE requests may be sent in the context of a dialog initiated by some other SIP request. Since the MESSAGE request is an extension to SIP it inherits all the request routing and security features of that protocol. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-sip-message-03.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-sip-message-03.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-sip-message-03.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <20020418141051.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-sip-message-03.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-sip-message-03.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20020418141051.I-D@ietf.org> --OtherAccess-- --NextPart-- _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Fri Apr 19 07:53:55 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA16744 for ; Fri, 19 Apr 2002 07:53:55 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id HAA04337 for sip-archive@odin.ietf.org; Fri, 19 Apr 2002 07:53:56 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id HAA02572; Fri, 19 Apr 2002 07:22:38 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id HAA02526 for ; Fri, 19 Apr 2002 07:22:30 -0400 (EDT) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA15901; Fri, 19 Apr 2002 07:22:28 -0400 (EDT) Message-Id: <200204191122.HAA15901@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; CC: sip@ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Date: Fri, 19 Apr 2002 07:22:28 -0400 Subject: [Sip] I-D ACTION:draft-peterson-sip-identity-00.txt Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : Enhancements for Authenticated Identity Management in the Session Initiation Protocol (SIP) Author(s) : J. Peterson Filename : draft-peterson-sip-identity-00.txt Pages : 25 Date : 18-Apr-02 The existing mechanisms for expressing identity in the Session Initiation Protocol oftentimes do not permit an administrative domain to verify securely the identity of the originator of a request. This document recommends practices and conventions for authenticating end users, and proposes a way to distribute secure authenticated identities within SIP messages. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-peterson-sip-identity-00.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-peterson-sip-identity-00.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-peterson-sip-identity-00.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <20020418140905.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-peterson-sip-identity-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-peterson-sip-identity-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20020418140905.I-D@ietf.org> --OtherAccess-- --NextPart-- _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Fri Apr 19 07:54:00 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA16761 for ; Fri, 19 Apr 2002 07:54:00 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id HAA04352 for sip-archive@odin.ietf.org; Fri, 19 Apr 2002 07:54:01 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id HAA02522; Fri, 19 Apr 2002 07:22:25 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id HAA02491 for ; Fri, 19 Apr 2002 07:22:20 -0400 (EDT) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA15868; Fri, 19 Apr 2002 07:22:18 -0400 (EDT) Message-Id: <200204191122.HAA15868@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; CC: sip@ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Date: Fri, 19 Apr 2002 07:22:18 -0400 Subject: [Sip] I-D ACTION:draft-peterson-sip-privacy-longterm-00.txt Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : A Privacy Mechanism for the Session Initiation Protocol (SIP) Author(s) : J. Peterson Filename : draft-peterson-sip-privacy-longterm-00.txt Pages : 26 Date : 18-Apr-02 This document defines new mechanisms for the Session Initiation Protocol (SIP) in support of privacy. Specifically, guidelines are provided for the creation of messages that do not divulge personal identity information. A new 'privacy service' logical role for intermediaries is defined to answer some privacy requirements that user agents cannot satisfy themselves. Finally, means are presented by which a user can request particular functions from a privacy service. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-peterson-sip-privacy-longterm-00.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-peterson-sip-privacy-longterm-00.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-peterson-sip-privacy-longterm-00.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <20020418140839.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-peterson-sip-privacy-longterm-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-peterson-sip-privacy-longterm-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20020418140839.I-D@ietf.org> --OtherAccess-- --NextPart-- _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@ns.ietf.org Fri Apr 19 10:12:16 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA20727 for ; Fri, 19 Apr 2002 10:12:16 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id KAA12011 for sip-archive@odin.ietf.org; Fri, 19 Apr 2002 10:12:15 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA09082; Fri, 19 Apr 2002 09:30:59 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id XAA24876 for ; Thu, 18 Apr 2002 23:37:59 -0400 (EDT) Received: from hotmail.com (f232.law10.hotmail.com [64.4.15.232]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA01257 for ; Thu, 18 Apr 2002 23:37:55 -0400 (EDT) Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Thu, 18 Apr 2002 20:37:28 -0700 Received: from 202.142.77.67 by lw10fd.law10.hotmail.msn.com with HTTP; Fri, 19 Apr 2002 03:37:28 GMT X-Originating-IP: [202.142.77.67] From: "ROOPA RAO" To: sip@ietf.org Date: Fri, 19 Apr 2002 09:07:28 +0530 Mime-Version: 1.0 Content-Type: text/plain; format=flowed Message-ID: X-OriginalArrivalTime: 19 Apr 2002 03:37:28.0801 (UTC) FILETIME=[87B28510:01C1E753] Subject: [Sip] Queries regd. SIP Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Hello, I am new to SIP and have been trying to learn more about it since I would like to work on a project in this area. I have some very basic queries in this. Any help would be greatly appreciated. I would like to know what exactly are the applications/ uses of this SIP protocol. I know that it can be used for Internet Telephony applications but i am not clear as to if i build some product/software on this who are the likely customers/ what is the market. Also when there are so many open source codes and applications available for free on the internet why should anyone build similar sort of applications ? Please let me know where i can get more information on such issues. Thanks, R.P. _________________________________________________________________ Chat with friends online, try MSN Messenger: http://messenger.msn.com _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@ns.ietf.org Fri Apr 19 10:33:44 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA21654 for ; Fri, 19 Apr 2002 10:33:44 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id KAA14106 for sip-archive@odin.ietf.org; Fri, 19 Apr 2002 10:33:46 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA10676; Fri, 19 Apr 2002 09:53:19 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA10633 for ; Fri, 19 Apr 2002 09:53:15 -0400 (EDT) Received: from sj-msg-core-1.cisco.com (sj-msg-core-1.cisco.com [171.71.163.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA20001 for ; Fri, 19 Apr 2002 09:53:12 -0400 (EDT) Received: from nisser.cisco.com (nisser.cisco.com [171.71.176.85]) by sj-msg-core-1.cisco.com (8.12.2/8.12.2) with ESMTP id g3JDqipG011246; Fri, 19 Apr 2002 06:52:44 -0700 (PDT) Received: from cisco.com (rtp-vpn2-541.cisco.com [10.82.242.29]) by nisser.cisco.com (8.8.6 (PHNE_14041)/CISCO.SERVER.1.2) with ESMTP id GAA01616; Fri, 19 Apr 2002 06:52:43 -0700 (PDT) Message-ID: <3CC0212A.9403A39D@cisco.com> Date: Fri, 19 Apr 2002 09:52:42 -0400 From: Flemming Andreasen X-Mailer: Mozilla 4.79 [en]C-CCK-MCD (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Rohan Mahy CC: sip@ietf.org Subject: Re: [Sip] Proposed plan for Network-Asserted ID/Privacy References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit Rohan Mahy wrote: > Hi, > > I'd like to propose a concrete plan to move forward with a solution for > network-asserted identity and privacy. I'm proposing this as an > individual (who is sick of reading about this topic on the mailing > list). Below I've listed some of problems that various folks were > apparently trying to solve in this space. > > 1. Provide a Network-Asserted ID > a. Within a trusted administrative domain or federation of domains > b. For interworking with PSTN mechanisms* > c. Usable across administrative boundaries > > 2. Provide capability for Call Trace > a. Within a trusted administrative domain or federation of domains > b. For interworking with PSTN mechanisms* > c. Usable across administrative boundaries > > 3. Provide privacy > a. by the user directly withholding information from the network > b. in the network for user-provided info at the user's request > c. in the network for user-provided info based on network policy > d. of network-provided information > > 4. Allow for a user-provided "hint" for Network-Asserted ID > > *(with gateways in the trusted domain or federation) > > Most of the snags and disagreements we have had with the existing > Remote-Party-ID draft (draft-ietf-sip-privacy-04) are related to problems > 1c, 2c, and 4. Even a very scaled-down version of this draft would allow > for trusted intermediaries and user agents (including gateways) to > exchange network asserted identity and provide the capability for call > trace within a domain or federation of trusted domains. The solution is > as simple as a single header which carries the identity in clear text, > which is added by the first proxy that authenticates the user, and > removed before it leaves the trust boundary. You need to be more clear. 1 and 2 talk about administrative domains and administrative boundaries and now you are talking about trust boundaries. How do you define an administrative domain, an administrative boundary, and a trust boundary ? > This would solve > 1a, 1b, 2a, and 2b. No. The UA is (normally) untrusted but still needs it. If you were only talking about the case when privacy was requested, then it doesn't address the requirement to provide call trace for anonymous calls. The user is obviously untrusted and hence cannot be given the caller-id in clear-text. The privacy draft solves this by handing out an encrypted Remote-Party-Id which can subsequently be used for call trace (as well as other features for that matter, e.g. anonymous call return). > > Finally, we have problem 4. Some folks have proposed that > UAs should provide a hint using the same mechanism used to > communicate network asserted identity among trusted entities. > Others propose that authentication servers that create a > network asserted identity accept multiple "usernames" during > authentication and use this as the hint. AFAIK these are the > only two choices, and we can come up with an answer to this > question in a separate thread. The answer does not fundamentally > change any of the mechanisms we select to solve the other problems. Well it certainly impacts it. If you go with the first solution then you also accept that Remote-Party-Id can be provided by an untrusted entity, so I don't think we can solve these independently. > > > So, in summary, I'm proposing: > > No additional work is required to implement 3c > > Three short term deliverables > I) adopt draft-peterson-sip-privacy-longterm as a WG item to solve > 3a and 3b > It's unclear that 3b is independent of which mechanism you choose to provide the hint above. > > II) write an extension to I) as a WG item for requesting privacy of > network asserted ID (however it is expressed) to support 3d. This would > get used by III and IV. > > III) pare down the mechanism in draft-ietf-sip-privacy to only address 1a, > 1b, 2a, and 2b. quickly get closure on which mechanism we use for 4, and > include it in the draft. keep the current applicability statement. > As mentioned above, I'm not clear on exactly what 1a, 1b, 2a and 2b are, but if the "network asserted identity" draft would neither address privacy for network asserted identity, nor call trace for anonymous calls, then I certainly disagree with this. -- Flemming _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@ns.ietf.org Fri Apr 19 10:43:45 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA22010 for ; Fri, 19 Apr 2002 10:43:45 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id KAA14665 for sip-archive@odin.ietf.org; Fri, 19 Apr 2002 10:43:48 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA11875; Fri, 19 Apr 2002 10:08:48 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA11843 for ; Fri, 19 Apr 2002 10:08:44 -0400 (EDT) Received: from relay3.softcomca.com ([168.144.1.70]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA20537 for ; Fri, 19 Apr 2002 10:08:41 -0400 (EDT) Received: from m2w098.softcomca.com ([168.144.108.98]) by relay3.softcomca.com with Microsoft SMTPSVC(5.0.2195.4905); Fri, 19 Apr 2002 10:08:42 -0400 X-Originating-IP: 12.107.104.81 X-URL: http://www.mail2web.com/ Subject: RE: [Sip] Queries regd. SIP From: "ranjitka@email.masconit.com" Date: Fri, 19 Apr 2002 10:08:42 -0400 To: "roopa_k_rao@hotmail.com" , "sip@ietf.org" Reply-To: ranjitka@email.masconit.com X-Priority: 3 X-MSMail-Priority: Normal MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" X-Mailer: JMail 3.7.0 by Dimac (www.dimac.net) Message-ID: X-OriginalArrivalTime: 19 Apr 2002 14:08:42.0674 (UTC) FILETIME=[B648E920:01C1E7AB] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from Quoted-Printable to 8bit by optimus.ietf.org id KAA11844 Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 8bit Hi Roopa, As u said SIP is mainly used in VoIP. It can be used in conjunction with other protocols like MGCP, RADIUS, COPS etc to build applications in Iternet telephony. U can know more about latest happenings in SIP at http://www.sipcentre.com HTH Regards Ranjit Original Message: ----------------- From: ROOPA RAO roopa_k_rao@hotmail.com Date: Thu, 18 Apr 2002 22:37:28 -0500 To: sip@ietf.org Subject: [Sip] Queries regd. SIP Hello, I am new to SIP and have been trying to learn more about it since I would like to work on a project in this area. I have some very basic queries in this. Any help would be greatly appreciated. I would like to know what exactly are the applications/ uses of this SIP protocol. I know that it can be used for Internet Telephony applications but i am not clear as to if i build some product/software on this who are the likely customers/ what is the market. Also when there are so many open source codes and applications available for free on the internet why should anyone build similar sort of applications ? Please let me know where i can get more information on such issues. Thanks, R.P. _________________________________________________________________ Chat with friends online, try MSN Messenger: http://messenger.msn.com _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip -------------------------------------------------------------------- mail2web - Check your email from the web at http://mail2web.com/ . _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@ns.ietf.org Fri Apr 19 11:27:24 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA23690 for ; Fri, 19 Apr 2002 11:27:24 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id LAA18856 for sip-archive@odin.ietf.org; Fri, 19 Apr 2002 11:27:26 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA15060; Fri, 19 Apr 2002 10:48:27 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA15029 for ; Fri, 19 Apr 2002 10:48:23 -0400 (EDT) Received: from dgesmtp02.wcom.com (dgesmtp02.wcom.com [199.249.16.17]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA22122 for ; Fri, 19 Apr 2002 10:48:20 -0400 (EDT) Received: from CONVERSION-DAEMON by firewall.wcom.com (PMDF V5.2-33 #42261) id <0GUT00L01L2Z0R@firewall.wcom.com> for sip@ietf.org; Fri, 19 Apr 2002 14:47:24 +0000 (GMT) Received: from dgismtp02.wcomnet.com ([166.38.58.142]) by firewall.wcom.com (PMDF V5.2-33 #42261) with ESMTP id <0GUT00K5IL2ZAA@firewall.wcom.com>; Fri, 19 Apr 2002 14:47:23 +0000 (GMT) Received: from dgismtp02.wcomnet.com by dgismtp02.wcomnet.com (PMDF V5.2-33 #42263) with SMTP id <0GUT00201L2SWK@dgismtp02.wcomnet.com>; Fri, 19 Apr 2002 14:47:23 +0000 (GMT) Received: from hsinnreich2 ([166.35.224.250]) by dgismtp02.wcomnet.com (PMDF V5.2-33 #42263) with ESMTP id <0GUT001B3L2G8H@dgismtp02.wcomnet.com>; Fri, 19 Apr 2002 14:47:06 +0000 (GMT) Date: Fri, 19 Apr 2002 09:47:04 -0500 From: Henry Sinnreich Subject: RE: [Sip] Queries regd. SIP In-reply-to: To: "'ROOPA RAO'" , sip@ietf.org Message-id: <000c01c1e7b1$12ff3f70$fae023a6@hsinnreich2> Organization: WorldCom, Inc. MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 X-Mailer: Microsoft Outlook, Build 10.0.3416 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7bit Importance: Normal X-Priority: 3 (Normal) X-MSMail-priority: Normal Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit > I would like to know what exactly are the applications/ uses > of this SIP protocol. Please see the white papers at www.sipforum.org Thanks, Henry > -----Original Message----- > From: sip-admin@ietf.org [mailto:sip-admin@ietf.org] On > Behalf Of ROOPA RAO > Sent: Thursday, April 18, 2002 10:37 PM > To: sip@ietf.org > Subject: [Sip] Queries regd. SIP > > > Hello, > > I am new to SIP and have been trying to learn more about > it since I would like to work on a project in this area. > > I have some very basic queries in this. Any help would be greatly > appreciated. > > I would like to know what exactly are the applications/ uses > of this SIP protocol. I know that it can be used for Internet > Telephony applications but i am not clear as to if i build > some product/software on this who are > the likely customers/ what is the market. > > Also when there are so many open source codes and > applications available for > free on the internet why should anyone build similar > sort of applications ? > > Please let me know where i can get more information on such issues. > > Thanks, > R.P. > > > > > > > _________________________________________________________________ > Chat with friends online, try MSN Messenger: http://messenger.msn.com > > > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current > sip Use sipping@ietf.org for new developments on the > application of sip > _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@ns.ietf.org Fri Apr 19 12:00:35 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA25239 for ; Fri, 19 Apr 2002 12:00:35 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id MAA21952 for sip-archive@odin.ietf.org; Fri, 19 Apr 2002 12:00:38 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA18653; Fri, 19 Apr 2002 11:25:03 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA18595 for ; Fri, 19 Apr 2002 11:24:58 -0400 (EDT) Received: from auemail1.firewall.lucent.com (auemail1.lucent.com [192.11.223.161]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA23533; Fri, 19 Apr 2002 11:24:54 -0400 (EDT) Received: from ih2mail.ih.lucent.com (h135-1-241-39.lucent.com [135.1.241.39]) by auemail1.firewall.lucent.com (Switch-2.1.3/Switch-2.1.0) with ESMTP id g3JFOPL02911; Fri, 19 Apr 2002 11:24:26 -0400 (EDT) Received: from lucent.com by ih2mail.ih.lucent.com (8.8.8+Sun/EMS-1.5 sol2) id KAA07438; Fri, 19 Apr 2002 10:24:24 -0500 (CDT) Message-ID: <3CC03681.2060701@lucent.com> Date: Fri, 19 Apr 2002 10:23:45 -0500 From: "Vijay K. Gurbani" Organization: Lucent Technologies, Inc./Bell Laboratories User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:0.9.4) Gecko/20011128 Netscape6/6.2.1 X-Accept-Language: en-us MIME-Version: 1.0 To: SIP LIST , SIPPING LIST , SPIRITS list , pint@lists.bell-labs.com Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [Sip] SIP support for IN services Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit Folks: Enclosed is an I-D for review that describes SIP support for IN services. The I-D represents agreement of the IETF SIN (SIP/IN) design team and is intended for publication as an informational RFC. It has been through Last Call in the IETF SIN DT and the comments of the WGs identified in the To list of this email are now being solicited. http://search.ietf.org/internet-drafts/draft-gurbani-sin-00.txt Thanks, - vijay -- Vijay K. Gurbani vkg@{lucent.com,research.bell-labs.com,acm.org} Wireless Networks Group/Internet Software and eServices Lucent Technologies/Bell Labs Innovations, 2000 Lucent Lane, Rm 6G-440 Naperville, Illinois 60566 Voice: +1 630 224 0216 _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@ns.ietf.org Fri Apr 19 12:35:42 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA00201 for ; Fri, 19 Apr 2002 12:35:42 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id MAA24798 for sip-archive@odin.ietf.org; Fri, 19 Apr 2002 12:35:42 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA20877; Fri, 19 Apr 2002 11:51:54 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA20775 for ; Fri, 19 Apr 2002 11:51:45 -0400 (EDT) Received: from zctfs063.europe.nortel.com (zctfs063.nortelnetworks.com [47.164.128.120]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA24711 for ; Fri, 19 Apr 2002 11:51:41 -0400 (EDT) Received: from zwcwc012.europe.nortel.com (zwcwc012.europe.nortel.com [47.73.112.187]) by zctfs063.europe.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id g3JFp2m11848; Fri, 19 Apr 2002 17:51:02 +0200 (MEST) Received: by zwcwc012.europe.nortel.com with Internet Mail Service (5.5.2653.19) id ; Fri, 19 Apr 2002 16:51:02 +0100 Message-ID: From: "Mark Watson" To: "'Flemming Andreasen'" , Rohan Mahy Cc: sip@ietf.org Subject: Problem 4 of RE: [Sip] Proposed plan for Network-Asserted ID/Priv acy Date: Fri, 19 Apr 2002 16:50:59 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C1E7B9.92F15EA4" Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C1E7B9.92F15EA4 Content-Type: text/plain Rohan suggested a separate thread for... > > 4. Allow for a user-provided "hint" for Network-Asserted ID > > > > Finally, we have problem 4. Some folks have proposed that > > UAs should provide a hint using the same mechanism used to > > communicate network asserted identity among trusted entities. > > > Others propose that authentication servers that create a > > > network asserted identity accept multiple "usernames" during > > > authentication and use this as the hint. AFAIK these are the > > only two choices, and we can come up with an answer to this > > question in a separate thread. The answer does not fundamentally > > change any of the mechanisms we select to solve the other problems. > > Well it certainly impacts it. If you go with the first > solution then you also > accept that Remote-Party-Id can be provided by an untrusted > entity, so I don't > think we can solve these independently. I diagree. Solve the other problems first. Then we have three choices: 1) Use the same header for the 'hints' 2) Define another header for the 'hints' 3) Assume the 'hint' in in the authentication 'username' If you choose (1), then you may need something extra in that header to distinguish between the two use-cases. ...Mark ------_=_NextPart_001_01C1E7B9.92F15EA4 Content-Type: text/html Problem 4 of RE: [Sip] Proposed plan for Network-Asserted ID/Privacy

Rohan suggested a separate thread for...

> > 4. Allow for a user-provided "hint" for Network-Asserted ID
<snip>
> >
> > Finally, we have problem 4. Some folks have proposed that
> > UAs should provide a hint using the same mechanism used to
> > communicate network asserted identity among trusted entities.
>
> > Others propose that authentication servers that create a
>
> > network asserted identity accept multiple "usernames" during
>
> > authentication and use this as the hint. AFAIK these are the
> > only two choices, and we can come up with an answer to this
> > question in a separate thread. The answer does not fundamentally
> > change any of the mechanisms we select to solve the other problems.
>
> Well it certainly impacts it. If you go with the first
> solution then you also
> accept that Remote-Party-Id can be provided by an untrusted
> entity, so I don't
> think we can solve these independently.

I diagree. Solve the other problems first. Then we have three choices:
1) Use the same header for the 'hints'
2) Define another header for the 'hints'
3) Assume the 'hint' in in the authentication 'username'

If you choose (1), then you may need something extra in that header to distinguish between the two use-cases.

...Mark

------_=_NextPart_001_01C1E7B9.92F15EA4-- _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@ns.ietf.org Fri Apr 19 13:03:17 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA04268 for ; Fri, 19 Apr 2002 13:03:12 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id NAA26242 for sip-archive@odin.ietf.org; Fri, 19 Apr 2002 13:03:13 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA23819; Fri, 19 Apr 2002 12:27:17 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA23790 for ; Fri, 19 Apr 2002 12:27:14 -0400 (EDT) Received: from penguin.wise.edt.ericsson.se (penguin-ext.wise.edt.ericsson.se [193.180.251.47]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA28839 for ; Fri, 19 Apr 2002 12:27:10 -0400 (EDT) Received: from fogerty.lmf.ericsson.se (fogerty.lmf.ericsson.se [131.160.11.6]) by penguin.wise.edt.ericsson.se (8.12.1/8.12.1/WIREfire-1.4) with ESMTP id g3JGPxsv009899; Fri, 19 Apr 2002 18:27:07 +0200 (MEST) Received: from lmf.ericsson.se (EF5DM00K04BAV71.lmf.ericsson.se [131.160.30.98]) by fogerty.lmf.ericsson.se (8.12.1/8.12.1/lmf.8.12.1.jcs) with ESMTP id g3JDsTo5007424; Fri, 19 Apr 2002 16:54:40 +0300 (EET DST) Message-ID: <3CC01072.E2430CFE@lmf.ericsson.se> Date: Fri, 19 Apr 2002 15:41:22 +0300 From: Gonzalo Camarillo X-Mailer: Mozilla 4.74 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Juan-Carlos.Rojas@alcatel.fr CC: sip@ietf.org References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [Sip] Re: Manyfolks using SPDng Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit Hi Juan Carlos, There is not, as far as I know. However, it would be better to get the necessary implementation experience with manyfolks and SDP, and once we obtain this experience, elaborate a mechanism for SDPng. Regards, Gonzalo Juan-Carlos.Rojas@alcatel.fr wrote: > > Hello Gonzalo, > > Is there any project to create an internet-draft (or to update the existing > one) for the preconditions mechanism currently defined in the manyfolks > draft, but using SDPng (and so, XML based) ? > > Thank you for your answer > > Best regards > Juan Carlos -- Gonzalo Camarillo Phone : +358 9 299 33 71 Oy L M Ericsson Ab Mobile: +358 40 702 35 35 Telecom R&D Fax : +358 9 299 30 52 FIN-02420 Jorvas Email : Gonzalo.Camarillo@ericsson.com Finland http://www.hut.fi/~gonzalo _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@ns.ietf.org Fri Apr 19 13:20:00 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA06129 for ; Fri, 19 Apr 2002 13:19:58 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id NAA27440 for sip-archive@odin.ietf.org; Fri, 19 Apr 2002 13:19:59 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA25401; Fri, 19 Apr 2002 12:51:29 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA25367 for ; Fri, 19 Apr 2002 12:51:22 -0400 (EDT) Received: from lohi.eng.song.fi (lohi.eng.song.fi [195.10.149.18]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA02659 for ; Fri, 19 Apr 2002 12:51:20 -0400 (EDT) From: jh@lohi.eng.song.fi Received: from harjus.eng.song.fi ([195.10.149.20]) by lohi.eng.song.fi with esmtp (Exim 3.34 #1 (Debian)) id 16ybbO-0006ER-00; Fri, 19 Apr 2002 19:51:14 +0300 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15552.19202.335763.284871@harjus.eng.song.fi> Date: Fri, 19 Apr 2002 19:51:14 +0300 To: "Mark Watson" Cc: "'Flemming Andreasen'" , Rohan Mahy , sip@ietf.org Subject: Problem 4 of RE: [Sip] Proposed plan for Network-Asserted ID/Priv acy In-Reply-To: References: X-Mailer: VM 7.01 under Emacs 21.1.1 Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit Mark Watson writes: > I diagree. Solve the other problems first. Then we have three choices: > 1) Use the same header for the 'hints' > 2) Define another header for the 'hints' > 3) Assume the 'hint' in in the authentication 'username' (3) doesn't work. my username is jh@song.fi, but my from uri that i want to use, can be, for example, tel+358441234567. today i'm using the from uri as the hint, which works fine if the user is not requesting anonymity. if the user is requesting anonymity and the call goes to another sip user, then either a b2bua or a new "hint" header, such as really-from, is needed. -- juha _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@ns.ietf.org Fri Apr 19 13:50:30 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA10312 for ; Fri, 19 Apr 2002 13:50:29 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id NAA29839 for sip-archive@odin.ietf.org; Fri, 19 Apr 2002 13:50:31 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA27646; Fri, 19 Apr 2002 13:21:50 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA27618 for ; Fri, 19 Apr 2002 13:21:46 -0400 (EDT) Received: from mail5.microsoft.com (mail5.microsoft.com [131.107.3.121]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA06463 for ; Fri, 19 Apr 2002 13:21:44 -0400 (EDT) Received: from inet-vrs-05.redmond.corp.microsoft.com ([157.54.6.148]) by mail5.microsoft.com with Microsoft SMTPSVC(5.0.2195.4905); Fri, 19 Apr 2002 10:20:33 -0700 Received: from 157.54.6.197 by inet-vrs-05.redmond.corp.microsoft.com (InterScan E-Mail VirusWall NT); Fri, 19 Apr 2002 10:21:14 -0700 Received: from red-imc-04.redmond.corp.microsoft.com ([157.54.2.168]) by inet-hub-06.redmond.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.4905); Fri, 19 Apr 2002 10:20:36 -0700 Received: from win-imc-02.wingroup.windeploy.ntdev.microsoft.com ([157.54.0.84]) by red-imc-04.redmond.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.2966); Fri, 19 Apr 2002 10:20:35 -0700 Received: from win-msg-02.wingroup.windeploy.ntdev.microsoft.com ([157.54.0.134]) by win-imc-02.wingroup.windeploy.ntdev.microsoft.com with Microsoft SMTPSVC(6.0.3590.0); Fri, 19 Apr 2002 10:17:38 -0700 Content-Class: urn:content-classes:message Subject: RE: Problem 4 of RE: [Sip] Proposed plan for Network-Asserted ID/Privacy MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Date: Fri, 19 Apr 2002 10:17:36 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.0.6177.0 Message-ID: Thread-Topic: Problem 4 of RE: [Sip] Proposed plan for Network-Asserted ID/Privacy thread-index: AcHnwhQS4gS86VXHQJGNFxeeAMRz1gABARgQ From: "Christian Huitema" To: , "Mark Watson" Cc: "Flemming Andreasen" , "Rohan Mahy" , X-OriginalArrivalTime: 19 Apr 2002 17:17:38.0414 (UTC) FILETIME=[1AE990E0:01C1E7C6] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id NAA27619 Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 8bit > > I diagree. Solve the other problems first. Then we have three choices: > > 1) Use the same header for the 'hints' > > 2) Define another header for the 'hints' > > 3) Assume the 'hint' in in the authentication 'username' > > (3) doesn't work. my username is jh@song.fi, but my from uri that i > want to use, can be, for example, tel+358441234567. In fact, e-mail today uses two different fields: the "SMTP From:" parameter defines who is posting the message, and the "From:" field defines the user who is supposed to get the replies. (OK, there is also a "sender" field, when someone sends a message "on behalf" of other user(s), but we won't get there.) By this logic, we would need a "SIP From", identifying the account sending the message, in addition to the current "From" field, wich identifies the user. -- Christian Huitema _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@ns.ietf.org Fri Apr 19 15:13:33 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA20766 for ; Fri, 19 Apr 2002 15:13:33 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id PAA04515 for sip-archive@odin.ietf.org; Fri, 19 Apr 2002 15:13:35 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA02896; Fri, 19 Apr 2002 14:38:33 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA02865 for ; Fri, 19 Apr 2002 14:38:28 -0400 (EDT) Received: from mail1.dynamicsoft.com (mail1.dynamicsoft.com [63.113.40.10]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA15729 for ; Fri, 19 Apr 2002 14:38:25 -0400 (EDT) Received: from DYN-EXCH-001.dynamicsoft.com (dyn-exch-001 [63.113.44.7]) by mail1.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id g3JIZHDE009284; Fri, 19 Apr 2002 14:35:18 -0400 (EDT) Received: by DYN-EXCH-001.dynamicsoft.com with Internet Mail Service (5.5.2653.19) id <2QA0CKF8>; Fri, 19 Apr 2002 14:37:43 -0400 Message-ID: <9BF66EBF6BEFD942915B4D4D45C051F377A067@DYN-TX-EXCH-001.dynamicsoft.com> From: Adam Roach To: "'Elwell, John'" , "'patrick.mourot@online.fr'" , Robert Sparks , sip@ietf.org Subject: RE: [Sip] REFER security options - removing Referred-By Date: Fri, 19 Apr 2002 14:37:38 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Why is such information useful if it's unauthenticated? Are you planning to use it to implement policy? If so, inclusion of such a header only sets a trap for naive implementors. If not, are you envisioning this information will be presented to users? If that's your goal, you'll want to do something that works with deployed phones. As a convention (and I'm not proposing that this be standardized), you could obtain the desired effect with something like: INVITE sip:bob@example.com SIP/2.0 From: "Adam Roach forwarded by Robert Sparks" ;tag=12397 ... Right? I feel quite strongly that we should *not* include this sort of information in the current REFER draft, and work on providing an *authenticated* version of this draft at a later date. /a > -----Original Message----- > From: Elwell, John [mailto:John.Elwell@siemenscomms.co.uk] > Sent: Wednesday, April 10, 2002 1:51 > To: 'patrick.mourot@online.fr'; rsparks@dynamicsoft.com; sip@ietf.org > Subject: RE: [Sip] REFER security options - removing Referred-By > > > I agree with what Patrick Mourot says. Let's have a basic > refer capability > that provides an unsecured identity of A to C, and then leave > it to C to > decide whether and how to verify the identity of A. This will > depend on > whether it is attended or unattended transfer - with attended > transfer the > call A-C will exist and will be identified by the Replaces > header. This may > be sufficient, but if not, verification can be done in the > context of that > dialog A-C. > > --------------------------------------------------------------- > John Elwell (john.elwell@siemenscomms.co.uk) > Siemens Communications Limited, > --------------------------------------------------------------- > Internet communications are not secure and therefore Siemens > Communications Limited does not accept legal responsibility for the > contents of this message. Any views or opinions presented are solely > those of the author and do not necessarily represent those of Siemens > Communications Limited unless otherwise specifically stated. > > > > -----Original Message----- > From: patrick.mourot@online.fr [mailto:patrick.mourot@online.fr] > Sent: Tuesday, April 09, 2002 5:05 PM > To: rsparks@dynamicsoft.com; sip@ietf.org > Subject: RE: [Sip] REFER security options - removing Referred-By > > > > Sirs, > > I think there are plainty of cases where C : > -will not need to know that the call was started by A read in > Referred-By > -or will trust B (i.e: intranet cases). > > Protecting Referred-By also means protecting others headers. > > This means that we should avoid all solutions that are not optional > regarding C > policy. > > A VERIFYing approach starting at C is better suited; It > allows C to decide > to > verify or not A identity. > If C does NOT want to or does NOT support VERIFY the call > flows remains > consistent with current behavior. > > PS: Referred-By is a means for carrying some useful Information. > > That's my 2 cents. > > Best Regards, > > Patrick > > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip > _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@ns.ietf.org Fri Apr 19 15:14:12 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA20812 for ; Fri, 19 Apr 2002 15:14:12 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id PAA04552 for sip-archive@odin.ietf.org; Fri, 19 Apr 2002 15:14:14 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA03370; Fri, 19 Apr 2002 14:51:27 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA03339 for ; Fri, 19 Apr 2002 14:51:24 -0400 (EDT) Received: from Mitel.COM ([216.191.234.70]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA17715 for ; Fri, 19 Apr 2002 14:51:21 -0400 (EDT) From: Tom_Gray@Mitel.COM Received: from kanmta01.mitel.com (kanmta01.kanata.mitel.com [134.199.37.58]) by Mitel.COM (V8/MAIL-RELAY-2.1) with ESMTP id OAA10776; Fri, 19 Apr 2002 14:49:35 -0400 (EDT) Subject: RE: [Sip] REFER security options - removing Referred-By To: Adam Roach Cc: "'Elwell, John'" , "'patrick.mourot@online.fr'" , Robert Sparks , sip@ietf.org Date: Fri, 19 Apr 2002 14:49:33 -0400 Message-ID: X-MIMETrack: Serialize by Router on kanmta01/Mitel(Release 5.0.7 |March 21, 2001) at 04/19/2002 02:49:34 PM MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org The information could be useful because C could authenticate the identity outside of the SIP protocol if that is felt necesary. In many cases such authentication is not required. There can be other means extra-protocol of dealing with abusive callers. Adam Roach @ietf.org on 04/19/2002 02:37:38 PM Sent by: sip-admin@ietf.org To: "'Elwell, John'" , "'patrick.mourot@online.fr'" , Robert Sparks , sip@ietf.org cc: Subject: RE: [Sip] REFER security options - removing Referred-By Why is such information useful if it's unauthenticated? Are you planning to use it to implement policy? If so, inclusion of such a header only sets a trap for naive implementors. If not, are you envisioning this information will be presented to users? If that's your goal, you'll want to do something that works with deployed phones. As a convention (and I'm not proposing that this be standardized), you could obtain the desired effect with something like: INVITE sip:bob@example.com SIP/2.0 From: "Adam Roach forwarded by Robert Sparks" ;tag=12397 ... Right? I feel quite strongly that we should *not* include this sort of information in the current REFER draft, and work on providing an *authenticated* version of this draft at a later date. /a > -----Original Message----- > From: Elwell, John [mailto:John.Elwell@siemenscomms.co.uk] > Sent: Wednesday, April 10, 2002 1:51 > To: 'patrick.mourot@online.fr'; rsparks@dynamicsoft.com; sip@ietf.org > Subject: RE: [Sip] REFER security options - removing Referred-By > > > I agree with what Patrick Mourot says. Let's have a basic > refer capability > that provides an unsecured identity of A to C, and then leave > it to C to > decide whether and how to verify the identity of A. This will > depend on > whether it is attended or unattended transfer - with attended > transfer the > call A-C will exist and will be identified by the Replaces > header. This may > be sufficient, but if not, verification can be done in the > context of that > dialog A-C. > > --------------------------------------------------------------- > John Elwell (john.elwell@siemenscomms.co.uk) > Siemens Communications Limited, > --------------------------------------------------------------- > Internet communications are not secure and therefore Siemens > Communications Limited does not accept legal responsibility for the > contents of this message. Any views or opinions presented are solely > those of the author and do not necessarily represent those of Siemens > Communications Limited unless otherwise specifically stated. > > > > -----Original Message----- > From: patrick.mourot@online.fr [mailto:patrick.mourot@online.fr] > Sent: Tuesday, April 09, 2002 5:05 PM > To: rsparks@dynamicsoft.com; sip@ietf.org > Subject: RE: [Sip] REFER security options - removing Referred-By > > > > Sirs, > > I think there are plainty of cases where C : > -will not need to know that the call was started by A read in > Referred-By > -or will trust B (i.e: intranet cases). > > Protecting Referred-By also means protecting others headers. > > This means that we should avoid all solutions that are not optional > regarding C > policy. > > A VERIFYing approach starting at C is better suited; It > allows C to decide > to > verify or not A identity. > If C does NOT want to or does NOT support VERIFY the call > flows remains > consistent with current behavior. > > PS: Referred-By is a means for carrying some useful Information. > > That's my 2 cents. > > Best Regards, > > Patrick > > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip > _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@ns.ietf.org Fri Apr 19 15:25:47 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA22381 for ; Fri, 19 Apr 2002 15:25:47 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id PAA04931 for sip-archive@odin.ietf.org; Fri, 19 Apr 2002 15:25:49 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA03830; Fri, 19 Apr 2002 15:00:48 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA03771 for ; Fri, 19 Apr 2002 15:00:42 -0400 (EDT) Received: from mail-green.research.att.com (H-135-207-30-103.research.att.com [135.207.30.103]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA18985 for ; Fri, 19 Apr 2002 15:00:38 -0400 (EDT) Received: from alliance.research.att.com (alliance.research.att.com [135.207.26.26]) by mail-green.research.att.com (Postfix) with ESMTP id 2A2741E009; Fri, 19 Apr 2002 15:00:40 -0400 (EDT) Received: from fish.research.att.com (fish.research.att.com [135.207.27.137]) by alliance.research.att.com (8.8.7/8.8.7) with ESMTP id PAA23889; Fri, 19 Apr 2002 15:00:39 -0400 (EDT) From: William Marshall Received: (from wtm@localhost) by fish.research.att.com (SGI-8.9.3/8.8.5) id PAA69760; Fri, 19 Apr 2002 15:00:28 -0400 (EDT) Date: Fri, 19 Apr 2002 15:00:28 -0400 (EDT) Message-Id: <200204191900.PAA69760@fish.research.att.com> To: rohan@cisco.com Cc: sip@ietf.org Subject: Re: [Sip] Proposed plan for Network-Asserted ID/Privacy Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Rohan Mahy wrote: > I'd like to propose a concrete plan to move forward with a solution for > network-asserted identity and privacy. I'm proposing this as an > individual (who is sick of reading about this topic on the mailing > list). Below I've listed some of problems that various folks were > apparently trying to solve in this space. > > 1. Provide a Network-Asserted ID > a. Within a trusted administrative domain or federation of domains > b. For interworking with PSTN mechanisms* > c. Usable across administrative boundaries > Once a proxy has determined the value of this "Network-Asserted ID", there are actually four possibilities to consider. a. Sending it to another proxy within a trusted admin domain or federation of domains b. Sending it to a PSTN gateway within a trusted admin domain or federation of domains c. Sending it to a proxy outside the trust admin domain or federation of domains d. Sending it to a UA Unfortunalely caller-id and call-trace are useless without choice (d). So my first comment is that 1d and 2d are needed in your itemized list of problems to solve. I think it is a major simplification to reduce these four cases to only two: a. Sending it to a network element within a trusted admin domain or federation of domains b. Sending it to a network element outside the trusted admin domain or federation of domains (and who says PSTN gateways are always trusted? Should the GW generate a private used-once phone number for the call attempt?) And, as much as I'd like to believe your comment that no additional work is required to implement 3c, are we really willing to leave it that all services will break if anonymity is requested? Or should services be designed with this in mind? Bill Marshall wtm@research.att.com _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@ns.ietf.org Fri Apr 19 16:27:01 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA29132 for ; Fri, 19 Apr 2002 16:27:01 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id QAA08163 for sip-archive@odin.ietf.org; Fri, 19 Apr 2002 16:27:03 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA06413; Fri, 19 Apr 2002 15:50:58 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA06381 for ; Fri, 19 Apr 2002 15:50:54 -0400 (EDT) Received: from mail-green.research.att.com (H-135-207-30-103.research.att.com [135.207.30.103]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA25401 for ; Fri, 19 Apr 2002 15:50:51 -0400 (EDT) Received: from alliance.research.att.com (alliance.research.att.com [135.207.26.26]) by mail-green.research.att.com (Postfix) with ESMTP id 8ACB61E0EA; Fri, 19 Apr 2002 15:50:49 -0400 (EDT) Received: from fish.research.att.com (fish.research.att.com [135.207.27.137]) by alliance.research.att.com (8.8.7/8.8.7) with ESMTP id PAA25056; Fri, 19 Apr 2002 15:50:48 -0400 (EDT) From: William Marshall Received: (from wtm@localhost) by fish.research.att.com (SGI-8.9.3/8.8.5) id PAA68623; Fri, 19 Apr 2002 15:50:10 -0400 (EDT) Date: Fri, 19 Apr 2002 15:50:10 -0400 (EDT) Message-Id: <200204191950.PAA68623@fish.research.att.com> To: dean.willis@softarmor.com Cc: sip@ietf.org Subject: Re: [Sip] z9hG4bK forever ??? Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Dean wrote: > Bill said: > > We have now identified TWO cases where un-proxy-like behavior will be > > done in real networks. The first, a few months ago, was where a > > firewall control proxy modified the Contact header, and possibly > > also modified the addresses and ports in the SDP. The second is here, > > where a privacy proxy modifies the From header (and quite probably, > others). > > Proxies in any form cannot modify bodies, and B2BUAs are likely to break > things if they try to. SIP security relies greatly on smime-protected > bodies. The philosophy is nice, but not all that useful if it can't be put into practice. As was said previously on this subject: Last February Jonathan Rosenberg said: >Now, it is true that, ahem, certain prominent sip vendors have products >called firewall control proxies which muck with the SDP. Whether these >things are rightly proxies, based on the SIP spec, or a B2BUA, is more a >matter of technical marketing than standards, so I would not lose too >much sleep over it. Its far less a stretch than what people are calling >softswitches these days ;). Our job here at IETF is to write standards >that work and are good for the Internet. And Rohan responded: > I agree with Jonathan here. We should leave the spec as is with the > exception of *adding* Contact-Length. Another prominent vendor that I > know has an ALG that modifies the SDP, and I don't even want to > *think* about what you would call it. Both of these will break as soon as > someone turns on the end-to-end SMIME integrity and encryption. I would > like to have that problem some day... I still believe we should recognize that such things will exist, and that services will need to cope with them, and that guidance to designers of new services would benefit from knowing, in advance, what such elements might do to cause them trouble. Bill Marshall wtm@research.att.com _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@ns.ietf.org Fri Apr 19 16:47:14 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA01357 for ; Fri, 19 Apr 2002 16:47:14 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id QAA09191 for sip-archive@odin.ietf.org; Fri, 19 Apr 2002 16:47:17 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA07921; Fri, 19 Apr 2002 16:21:39 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA07894 for ; Fri, 19 Apr 2002 16:21:36 -0400 (EDT) Received: from excalibur.santera.com (exchange.santera.com [4.22.157.11]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA28629 for ; Fri, 19 Apr 2002 16:21:28 -0400 (EDT) X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Date: Fri, 19 Apr 2002 15:20:57 -0500 Message-ID: Thread-Topic: [Sip] new drafts relating to privacy and identity concepts posted Thread-Index: AcHmao9CRApWf/cOS/CUr9rSb0aJCgBZxMzA From: "Chiou, Mark" To: "Dean Willis" Cc: Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id QAA07895 Subject: [Sip] Questions on new draft identity concepts posted Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 8bit Hi Dean, I have the following questions: 1. What is the purpose of this identity draft? If it is for network usage, then identity info shall not be delivered to the UAS when the Privacy is set to Anonymous. 2. Why is using MIME type instead of new optional header field? Why Call-ID and Date are required? Why is only encrypted for Anonymous calls? How about non-Anonymous calls? 3. Can we consider forwarding scenario? Such that the forwarding Identity is included. I know this does not apply to IP world when 3xx is returned to the UAC. But it is very popular in the PSTN interwork scenarios. 4. In page 14, 5.4 example of the Content-Length:147 of the Unique-Boundary-1. Do you think the length shall include the length of Unique-boundary42. 5. There are several IDs that we need to consider all together instead of separating them: 1) User, who actually makes the call 2) actual Subscriber, who subscribes the service 3) identity known by the Service Provider, who provides the service 4) The last forwarding-by identity known by the Service Provider, who provides the service 5) Billing Identity, who actually pays the bill Not all of above are needed by the UAS, but all are needed by the Network. 6. Every identity shall have its own privacy attribute, so we should address Identity and Privacy together. Regards, Mark Chiou -----Original Message----- From: Dean Willis [mailto:dwillis@dynamicsoft.com] Sent: Wednesday, April 17, 2002 6:24 PM To: sip@ietf.org Subject: [Sip] new drafts relating to privacy and identity concepts posted Please review: http://www.softarmor.com/sipwg/drafts/draft-peterson-sip-privacy-longter m-00.txt http://www.softarmor.com/sipwg/drafts/draft-peterson-sip-identity-00.txt They've been sent into the internet-drafts repository and should appear there shortly. -- Dean _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@ns.ietf.org Fri Apr 19 19:06:40 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA16309 for ; Fri, 19 Apr 2002 19:06:40 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id TAA16186 for sip-archive@odin.ietf.org; Fri, 19 Apr 2002 19:06:41 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA15090; Fri, 19 Apr 2002 18:43:22 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA15060 for ; Fri, 19 Apr 2002 18:43:19 -0400 (EDT) Received: from pine.neustar.com (pine.neustar.com [209.173.57.70]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA13805 for ; Fri, 19 Apr 2002 18:43:15 -0400 (EDT) Received: from chiimc01.il.neustar.com (chih650b-s3p2.il.neustar.com [209.173.57.65]) by pine.neustar.com (8.11.0/8.11.0) with ESMTP id g3JMgi707171; Fri, 19 Apr 2002 17:42:44 -0500 Received: by chiimc01.il.neustar.com with Internet Mail Service (5.5.2653.19) id ; Fri, 19 Apr 2002 17:42:39 -0500 Message-ID: <70565611B164D511957A001083FCDD5601870238@va02.va.neustar.com> From: "Peterson, Jon" To: "'Chiou, Mark'" Cc: sip@ietf.org Subject: RE: [Sip] Questions on new draft identity concepts posted Date: Fri, 19 Apr 2002 17:42:37 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org I'd like to take a stab at these questions. Some responses below. Jon Peterson NeuStar, Inc. > -----Original Message----- > From: Chiou, Mark [mailto:MChiou@santera.com] > Sent: Friday, April 19, 2002 1:21 PM > To: Dean Willis > Cc: sip@ietf.org > Subject: [Sip] Questions on new draft identity concepts posted > > > Hi Dean, > > I have the following questions: > > 1. What is the purpose of this identity draft? > If it is for network usage, then identity info shall > not be delivered to the UAS when the Privacy is set to Anonymous. The purpose of this identity draft is to define a general-purpose way for an 'authentication service' to provide a secure, verified identity for the originator of a request that can be inspected by any potential recipients. Privacy concerns are addressed in the draft - the identity will not be decipherable by a UAS when privacy is requested. > 2. Why is using MIME type instead of new optional header field? This is a good question, and unfortunately a deep one. That short story is that it is easier to stage the required security properties (integrity via signature with certificate, replay protection, optional confidentiality) in a body than in a header. With a body, we can also do this through baseline bis09 security mechanisms without having to invent anything new. > Why Call-ID and Date are required? To provide reference integrity to the request, and a small amount of replay protection, respectively. > Why is only encrypted for Anonymous calls? How about > non-Anonymous calls? If privacy is not required, then presumably the identity can and should be shared with any potential recipient. Seeing a network-verified identity might make a recipient more comfortable that they know the identity of the originator of a request. Users should only request privacy when they need it - I often don't accept phone calls that are from a blocked ID, myself. > 3. Can we consider forwarding scenario? Such that the > forwarding Identity is included. > I know this does not apply to IP world when 3xx is > returned to the UAC. > But it is very popular in the PSTN interwork scenarios. I have some hopes that the 'auth-id' system described in this draft (or whatever it eventually ends up being when the draft is done) will be applicable to things like forwarding and referral. I think it may already help out with some identity problems in forwarding. > > 4. In page 14, 5.4 example of the Content-Length:147 of > the Unique-Boundary-1. > Do you think the length shall include the length of > Unique-boundary42. Those MIME types do get confusing when they're embedded, eh? The Content-Length in that example does not pretend to be accurate - maybe I'll update it to a less inaccurate value. However, the unique-boundaries, are, I hope, correctly aligned. > 5. There are several IDs that we need to consider all > together instead of > separating them: > 1) User, who actually makes the call > 2) actual Subscriber, who subscribes the service > 3) identity known by the Service Provider, who > provides the service > 4) The last forwarding-by identity known by the > Service Provider, > who provides the service > 5) Billing Identity, who actually pays the bill > Not all of above are needed by the UAS, but all are > needed by the Network. All interesting concepts, and as you'll note I left open the possibility that other information could be put into the 'auth-id' token as necessary. For the time being, the draft is only concerned, really, with (1) and (3) above. I'm surprised you make a distinction between (2) and (5) - I though the fact that (2) encompasses (5) is what differentiates (2) from (1). Then again, I don't really understand (2) that well either. Anyway, I don't think the identity draft needs to get into any of these details - this mechanism could be extended at a later time to accomodate these concepts as necessary. SIP needs to grapple a bit with what these other sorts of identities are before we figure out how to stuff them into secured bodies. > 6. Every identity shall have its own privacy attribute, > so we should address Identity and Privacy together. This identity draft does depend on and extend the accompanying privacy draft. Frankly, I think ascribing a new privacy attribute to every conceivable form of identity is unnecessary, and possibly dangerous. A user shouldn't have to know, when they create a message, all of the various headers in a message for which they need privacy - merely what kind of privacy they need. While there is definitely a relationship between identity and privacy, I think they are separable and they benefit from separate consideration. > Regards, > > Mark Chiou > > -----Original Message----- > From: Dean Willis [mailto:dwillis@dynamicsoft.com] > Sent: Wednesday, April 17, 2002 6:24 PM > To: sip@ietf.org > Subject: [Sip] new drafts relating to privacy and identity concepts > posted > > > Please review: > > http://www.softarmor.com/sipwg/drafts/draft-peterson-sip-priva cy-longter m-00.txt http://www.softarmor.com/sipwg/drafts/draft-peterson-sip-identity-00.txt They've been sent into the internet-drafts repository and should appear there shortly. -- Dean _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@ns.ietf.org Fri Apr 19 19:42:58 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA19963 for ; Fri, 19 Apr 2002 19:42:58 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id TAA17711 for sip-archive@odin.ietf.org; Fri, 19 Apr 2002 19:42:59 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id TAA16665; Fri, 19 Apr 2002 19:16:16 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id TAA16615 for ; Fri, 19 Apr 2002 19:16:11 -0400 (EDT) Received: from bdsl.66.12.12.130.gte.net (bdsl.66.12.12.130.gte.net [66.12.12.130]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA17107 for ; Fri, 19 Apr 2002 19:15:54 -0400 (EDT) Received: from TXDWILLIS2 (bdsl.greycouncil.com [127.0.0.1]) by bdsl.66.12.12.130.gte.net (8.11.6/8.11.6) with ESMTP id g3JNFNd22784; Fri, 19 Apr 2002 18:15:23 -0500 From: "Dean Willis" To: Cc: "3GPP_TSG_CN_WG1" <3GPP_TSG_CN_WG1@LIST.ETSI.FR> Date: Fri, 19 Apr 2002 18:15:16 -0500 Message-ID: <000401c1e7f8$10cef9b0$1e036e3f@TXDWILLIS2> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.3416 Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Content-Transfer-Encoding: 7bit Subject: [Sip] Revised Service Route Discovery Draft Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit I've submitted draft-willis-sip-svcrtdisco-01.txt to the Internet Drafts queue. This version includs refinements made by Bernie Hoeneisen to my earlier draft. The draft should be announced shortly on ietf-announce. In the meantime, please review: http://www.softarmor.com/sipwg/drafts/draft-willis-sip-svcrtdisco-01.txt or http://www.softarmor.com/sipwg/drafts/draft-willis-sip-svcrtdisco-01.htm l or http://www.softarmor.com/sipwg/drafts/draft-willis-sip-svcrtdisco-01.xml This is a "P-header" draft addressing 3GPP's required header for reporting a service proxy assignment in the REGISTER response. Please review ASAP. We need to get this to IETF last call by the end of the month if at all possible. -- Dean _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@ns.ietf.org Fri Apr 19 19:47:54 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA20369 for ; Fri, 19 Apr 2002 19:47:54 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id TAA17897 for sip-archive@odin.ietf.org; Fri, 19 Apr 2002 19:47:55 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id TAA16988; Fri, 19 Apr 2002 19:26:55 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id TAA16958 for ; Fri, 19 Apr 2002 19:26:52 -0400 (EDT) Received: from sj-msg-core-4.cisco.com (sj-msg-core-4.cisco.com [171.71.163.10]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA18275 for ; Fri, 19 Apr 2002 19:26:49 -0400 (EDT) Received: from imop.cisco.com (IDENT:mirapoint@imop.cisco.com [171.69.11.44]) by sj-msg-core-4.cisco.com (8.12.2/8.12.2) with ESMTP id g3JNQKjR002674; Fri, 19 Apr 2002 16:26:20 -0700 (PDT) Received: from imop.cisco.com (localhost.cisco.com [127.0.0.1]) by imop.cisco.com (Mirapoint) with SMTP id ACX24295 (AUTH rmahy); Fri, 19 Apr 2002 16:26:20 -0700 (PDT) Message-Id: <200204192326.ACX24295@imop.cisco.com> Received: from 128.107.142.117 by imop.cisco.com with HTTP/1.1; Fri, 19 Apr 2002 16:28:55 -0700 Date: Fri, 19 Apr 2002 16:28:55 -0700 From: Rohan Mahy Subject: Re: [Sip] Proposed plan for Network-Asserted ID/Privacy To: Flemming Andreasen Cc: Rohan Mahy , sip@ietf.org X-Mailer: Mirapoint Webmail Direct 2.9.1.3 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit ---- Original message ---- >Date: Fri, 19 Apr 2002 09:52:42 -0400 >From: Flemming Andreasen >Subject: Re: [Sip] Proposed plan for Network-Asserted ID/Privacy >To: Rohan Mahy >Cc: sip@ietf.org > > > >Rohan Mahy wrote: > >> Hi, >> >> I'd like to propose a concrete plan to move forward with a solution for >> network-asserted identity and privacy. I'm proposing this as an >> individual (who is sick of reading about this topic on the mailing >> list). Below I've listed some of problems that various folks were >> apparently trying to solve in this space. >> >> 1. Provide a Network-Asserted ID >> a. Within a trusted administrative domain or federation of domains >> b. For interworking with PSTN mechanisms* >> c. Usable across administrative boundaries >> >> 2. Provide capability for Call Trace >> a. Within a trusted administrative domain or federation of domains >> b. For interworking with PSTN mechanisms* >> c. Usable across administrative boundaries >> >> 3. Provide privacy >> a. by the user directly withholding information from the network >> b. in the network for user-provided info at the user's request >> c. in the network for user-provided info based on network policy >> d. of network-provided information >> >> 4. Allow for a user-provided "hint" for Network-Asserted ID >> >> *(with gateways in the trusted domain or federation) >> >> Most of the snags and disagreements we have had with the existing >> Remote-Party-ID draft (draft-ietf-sip-privacy-04) are related to problems >> 1c, 2c, and 4. Even a very scaled-down version of this draft would allow >> for trusted intermediaries and user agents (including gateways) to >> exchange network asserted identity and provide the capability for call >> trace within a domain or federation of trusted domains. The solution is >> as simple as a single header which carries the identity in clear text, >> which is added by the first proxy that authenticates the user, and >> removed before it leaves the trust boundary. > >You need to be more clear. 1 and 2 talk about administrative domains and >administrative boundaries and now you are talking about trust boundaries. How >do you define an administrative domain, an administrative boundary, and a >trust boundary ? Fair enough. Let's say for now that a trusted entity is trusted not to maliciously modify messages, or reveal "private" network asserted ID information outside the "trusted" federation. So, ordinary UAs in "my" service provider network are not trusted. >> This would solve >> 1a, 1b, 2a, and 2b. > >No. The UA is (normally) untrusted but still needs it. If you were only >talking about the case when privacy was requested, then it doesn't address the >requirement to provide call trace for anonymous calls. The user is obviously >untrusted and hence cannot be given the caller-id in clear- text. The privacy >draft solves this by handing out an encrypted Remote-Party- Id which can >subsequently be used for call trace (as well as other features for that >matter, e.g. anonymous call return). OK, I hope we agree that 1a, 1b, and 2b would by solved by the scaled down mechanism. You could still provide call trace (2a) within this network by using accounting mechanisms. You will probably say that insuring you have an accounting record for each call is a burden. Also, you do lose the ability to do call return with this mechanism, but I do not consider this a short-term requirement. (You might disagree). > > >> >> Finally, we have problem 4. Some folks have proposed that >> UAs should provide a hint using the same mechanism used to >> communicate network asserted identity among trusted entities. > >> Others propose that authentication servers that create a > >> network asserted identity accept multiple "usernames" during > >> authentication and use this as the hint. AFAIK these are the >> only two choices, and we can come up with an answer to this >> question in a separate thread. The answer does not fundamentally >> change any of the mechanisms we select to solve the other problems. > >Well it certainly impacts it. If you go with the first solution then you also >accept that Remote-Party-Id can be provided by an untrusted entity, so I don't >think we can solve these independently. i think we need to decouple them now, and can join them again if it makes sense. >> So, in summary, I'm proposing: >> >> No additional work is required to implement 3c >> >> Three short term deliverables >> I) adopt draft-peterson-sip-privacy-longterm as a WG item to solve >> 3a and 3b >> > >It's unclear that 3b is independent of which mechanism you choose to provide >the hint above. I don't follow you. >> II) write an extension to I) as a WG item for requesting privacy of >> network asserted ID (however it is expressed) to support 3d. This would >> get used by III and IV. >> >> III) pare down the mechanism in draft-ietf-sip-privacy to only address 1a, >> 1b, 2a, and 2b. quickly get closure on which mechanism we use for 4, and >> include it in the draft. keep the current applicability statement. > >As mentioned above, I'm not clear on exactly what 1a, 1b, 2a and 2b are, but >if the "network asserted identity" draft would neither address privacy for >network asserted identity, nor call trace for anonymous calls, then I >certainly disagree with this. I think it does provide a solution here for a small scope. thanks, -rohan _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@ns.ietf.org Fri Apr 19 19:52:15 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA20689 for ; Fri, 19 Apr 2002 19:52:15 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id TAA18049 for sip-archive@odin.ietf.org; Fri, 19 Apr 2002 19:52:17 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id TAA17144; Fri, 19 Apr 2002 19:30:16 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id TAA17105 for ; Fri, 19 Apr 2002 19:30:12 -0400 (EDT) Received: from sj-msg-core-4.cisco.com (sj-msg-core-4.cisco.com [171.71.163.10]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA18485 for ; Fri, 19 Apr 2002 19:30:09 -0400 (EDT) Received: from imop.cisco.com (IDENT:mirapoint@imop.cisco.com [171.69.11.44]) by sj-msg-core-4.cisco.com (8.12.2/8.12.2) with ESMTP id g3JNTejR003651; Fri, 19 Apr 2002 16:29:40 -0700 (PDT) Received: from imop.cisco.com (localhost.cisco.com [127.0.0.1]) by imop.cisco.com (Mirapoint) with SMTP id ACX24339 (AUTH rmahy); Fri, 19 Apr 2002 16:29:39 -0700 (PDT) Message-Id: <200204192329.ACX24339@imop.cisco.com> Received: from 128.107.142.117 by imop.cisco.com with HTTP/1.1; Fri, 19 Apr 2002 16:32:14 -0700 Date: Fri, 19 Apr 2002 16:32:14 -0700 From: Rohan Mahy Subject: Re: Problem 4 of RE: [Sip] Proposed plan for Network-Asserted ID/Privacy To: jh@lohi.eng.song.fi Cc: Mark Watson , "'Flemming Andreasen'" , Rohan Mahy , sip@ietf.org X-Mailer: Mirapoint Webmail Direct 2.9.1.3 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit Juha, >Mark Watson writes: > > I diagree. Solve the other problems first. Then we have three choices: > > 1) Use the same header for the 'hints' > > 2) Define another header for the 'hints' > > 3) Assume the 'hint' in in the authentication 'username' > >(3) doesn't work. my username is jh@song.fi, but my from uri that i >want to use, can be, for example, tel+358441234567. I'm suggesting that in order to solve this problem, one choice (3) is that we can make these proxies smart enough that they can accept jh@song.fi or +358441234567 in the username field, and understand that these two things refer to the same user. thanks, -rohan _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@ns.ietf.org Fri Apr 19 20:21:46 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA23557 for ; Fri, 19 Apr 2002 20:21:46 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id UAA19101 for sip-archive@odin.ietf.org; Fri, 19 Apr 2002 20:21:48 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id TAA17862; Fri, 19 Apr 2002 19:46:37 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id TAA17831 for ; Fri, 19 Apr 2002 19:46:34 -0400 (EDT) Received: from sj-msg-core-3.cisco.com (sj-msg-core-3.cisco.com [171.70.157.152]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA20237 for ; Fri, 19 Apr 2002 19:46:31 -0400 (EDT) Received: from imop.cisco.com (IDENT:mirapoint@imop.cisco.com [171.69.11.44]) by sj-msg-core-3.cisco.com (8.12.2/8.12.2) with ESMTP id g3JNji2q005814; Fri, 19 Apr 2002 16:45:44 -0700 (PDT) Received: from imop.cisco.com (localhost.cisco.com [127.0.0.1]) by imop.cisco.com (Mirapoint) with SMTP id ACX24565 (AUTH rmahy); Fri, 19 Apr 2002 16:46:02 -0700 (PDT) Message-Id: <200204192346.ACX24565@imop.cisco.com> Received: from 128.107.142.117 by imop.cisco.com with HTTP/1.1; Fri, 19 Apr 2002 16:48:37 -0700 Date: Fri, 19 Apr 2002 16:48:37 -0700 From: Rohan Mahy Subject: Re: [Sip] Proposed plan for Network-Asserted ID/Privacy To: William Marshall Cc: rohan@cisco.com, sip@ietf.org X-Mailer: Mirapoint Webmail Direct 2.9.1.3 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit ---- Original message ---- >Date: Fri, 19 Apr 2002 15:00:28 -0400 (EDT) >From: William Marshall >Subject: Re: [Sip] Proposed plan for Network-Asserted ID/Privacy >To: rohan@cisco.com >Cc: sip@ietf.org > >Rohan Mahy wrote: >> I'd like to propose a concrete plan to move forward with a solution for >> network-asserted identity and privacy. I'm proposing this as an >> individual (who is sick of reading about this topic on the mailing >> list). Below I've listed some of problems that various folks were >> apparently trying to solve in this space. >> >> 1. Provide a Network-Asserted ID >> a. Within a trusted administrative domain or federation of domains >> b. For interworking with PSTN mechanisms* >> c. Usable across administrative boundaries >> > >Once a proxy has determined the value of this "Network- Asserted ID", >there are actually four possibilities to consider. > a. Sending it to another proxy within a trusted admin domain > or federation of domains > b. Sending it to a PSTN gateway within a trusted admin domain > or federation of domains > c. Sending it to a proxy outside the trust admin domain > or federation of domains > d. Sending it to a UA OK, I agree that this list is clearer than the one I proposed. >Unfortunalely caller-id and call-trace are useless without choice (d). >So my first comment is that 1d and 2d are needed in your itemized list >of problems to solve. Lets assume that the Network Asserted ID is stripped as it leaves a trust boundary only if privacy is requested (so you get 1d). Then the only problem to solve is anonymous call trace (2d). I think that some providers can choose to offer call trace by storing accounting records for some period of time. Alternatively, the provider could require a signature- based mechanism like the one that Jon proposed. >I think it is a major simplification to reduce these four cases to only >two: > a. Sending it to a network element within a trusted admin domain > or federation of domains > b. Sending it to a network element outside the trusted admin domain > or federation of domains >(and who says PSTN gateways are always trusted? Should the GW generate >a private used-once phone number for the call attempt?) To clarify, I intended for gateways which are not trusted to be treated like any other device in a different domain. An untrusted PSTN gateway would need to be addressed using a signature-based mechanism. Consequently, it would not be able to provide an actual phone number and just set it to screened. >And, as much as I'd like to believe your comment that no additional work >is required to implement 3c, are we really willing to leave it that all >services will break if anonymity is requested? Or should >services be designed with this in mind? I don't think that using an anonymizer has to break features unless these feature explicitly need raw identity information. Also, I'm not really sure what you are proposing instead. thanks, -rohan >Bill Marshall >wtm@research.att.com > >_______________________________________________ >Sip mailing list https://www1.ietf.org/mailman/listinfo/sip >This list is for NEW development of the core SIP Protocol >Use sip-implementors@cs.columbia.edu for questions on current sip >Use sipping@ietf.org for new developments on the application of sip _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@ns.ietf.org Fri Apr 19 20:50:16 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA26717 for ; Fri, 19 Apr 2002 20:50:15 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id UAA20232 for sip-archive@odin.ietf.org; Fri, 19 Apr 2002 20:49:09 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id UAA19144; Fri, 19 Apr 2002 20:21:56 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id UAA19113 for ; Fri, 19 Apr 2002 20:21:53 -0400 (EDT) Received: from oak.neustar.com (oak.neustar.com [209.173.53.70]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA23570 for ; Fri, 19 Apr 2002 20:21:50 -0400 (EDT) Received: from chiimc01.il.neustar.com (stih650b-s1p2.va.neustar.com [209.173.53.65]) by oak.neustar.com (8.11.0/8.11.0) with ESMTP id g3K0LDH09667; Fri, 19 Apr 2002 20:21:14 -0400 Received: by chiimc01.il.neustar.com with Internet Mail Service (5.5.2653.19) id ; Fri, 19 Apr 2002 19:21:08 -0500 Message-ID: <70565611B164D511957A001083FCDD5601870239@va02.va.neustar.com> From: "Peterson, Jon" To: "'Rohan Mahy'" , sip@ietf.org Subject: RE: [Sip] Proposed plan for Network-Asserted ID/Privacy Date: Fri, 19 Apr 2002 19:21:06 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org I wanted to weigh in with a couple of comments on this plan, below. Jon Peterson NeuStar, Inc. > -----Original Message----- > From: Rohan Mahy [mailto:rohan@cisco.com] > Sent: Thursday, April 18, 2002 4:07 PM > To: sip@ietf.org > Subject: [Sip] Proposed plan for Network-Asserted ID/Privacy > [snip] > > 1. Provide a Network-Asserted ID > a. Within a trusted administrative domain or federation of domains > b. For interworking with PSTN mechanisms* > c. Usable across administrative boundaries > I assume we understand 'across administrative boundaries' here to refer to any 'untrusted' destination? I really have a hard time seeing why 1b (and 2b by extension) needs to be a separate case from 1a (and 2a). Surely PSTN gateways are 'trusted', and no element is going to do anything differently when sending a request to a PSTN gateway than they would do when sending it to any other 'trusted' element? I also haven't seen any great need in my own identity draft to make use of the distinction along the lines of 1a and 1c ('trusted' and 'untrusted') - I feel that this distinction is motivated architectures that arise from the absence of cryptographic mechanisms. But I understand that there are some who want to carve the problem up this way. Personally, I view 1a, 1b and 1c as requirements that are differentiated only by pseudoproblems. > 2. Provide capability for Call Trace > a. Within a trusted administrative domain or federation of domains > b. For interworking with PSTN mechanisms* > c. Usable across administrative boundaries The distinction between 1 and 2 overall is a little fine to me as well. Surely network-asserted identity is a way of implementing call trace, right? Call trace implies revealing identity selectively, namely the privacy requirements entailed in 3, but I'm not sure we need a separate category for this. Is there something other than what we are already doing to implement 1 and 3 that we'd need to implement 2? 3 & 4 below are both fine. > > 3. Provide privacy > a. by the user directly withholding information from the network > b. in the network for user-provided info at the user's request > c. in the network for user-provided info based on network policy > d. of network-provided information > > 4. Allow for a user-provided "hint" for Network-Asserted ID > > *(with gateways in the trusted domain or federation) > [snip] > > So, in summary, I'm proposing: > > No additional work is required to implement 3c Agreed. Nothing pressing, anyway. > > Three short term deliverables > I) adopt draft-peterson-sip-privacy-longterm as a WG item to solve > 3a and 3b Fine by me, obviously. > > II) write an extension to I) as a WG item for requesting privacy of > network asserted ID (however it is expressed) to support 3d. This would > get used by III and IV. > So, today my identity draft already contains a privacy extension for the style of NAI provided in that draft. It declares a Privacy header priv-value for 'auth' for this purpose. That could be generalized, certainly, though exactly what it would entail would undoubtedly be different for different NAI systems. In my identity draft, it entails that one SHOULD not distribute an NAI, and if one does, it MUST be encrypted. Personally, I don't think that relying on downstream entities to remove the NAI when they see fit is sufficient, and this would probably be a point of contention in any attempt to agree on a single meaning for this 'auth' priv-value. I'd therefore like to suggest that we think a little more about this. Maybe there's a way to generalize the syntax but not the semantics for any particular NAI system. However, if I were the user requesting privacy, I'd want to know whether encryption or removal were going to be used... > III) pare down the mechanism in draft-ietf-sip-privacy to only address 1a, > 1b, 2a, and 2b. quickly get closure on which mechanism we use for 4, and > include it in the draft. keep the current applicability statement. > I don't think the mechanism you need to use for 4 should be included in this draft - I think the manner in which you provide your identity to entities that create NAIs has no obvious dependencies on the NAI distribution mechanism. In so far as this may be a matter for SIP (the people that seem to want this may have some out-of-band way of getting this data), it should probably be in its own draft. I'd also like to comment that I think getting the existing sip-privacy-04 mechanism into parity with a reasonable applicability, including as Flemming sugggests robust definitions of trust, administrative boundaries, and so forth is not necessarily a trivial task. > One or more longer term deliverables, including > IV) draft-peterson-sip-identity ... to address a more general way to > solve 1 and 2 including 1c and 2c. Note that this draft is the first > step toward providing real cryptographic identity services. > I think we also need to address this topic as a charter item. > Suits me. Although the mechanism my draft proposes is admittedly heavyweight, I think it addresses the general requirements with few new protocol mechanisms. I'm looking forward to comments on it. I have no reason today to think that it will require a 'long term' to complete this work. > We might also provide an informational document describing how to map > privacy and identity between SIP and the PSTN. > Juha, among others, had argued this in the past, anyway. I think we do need a way to map SIP's privacy apparati to the appropriate ISUP presentation restriction bits, and so on. This is just part of the SIP-T work. > hope this helps. > thanks, > -rohan > > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip > _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Sat Apr 20 01:34:30 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA20050 for ; Sat, 20 Apr 2002 01:34:30 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id BAA11098 for sip-archive@odin.ietf.org; Sat, 20 Apr 2002 01:34:31 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id AAA28548; Sat, 20 Apr 2002 00:52:24 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id AAA28518 for ; Sat, 20 Apr 2002 00:52:21 -0400 (EDT) Received: from lohi.eng.song.fi (lohi.eng.song.fi [195.10.149.18]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA19762 for ; Sat, 20 Apr 2002 00:52:17 -0400 (EDT) From: jh@lohi.eng.song.fi Received: from harjus.eng.song.fi ([195.10.149.20]) by lohi.eng.song.fi with esmtp (Exim 3.34 #1 (Debian)) id 16ymr8-0006On-00; Sat, 20 Apr 2002 07:52:14 +0300 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15552.62462.769964.42801@harjus.eng.song.fi> Date: Sat, 20 Apr 2002 07:52:14 +0300 To: Rohan Mahy Cc: Mark Watson , "'Flemming Andreasen'" , sip@ietf.org Subject: Re: Problem 4 of RE: [Sip] Proposed plan for Network-Asserted ID/Privacy In-Reply-To: <200204192329.ACX24339@imop.cisco.com> References: <200204192329.ACX24339@imop.cisco.com> X-Mailer: VM 7.01 under Emacs 21.1.1 Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit Rohan Mahy writes: > I'm suggesting that in order to solve this problem, one > choice (3) is that we can make these proxies smart enough > that they can accept jh@song.fi or +358441234567 in the > username field, and understand that these two things refer to > the same user. the point that i wanted to make is that my "username" is totally separate from my "from uri" and that BOTH exist in the invite that i send. when my sip/pstn gw forwards the invite to pstn, the network must verify that the "from uri" really belongs to me as identified by the username. -- juha _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Sat Apr 20 05:51:10 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA00174 for ; Sat, 20 Apr 2002 05:51:10 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id FAA20901 for sip-archive@odin.ietf.org; Sat, 20 Apr 2002 05:51:01 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id FAA18822; Sat, 20 Apr 2002 05:12:34 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id FAA18788 for ; Sat, 20 Apr 2002 05:12:31 -0400 (EDT) Received: from smtp2.arnet.com.ar (smtp2.arnet.com.ar [200.45.191.5]) by ietf.org (8.9.1a/8.9.1a) with SMTP id FAA29861 for ; Sat, 20 Apr 2002 05:12:24 -0400 (EDT) Received: (qmail 3694 invoked from network); 20 Apr 2002 09:10:17 -0000 Received: from unknown (HELO mail2.arnet.com.ar) (200.45.0.5) by smtp2.arnet.com.ar with SMTP; 20 Apr 2002 09:10:17 -0000 Received: from mail pickup service by mail2.arnet.com.ar with Microsoft SMTPSVC; Sat, 20 Apr 2002 06:09:55 -0300 Received: from mx1.arnet.com.ar ([200.45.0.2]) by mail2.arnet.com.ar with Microsoft SMTPSVC(5.5.1877.677.67); Thu, 18 Apr 2002 11:38:19 -0300 Received: from loki.ietf.org ([132.151.1.177]) by mx1.arnet.com.ar with Microsoft SMTPSVC(5.5.1877.357.35); Thu, 18 Apr 2002 11:38:20 -0300 Received: (from adm@localhost) by loki.ietf.org (8.9.1b+Sun/8.9.1) id KAA20524 for ietf-123-outbound.01@ietf.org; Thu, 18 Apr 2002 10:35:00 -0400 (EDT) Received: from ietf.org (odin.ietf.org [10.27.2.28]) by loki.ietf.org (8.9.1b+Sun/8.9.1) with ESMTP id IAA19185 for ; Thu, 18 Apr 2002 08:01:08 -0400 (EDT) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA02082; Thu, 18 Apr 2002 08:01:04 -0400 (EDT) Message-Id: <200204181201.IAA02082@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: sip@ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Date: Thu, 18 Apr 2002 08:01:04 -0400 Subject: [Sip] I-D ACTION:draft-ietf-sip-digest-aka-00.txt Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Session Initiation Protocol Working Group of the IETF. Title : HTTP Digest Authentication Using AKA Author(s) : R. Housley, W. Polk Filename : draft-ietf-sip-digest-aka-00.txt Pages : 17 Date : 17-Apr-02 The Hypertext Transfer Protocol (HTTP) Authentication Framework includes two authentication schemes: Basic and Digest. Both schemes employ a shared secret based mechanism for access authentication. The Authentication and Key Agreement (AKA) mechanism performs user authentication and session key distribution in Universal Mobile Telecommunications System (UMTS) networks. AKA is a challenge- response based mechanism that uses symmetric cryptography. This memo specifies an AKA based one-time password generation mechanism for HTTP Digest access authentication. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-sip-digest-aka-00.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-sip-digest-aka-00.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-sip-digest-aka-00.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <20020417151758.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-sip-digest-aka-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-sip-digest-aka-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20020417151758.I-D@ietf.org> --OtherAccess-- --NextPart-- _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@ns.ietf.org Sat Apr 20 14:13:55 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA05545 for ; Sat, 20 Apr 2002 14:13:55 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id OAA09652 for sip-archive@odin.ietf.org; Sat, 20 Apr 2002 14:13:57 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA06990; Sat, 20 Apr 2002 13:12:34 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA06959 for ; Sat, 20 Apr 2002 13:12:31 -0400 (EDT) Received: from bdsl.66.12.12.130.gte.net (bdsl.66.12.12.130.gte.net [66.12.12.130]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA04576 for ; Sat, 20 Apr 2002 13:12:27 -0400 (EDT) Received: from TXDWILLIS2 (bdsl.greycouncil.com [127.0.0.1]) by bdsl.66.12.12.130.gte.net (8.11.6/8.11.6) with ESMTP id g3KGmZd27422; Sat, 20 Apr 2002 11:48:36 -0500 From: "Dean Willis" To: , "'Rohan Mahy'" Cc: "'Mark Watson'" , "'Flemming Andreasen'" , Subject: RE: Problem 4 of RE: [Sip] Proposed plan for Network-Asserted ID/Privacy Date: Sat, 20 Apr 2002 11:48:25 -0500 Message-ID: <010d01c1e88b$3291f910$682c36d0@TXDWILLIS2> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.3416 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Importance: Normal In-Reply-To: <15552.62462.769964.42801@harjus.eng.song.fi> Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit > the point that i wanted to make is that my "username" is > totally separate from my "from uri" and that BOTH exist in > the invite that i send. when my sip/pstn gw forwards the > invite to pstn, the network must verify that the "from uri" > really belongs to me as identified by the username. That's sort of a quirk in your gateway -- it maps From: to calling-party-ID. Most gateways work that way today. They won't necessarily do so in the future. It COULD map "Username" from an authorization header to calling-party-ID. It also COULD generate the challenge to get an appropriate authorization header back. That may not be the "right" way to do it, but that's what we're talking about here -- finding the "right" way to go forward. -- Dean _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@ns.ietf.org Sat Apr 20 17:58:53 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA08047 for ; Sat, 20 Apr 2002 17:58:53 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id RAA17343 for sip-archive@odin.ietf.org; Sat, 20 Apr 2002 17:58:57 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA16278; Sat, 20 Apr 2002 17:21:10 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA16247 for ; Sat, 20 Apr 2002 17:21:06 -0400 (EDT) Received: from lohi.eng.song.fi (lohi.eng.song.fi [195.10.149.18]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA07624 for ; Sat, 20 Apr 2002 17:21:02 -0400 (EDT) From: jh@lohi.eng.song.fi Received: from harjus.eng.song.fi ([195.10.149.20]) by lohi.eng.song.fi with esmtp (Exim 3.34 #1 (Debian)) id 16z2Hz-0006Uu-00; Sun, 21 Apr 2002 00:20:59 +0300 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15553.56251.677760.711952@harjus.eng.song.fi> Date: Sun, 21 Apr 2002 00:20:59 +0300 To: "Dean Willis" Cc: "'Rohan Mahy'" , "'Mark Watson'" , "'Flemming Andreasen'" , Subject: RE: Problem 4 of RE: [Sip] Proposed plan for Network-Asserted ID/Privacy In-Reply-To: <010d01c1e88b$3291f910$682c36d0@TXDWILLIS2> References: <15552.62462.769964.42801@harjus.eng.song.fi> <010d01c1e88b$3291f910$682c36d0@TXDWILLIS2> X-Mailer: VM 7.01 under Emacs 21.1.1 Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit Dean Willis writes: > It COULD map "Username" from an authorization header to > calling-party-ID. no it could not because the user may have any number of calling party numbers belong to different area codes and even different countries. the user thus definitely needs to be able to control the calling party id. > It also COULD generate the challenge to get an > appropriate authorization header back. this is what we do today, but knowing who the user is doesn't mean that the proxy knows which calling party id the user wants to use. > That may not be the "right" way > to do it, but that's what we're talking about here -- finding the > "right" way to go forward. the proxy MUST respect the user's will regarding the calling party id within the limits of calling party ids of that user. the proxy has no right to pick one on its own. -- juha _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Sun Apr 21 06:54:51 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA23522 for ; Sun, 21 Apr 2002 06:54:51 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id GAA22803 for sip-archive@odin.ietf.org; Sun, 21 Apr 2002 06:54:51 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id GAA21380; Sun, 21 Apr 2002 06:07:49 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id GAA21349 for ; Sun, 21 Apr 2002 06:07:45 -0400 (EDT) Received: from albatross.wise.edt.ericsson.se (albatross-ext.wise.edt.ericsson.se [193.180.251.49]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA23193 for ; Sun, 21 Apr 2002 06:07:43 -0400 (EDT) Received: from madrid.es.eu.ericsson.se (madrid.es.eu.ericsson.se [159.107.7.100]) by albatross.wise.edt.ericsson.se (8.12.1/8.12.1/WIREfire-1.4) with ESMTP id g3LA7e0E012476; Sun, 21 Apr 2002 12:07:41 +0200 (MEST) Received: from ericsson.com ([159.107.1.12]) by madrid.es.eu.ericsson.se (8.12.1/8.12.1) with ESMTP id g3LA7bws008361; Sun, 21 Apr 2002 12:07:38 +0200 (MET DST) Message-ID: <3CC28F6E.C4C2A03A@ericsson.com> Date: Sun, 21 Apr 2002 13:07:42 +0300 From: "Miguel A. Garcia" Organization: OY LM Ericsson AB X-Mailer: Mozilla 4.74 [en] (Windows NT 5.0; U) X-Accept-Language: es,en MIME-Version: 1.0 To: "Henning G. Schulzrinne" , "Bernie Volz (EUD)" , sip@ietf.org Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [Sip] Comment about draft-ietf-sip-dhcpv6-00.txt Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit Hi: A very simple comment regarding the DHCPv6 option for SIP servers I-D. The draft has a duplicated reference to the "SIP: locating SIP servers" I-D, future RFC 3263. It is listed as both references 3 and 7. Regards, Miguel -- Miguel-Angel Garcia Oy LM Ericsson AB Jorvas, Finland mailto:Miguel.A.Garcia@ericsson.com Phone: +358 9 299 3553 mailto:Miguel.A.Garcia@piuha.net Mobile: +358 40 5140002 _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Sun Apr 21 09:48:18 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA24833 for ; Sun, 21 Apr 2002 09:48:17 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id JAA29752 for sip-archive@odin.ietf.org; Sun, 21 Apr 2002 09:48:18 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA28277; Sun, 21 Apr 2002 09:12:25 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA28246 for ; Sun, 21 Apr 2002 09:12:22 -0400 (EDT) Received: from kenny.siteprotect.com (kenny.siteprotect.com [64.26.0.130]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA24505 for ; Sun, 21 Apr 2002 09:12:21 -0400 (EDT) Received: from joshua (host217-39-157-182.in-addr.btopenworld.com [217.39.157.182]) by kenny.siteprotect.com (8.9.3/8.9.3) with ESMTP id IAA10333 for ; Sun, 21 Apr 2002 08:11:48 -0500 From: "Ofir Arkin" To: Date: Sun, 21 Apr 2002 14:11:21 +0100 Message-ID: <000e01c1e936$0b93dcb0$0a01a8c0@joshua> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.2627 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Importance: Normal Content-Transfer-Encoding: 7bit Subject: [Sip] When is a 487 Request Terminated is sent? Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit I would appreciate if some one would shade a light on the exact circumstances in which a 487 Request Terminated is sent. Thanks Ofir Arkin [ofir@sys-security.com] The Sys-Security Group http://www.sys-security.com PGP CC2C BE53 12C6 C9F2 87B1 B8C6 0DFA CF2D D360 43FA _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Sun Apr 21 09:54:38 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA24900 for ; Sun, 21 Apr 2002 09:54:37 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id JAA29855 for sip-archive@odin.ietf.org; Sun, 21 Apr 2002 09:54:38 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA28686; Sun, 21 Apr 2002 09:26:46 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA28655 for ; Sun, 21 Apr 2002 09:26:42 -0400 (EDT) Received: from public.szptt.net.cn (mail2-smtp.szptt.net.cn [202.96.136.222]) by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA24624 for ; Sun, 21 Apr 2002 09:26:40 -0400 (EDT) Received: from public.szptt.net.cn([202.96.136.222]) by public.szptt.net.cn(JetMail 2.5.3.0) with SMTP id jm4a3cc2ceb3; Sun, 21 Apr 2002 13:26:20 -0000 Received: from loki.ietf.org([132.151.1.177]) by public.szptt.net.cn(JetMail 2.5.3.0) with SMTP id jm233cc05bb3; Fri, 19 Apr 2002 13:00:56 -0000 Received: (from adm@localhost) by loki.ietf.org (8.9.1b+Sun/8.9.1) id HAA25860 for ietf-123-outbound.01@ietf.org; Fri, 19 Apr 2002 07:35:01 -0400 (EDT) Received: from ietf.org (odin.ietf.org [10.27.2.28]) by loki.ietf.org (8.9.1b+Sun/8.9.1) with ESMTP id HAA25674 for ; Fri, 19 Apr 2002 07:22:19 -0400 (EDT) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA15868; Fri, 19 Apr 2002 07:22:18 -0400 (EDT) Message-Id: <200204191122.HAA15868@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; CC: sip@ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Date: Fri, 19 Apr 2002 07:22:18 -0400 Subject: [Sip] I-D ACTION:draft-peterson-sip-privacy-longterm-00.txt Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : A Privacy Mechanism for the Session Initiation Protocol (SIP) Author(s) : J. Peterson Filename : draft-peterson-sip-privacy-longterm-00.txt Pages : 26 Date : 18-Apr-02 This document defines new mechanisms for the Session Initiation Protocol (SIP) in support of privacy. Specifically, guidelines are provided for the creation of messages that do not divulge personal identity information. A new 'privacy service' logical role for intermediaries is defined to answer some privacy requirements that user agents cannot satisfy themselves. Finally, means are presented by which a user can request particular functions from a privacy service. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-peterson-sip-privacy-longterm-00.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-peterson-sip-privacy-longterm-00.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-peterson-sip-privacy-longterm-00.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <20020418140839.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-peterson-sip-privacy-longterm-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-peterson-sip-privacy-longterm-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20020418140839.I-D@ietf.org> --OtherAccess-- --NextPart-- _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Sun Apr 21 10:13:24 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA25415 for ; Sun, 21 Apr 2002 10:13:24 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id KAA00646 for sip-archive@odin.ietf.org; Sun, 21 Apr 2002 10:13:25 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA29702; Sun, 21 Apr 2002 09:46:16 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA29670 for ; Sun, 21 Apr 2002 09:46:12 -0400 (EDT) Received: from cs.columbia.edu (cs.columbia.edu [128.59.16.20]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA24824 for ; Sun, 21 Apr 2002 09:46:10 -0400 (EDT) Received: from opus.cs.columbia.edu (opus.cs.columbia.edu [128.59.20.100]) by cs.columbia.edu (8.9.3/8.9.3) with ESMTP id JAA05409; Sun, 21 Apr 2002 09:46:10 -0400 (EDT) Received: from cs.columbia.edu (cta.cs.columbia.edu [128.59.19.46]) (authenticated bits=0) by opus.cs.columbia.edu (8.12.1/8.12.1) with ESMTP id g3LDk9Pm019288 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Sun, 21 Apr 2002 09:46:09 -0400 (EDT) Message-ID: <3CC2C29F.69102AD1@cs.columbia.edu> Date: Sun, 21 Apr 2002 09:46:07 -0400 From: Henning Schulzrinne Organization: Columbia University X-Mailer: Mozilla 4.76 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: "Miguel A. Garcia" CC: "Bernie Volz (EUD)" , sip@ietf.org References: <3CC28F6E.C4C2A03A@ericsson.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [Sip] Re: Comment about draft-ietf-sip-dhcpv6-00.txt Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit Thanks; corrected and to be fixed in the next release. "Miguel A. Garcia" wrote: > > Hi: > > A very simple comment regarding the DHCPv6 option for SIP servers I-D. > > The draft has a duplicated reference to the "SIP: locating SIP servers" I-D, future RFC 3263. It is listed as both references 3 and 7. > > Regards, > _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Sun Apr 21 14:51:34 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA00042 for ; Sun, 21 Apr 2002 14:51:34 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id OAA12398 for sip-archive@odin.ietf.org; Sun, 21 Apr 2002 14:51:35 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA09144; Sun, 21 Apr 2002 13:44:21 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA09112 for ; Sun, 21 Apr 2002 13:44:17 -0400 (EDT) Received: from bdsl.66.12.12.130.gte.net (bdsl.66.12.12.130.gte.net [66.12.12.130]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA29116 for ; Sun, 21 Apr 2002 13:44:16 -0400 (EDT) Received: from TXDWILLIS2 (bdsl.greycouncil.com [127.0.0.1]) by bdsl.66.12.12.130.gte.net (8.11.6/8.11.6) with ESMTP id g3LHgwd09369; Sun, 21 Apr 2002 12:42:59 -0500 From: "Dean Willis" To: Cc: "'Rohan Mahy'" , "'Mark Watson'" , "'Flemming Andreasen'" , Subject: RE: Problem 4 of RE: [Sip] Proposed plan for Network-Asserted ID/Privacy Date: Sun, 21 Apr 2002 12:42:47 -0500 Message-ID: <007901c1e95b$f4c520e0$5501a8c0@TXDWILLIS2> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.3416 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Importance: Normal In-Reply-To: <15553.56251.677760.711952@harjus.eng.song.fi> Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit > -----Original Message----- > From: jh@lohi.eng.song.fi [mailto:jh@lohi.eng.song.fi] > Sent: Saturday, April 20, 2002 4:21 PM > To: Dean Willis > Cc: 'Rohan Mahy'; 'Mark Watson'; 'Flemming Andreasen'; sip@ietf.org > Subject: RE: Problem 4 of RE: [Sip] Proposed plan for > Network-Asserted ID/Privacy > > > Dean Willis writes: > > > It COULD map "Username" from an authorization header to > > calling-party-ID. > > no it could not because the user may have any number of > calling party numbers belong to different area codes and even > different countries. the user thus definitely needs to be > able to control the calling party id. Well, the user COULD have many different usernames to present to the gateway, one for each public ID. They might not use the same username for a calling-party-ID service (that is what we're talking about) as they use for routing service on a proxy. It's a different way to look at the problem, and I offer it only as an existence proof for alternatives. -- Dean _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Sun Apr 21 14:53:07 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA00119 for ; Sun, 21 Apr 2002 14:53:07 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id OAA12506 for sip-archive@odin.ietf.org; Sun, 21 Apr 2002 14:53:08 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA09680; Sun, 21 Apr 2002 13:53:22 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA09620 for ; Sun, 21 Apr 2002 13:53:18 -0400 (EDT) Received: from lohi.eng.song.fi (lohi.eng.song.fi [195.10.149.18]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA29211 for ; Sun, 21 Apr 2002 13:53:16 -0400 (EDT) From: jh@lohi.eng.song.fi Received: from harjus.eng.song.fi ([195.10.149.20]) by lohi.eng.song.fi with esmtp (Exim 3.34 #1 (Debian)) id 16zLWQ-0006zs-00; Sun, 21 Apr 2002 20:53:10 +0300 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15554.64645.969501.922211@harjus.eng.song.fi> Date: Sun, 21 Apr 2002 20:53:09 +0300 To: "Dean Willis" Cc: "'Rohan Mahy'" , "'Mark Watson'" , "'Flemming Andreasen'" ,