Re: AW: AW: AW: [Sipping-tispan] Requirements 02e
"Tom-PT Taylor" <taylor@nortel.com> Fri, 30 September 2005 14:09 UTC
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org)
by megatron.ietf.org with esmtp (Exim 4.32)
id 1ELLZW-0008EH-Au; Fri, 30 Sep 2005 10:09:10 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
by megatron.ietf.org with esmtp (Exim 4.32) id 1ELLZU-0008Bd-81
for sipping-tispan@megatron.ietf.org; Fri, 30 Sep 2005 10:09:08 -0400
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA12865
for <sipping-tispan@ietf.org>; Fri, 30 Sep 2005 10:09:06 -0400 (EDT)
Received: from zctfs063.nortelnetworks.com ([47.164.128.120])
by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ELLhJ-0006mb-RT
for sipping-tispan@ietf.org; Fri, 30 Sep 2005 10:17:16 -0400
Received: from zctfhxm1.corp.nortel.com (zctfhxm1.corp.nortel.com
[47.164.129.157])
by zctfs063.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP
id j8UE7bI04024; Fri, 30 Sep 2005 16:07:37 +0200 (MEST)
Received: from zcarhxp0.corp.nortel.com ([47.129.230.91]) by
zctfhxm1.corp.nortel.com with Microsoft SMTPSVC(6.0.3790.211);
Fri, 30 Sep 2005 16:07:36 +0200
Received: from [127.0.0.1] ([47.130.17.215] RDNS failed) by
zcarhxp0.corp.nortel.com with Microsoft SMTPSVC(6.0.3790.211);
Fri, 30 Sep 2005 10:07:34 -0400
Message-ID: <433D46A2.3040502@nortel.com>
Date: Fri, 30 Sep 2005 10:07:30 -0400
From: "Tom-PT Taylor" <taylor@nortel.com>
User-Agent: Mozilla Thunderbird 1.0.6 (Windows/20050716)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Paul Kyzivat <pkyzivat@cisco.com>
Subject: Re: AW: AW: AW: [Sipping-tispan] Requirements 02e
References: <E7666D92C64C2845AEF12636FF94F95202319F9C@S4DE8PSAAGQ.blf.telekom.de>
<433D4067.4000804@cisco.com>
In-Reply-To: <433D4067.4000804@cisco.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
X-OriginalArrivalTime: 30 Sep 2005 14:07:34.0500 (UTC)
FILETIME=[4E236240:01C5C5C8]
Content-Transfer-Encoding: quoted-printable
X-MIME-Autoconverted: from 8bit to quoted-printable by
zctfs063.nortelnetworks.com id j8UE7bI04024
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 8970a17ea8642e1e9e9a967e2088f88d
Content-Transfer-Encoding: quoted-printable
Cc: sipping-tispan@ietf.org
X-BeenThere: sipping-tispan@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Discussion of requirements for SIP introduced by ETSI TISPAN
<sipping-tispan.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/sipping-tispan>,
<mailto:sipping-tispan-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/sipping-tispan>
List-Post: <mailto:sipping-tispan@ietf.org>
List-Help: <mailto:sipping-tispan-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/sipping-tispan>,
<mailto:sipping-tispan-request@ietf.org?subject=subscribe>
Sender: sipping-tispan-bounces@ietf.org
Errors-To: sipping-tispan-bounces@ietf.org
It's not quite that dramatic. I seem to recall that this sort of capability requires a "special arrangement" between the caller's organization and the service provider. There's a certain amount of transitive trust based on that -- the service provider might end the arrangement if there are complaints. Agreed, that's not a lot. BTW the identity I've configured on my SIP client seems to be displayed in the PSTN unchanged. Paul Kyzivat wrote: > > > Jesske, R wrote: > >> Paul, >> with regard to the interworking to the PSTN/ PSTN Phones via a >> Terminal adapter the same procedures as used within the PSTN/ISDN apply. >> >> The P-Asserted-Id is mapped to the Connected number and the "new >> P-Additional ID" is mapped to the Generic number (additional Connected >> number). >> >> When at the originating Switch a backward message is received with >> both elements only the user provided (additional connected number) >> will presented to the user. >> The connected number is stored within the exchange. >> >> We have the same mapping and procedures with the P-Asserted-ID and the >> >From header. > > > So, what you are telling me is that callerid (and callee identity) is a > complete joke - that it has no legitimacy at all! The value displayed > *may* be a value authenticated by the provider, and it *may* be a value > that was provided by the other end without authentication, and I have no > way of discerning which it is. So I must assume that callerid is always > a lie. > > And this is a service you wish to simulate ??? > > Paul > >> I hope this clarifies. >> >> Bets Regards >> >> Roland >> >> >>> -----Ursprüngliche Nachricht----- >>> Von: Paul Kyzivat [mailto:pkyzivat@cisco.com] Gesendet: Donnerstag, >>> 29. September 2005 15:05 >>> An: Jesske, Roland >>> Cc: Miguel.An.Garcia@nokia.com; sipping-tispan@ietf.org >>> Betreff: Re: AW: AW: [Sipping-tispan] Requirements 02e >>> >>> >>> >>> >>> Jesske, R wrote: >>> >>>> Paul, >>>> The callee has the possibility to subscribe to an not >>> >>> >>> screening option so that the additional identity can be included by >>> the subscriber. >>> >>>> So the final SIP response will include a P-Asserted-id and >>> >>> >>> an additional identity. >>> >>>> So the originating user can receive either two identities >>> >>> >>> or only one. >>> >>>> It is up to the UA to decide which one shall be presented. >>>> >>>> With regard to the PSTN/ISDN service this is true. But If I >>> >>> >>> see the presentation of the From header and the P-Asserted-Identity >>> header in forward direction, I think we should do the same in >>> backward direction, that both identities will be sent to the Caller >>> back. >>> >>> OK. That relieves some of my concern, since you are leaving the >>> decision of what to display to the UA, and it is clear to the UA >>> which is authenticated and which is not. >>> >>> But I am still interested in what you expect to happen when this is >>> gatewayed to the PSTN, or when the UA is an analog interface >>> connected to a phone with "callerid box". AFAIK, the callerid box >>> will only display one name+number per call and doesn't have any way >>> to indicate whether the id it is displaying has been authenticated or >>> not. This is distressing if the displayed id may sometimes be >>> authenticated and sometimes not. >>> >>> However I don't find the precedent of From vs P-Asserted-ID as >>> compelling for doing something similar in the reverse direction. The >>> From and To headers are turning out to be useless in environments >>> that use P-Asserted-ID, and probably should just be ignored. In this >>> environment it would make some sense to always populate them with >>> Anonymous. >>> >>> Paul >>> >>> >>>> Roland >>>> >>>> >>>> >>>>> -----Ursprüngliche Nachricht----- >>>>> Von: Paul Kyzivat [mailto:pkyzivat@cisco.com] Gesendet: Montag, 26. >>>>> September 2005 17:02 >>>>> An: Jesske, Roland >>>>> Cc: Miguel.An.Garcia@nokia.com; sipping-tispan@ietf.org >>>>> Betreff: Re: AW: [Sipping-tispan] Requirements 02e >>>>> >>>>> >>>>> >>>>> >>>>> Jesske, R wrote: >>>>> >>>>> >>>>>>> -----Ursprüngliche Nachricht----- >>>>>>> Von: sipping-tispan-bounces@ietf.org >>>>>>> [mailto:sipping-tispan-bounces@ietf.org] Im Auftrag von >>> >>> >>> Paul Kyzivat >>> >>>>>>> Gesendet: Donnerstag, 22. September 2005 21:09 >>>>>>> An: Miguel Garcia >>>>>>> Cc: sipping-tispan@ietf.org >>>>>>> Betreff: Re: [Sipping-tispan] Requirements 02e >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> Miguel Garcia wrote: >>>>>>> >>>>>>> >>>>>>> >>>>>>>> That is my understanding. If I recall correctly, the idea >>>>>>> >>>>>>> >>>>>>> is to emulate >>>>>>> >>>>>>> >>>>>>>> the PBX, where the callee can indicate a direct-to-call >>>>>>> >>>>>>> >>>>>>> number (URI). >>>>>>> >>>>>>> OK, so the callee can indicate it. What happens at the calling >>>>>>> end? Is it displayed instead of the callerid? Is it displayed in >>>>>>> addition to the callerid? Is it retained by the calling UA and >>>>>>> used in some circumstance? >>>>>> >>>>>> >>>>>> >>>>>> [RJ] This ID is displayed at the callers UA instead of the >>>>> >>>>> >>>>> dialled number or the P-Asserted-ID sent from the >>> >>> >>> terminating network. >>> >>>>> Which network element makes the decision about which one to >>>>> display? Is it a network element operating on behalf of the callee, >>>>> one operating on behalf of the caller, or is it the caller itself >>>>> that decides? >>>>> >>>>> >>>>> >>>>>> The Reply-to header can only be used in from the Caller so >>>>> >>>>> >>>>> it is not possible to use this ID for the callee. >>>>> >>>>> >>>>>> Also the Contact header is not appropriate. >>>>>> >>>>>> The equivalent in PSTN is the COLP/COLR service. There we >>>>> >>>>> >>>>> have a connected and additional connected number. Normally only the >>>>> connected number that is a network asserted number will be shown. >>>>> But there is also the possibility to allow the user to present a >>>>> number sent from his phone directly. (so called no screening >>>>> option) So we trust the user that it is a dialable and valid >>>>> number. This feature will be used from PBX. >>>>> >>>>> >>>>>> So we want the have the same within SIP. In forward >>>>> >>>>> >>>>> direction we have the From header and the P-Asserted-Identity. But >>>>> in Backward direction the equivalent to the From header is missing. >>>>> >>>>> >>>>>> So we need such an identity header for the backward >>>>> >>>>> >>>>> direction setup from the callee. >>>>> >>>>> It sounds like the calling device gets one number, which could be >>>>> either a number that the network can vouch for, or one that the >>>>> network cannot vouch for. Does the calling device have indication >>> >>> >>> about which >>> >>>>> case holds? If it doesn't trust the number from the callee, can it >>>>> get the asserted id instead? >>>>> >>>>> Paul >>>>> >>>>> >>>>> >>>>>> Roland >>>>>> >>>>>> >>>>>> >>>>>> >>>>>>> This sounds a lot like the SIP Reply-To header, which can be >>>>>>> there and carry information, but which has never had any clear >>>>>>> utility, and so has essentially never been used. >>>>>>> >>>>>>> Paul >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>>> /Miguel >>>>>>>> >>>>>>>> Paul Kyzivat wrote: >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>>> Re TIP: What is the caller supposed to do with this >>>>>>> >>>>>>> >>>>>>> multiplicity of >>>>>>> >>>>>>> >>>>>>>>> addresses? Are we to imagine that the device will present >>>>>>> >>>>>>> >>>>>>> the caller >>>>>>> >>>>>>> >>>>>>>>> with all of them so that he may pick which to use when >>>>>>> >>>>>>> >>>>>>> making a future >>>>>>> >>>>>>> >>>>>>>>> call? >>>>>>>>> >>>>>>>>> Paul >>>>>>>>> >>>>>>>>> Miguel Garcia wrote: >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>>> Inline discussion >>>>>>>>>> >>>>>>>>>> Rocky Wang wrote: >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>>> Hi, Miguel, >>>>>>>>>>> >>>>>>>>>>> For REQ-TIP-1, I agree with you and it is the same of >>>>>>> >>>>>>> >>>>>>> ours. But >>>>>>> >>>>>>> >>>>>>> >>>>>>>>>>> previously I misunderstand it that the direct >>>>>>> >>>>>>> >>>>>>> communication means it >>>>>>> >>>>>>> >>>>>>> >>>>>>>>>>> should reach to the same terminal. >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> Ok, I can add a clarification that there is not a >>>>>>> >>>>>>> >>>>>>> requirement to end >>>>>>> >>>>>>> >>>>>>>>>> up in the same terminal. >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>>> But for REQ-TIP-3, maybe there are still some >>>>>>> >>>>>>> >>>>>>> security problem. >>>>>>> >>>>>>> >>>>>>> >>>>>>>>>>> Suppose user B set and his terminal returns a >>>>> >>>>> >>>>> subscriber C's URI >>>>> >>>>>>>>>>> back to >>>>>>>>>>> the calling party A, then what will happen? It will be >>>>>>> >>>>>>> >>>>>>> possible that >>>>>>> >>>>>>> >>>>>>>>>>> the >>>>>>>>>>> user A will be misleaded to make a call to C but he >>>>>>> >>>>>>> >>>>>>> wants to make >>>>>>> >>>>>>> >>>>>>>>>>> one to >>>>>>>>>>> user B actually. >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> Shame. As I said, there isn't a requirement for the >>>>>>> >>>>>>> >>>>>>> network to assert >>>>>>> >>>>>>> >>>>>>>>>> the additional identity. This has been clarified a few >>>>>>> >>>>>>> >>>>>>> times in the >>>>>>> >>>>>>> >>>>>>>>>> past, and remember, I am not the owner of the >>>>>>> >>>>>>> >>>>>>> requirements, just the >>>>>>> >>>>>>> >>>>>>>>>> scribe. So from TISPAN point of view, the requirement is >>>>>>> >>>>>>> >>>>>>> as is, and >>>>>>> >>>>>>> >>>>>>>>>> the security implications are accepted. >>>>>>>>>> >>>>>>>>>> /Miguel >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>>> Best Regards, >>>>>>>>>>> Rocky Wang >>>>>>>>>>> >>>>>>>>>>> -----Original Message----- >>>>>>>>>>> From: Miguel Garcia [mailto:Miguel.An.Garcia@nokia.com] Sent: >>>>>>>>>>> 2005?9?21? 14:37 >>>>>>>>>>> To: Rocky Wang >>>>>>>>>>> Cc: sipping-tispan@ietf.org >>>>>>>>>>> Subject: Re: [Sipping-tispan] Requirements 02e >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> Hi Rocky: >>>>>>>>>>> >>>>>>>>>>> inline discussion. >>>>>>>>>>> >>>>>>>>>>> Rocky Wang wrote: >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>>> But I have some more doubts on TIP: >>>>>>>>>>>> REQ-TIP-1: In addition to any network asserted >>>>>>> >>>>>>> >>>>>>> identity, it must be >>>>>>> >>>>>>> >>>>>>> >>>>>>>>>>>> possible for the callee to indicate in a >>>>>>> >>>>>>> >>>>>>> SIP response an >>>>>>> >>>>>>> >>>>>>> >>>>>>>>>>>> additional identity where he is reachable >>>>>>> >>>>>>> >>>>>>> for future >>>>>>> >>>>>>> >>>>>>> >>>>>>>>>>>> direct communications. >>>>>>>>>>>> Does it mean the back identifier must be something >>>>>>> >>>>>>> >>>>>>> like gruu? The >>>>>>> >>>>>>> >>>>>>>>>>>> one who answers the call from one endpoint does not >>>>>>> >>>>>>> >>>>>>> always mean the >>>>>>> >>>>>>> >>>>>>>>>>>> caller should make a call to this endpoint directly later. >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> As far as I understand, there is not a requirement for >>>>>>> >>>>>>> >>>>>>> this to be a >>>>>>> >>>>>>> >>>>>>>>>>> GRUU. This is just another URI that would lead to the >>>>>>> >>>>>>> >>>>>>> same person, >>>>>>> >>>>>>> >>>>>>>>>>> but not necessarily to the same terminal. >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>>> REQ-TIP-3: The identity mentioned in REQ-TIP-1 is >>>>>>> >>>>>>> >>>>>>> considered an end >>>>>>> >>>>>>> >>>>>>> >>>>>>>>>>>> user supplied information that is not >>>>>>> >>>>>>> >>>>>>> asserted by the >>>>>>> >>>>>>> >>>>>>> >>>>>>>>>>>> network. >>>>>>>>>>>> Does it mean the network equipments just transfer >>> >>> >>> the called >>> >>>>>>>>>>>> party's identifier provided by the called party >>>>>>> >>>>>>> >>>>>>> endpoint? It must >>>>>>> >>>>>>> >>>>>>>>>>>> be also asserted, I think. Or, it will cause some >>>>>>> >>>>>>> >>>>>>> security problem. >>>>>>> >>>>>>> >>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> It means that the network does not verify the validity >>>>>>> >>>>>>> >>>>>>> of this URI. >>>>>>> >>>>>>> >>>>>>>>>>> It is up to the user to put something meaningful there. >>>>>>> >>>>>>> >>>>>>> This is the >>>>>>> >>>>>>> >>>>>>>>>>> requirement. >>>>>>>>>>> >>>>>>>>>>> BR, >>>>>>>>>>> >>>>>>>>>>> Miguel >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>>> Regards, >>>>>>>>>>>> Rocky Wang >>>>>>>>>>>> >>>>>>>>>>>> -----Original Message----- >>>>>>>>>>>> From: Miguel Garcia [mailto:Miguel.An.Garcia@nokia.com] >>>>>>>>>>>> Sent: 2005?9?20? 14:46 >>>>>>>>>>>> To: Rocky Wang >>>>>>>>>>>> Cc: sipping-tispan@ietf.org >>>>>>>>>>>> Subject: Re: [Sipping-tispan] Requirements 02e >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> Hi Rocky: >>>>>>>>>>>> >>>>>>>>>>>> Yes, I think we agreed that this is a missing >>>>>>> >>>>>>> >>>>>>> requirement, but we want >>>>>>> >>>>>>> >>>>>>> >>>>>>>>>>>> to write it down when we have finished the other >>>>>>> >>>>>>> >>>>>>> requirements, because >>>>>>> >>>>>>> >>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>>> it may happen that the calling part categories >>>>>>> >>>>>>> >>>>>>> requirements help us in >>>>>>> >>>>>>> >>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>>> creating a proper dependency. >>>>>>>>>>>> >>>>>>>>>>>> So this is not forgotten, it will be added at a later time. >>>>>>>>>>>> >>>>>>>>>>>> BR, >>>>>>>>>>>> >>>>>>>>>>>> Miguel >>>>>>>>>>>> >>>>>>>>>>>> Rocky Wang wrote: >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>>> Hi, Migues, >>>>>>>>>>>>> As I considered, the requirement of overrding ACR >>>>>>> >>>>>>> >>>>>>> service must be >>>>>>> >>>>>>> >>>>>>> >>>>>>>>>>>>> there as a formal requirement. Maybe there are some >>>>>>> >>>>>>> >>>>>>> ways that the >>>>>>> >>>>>>> >>>>>>>>>>>>> called AS to get enough information to determine that >>>>>>> >>>>>>> >>>>>>> it can or >>>>>>> >>>>>>> >>>>>>>>>>>>> cannot >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>>> override the ACR, but there are some cases the >>>>>>> >>>>>>> >>>>>>> simulation service >>>>>>> >>>>>>> >>>>>>>>>>>>> must >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>>> be overrided, including the case you listed in the 02a >>>>>>> >>>>>>> >>>>>>> version. It >>>>>>> >>>>>>> >>>>>>>>>>>>> can >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>>> be like this: 1. The originating network shall be able >>>>>>> >>>>>>> >>>>>>> to take enough >>>>>>> >>>>>>> >>>>>>> >>>>>>>>>>>>> calling party's information to the terminating network >>>>>>> >>>>>>> >>>>>>> to help to >>>>>>> >>>>>>> >>>>>>>>>>>>> override the callee's ACR service. 2. The >>> >>> >>> terminating network >>> >>>>>>>>>>>>> shall be >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>>> able to override the callee's ACR simulation service >>>>>>> >>>>>>> >>>>>>> if the caller is >>>>>>> >>>>>>> >>>>>>> >>>>>>>>>>>>> authorized to do this based on the caller's information. >>>>>>>>>>>>> >>>>>>>>>>>>> Rocky Wang >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> -----Original Message----- >>>>>>>>>>>>> From: sipping-tispan-bounces@ietf.org >>>>>>>>>>>>> [mailto:sipping-tispan-bounces@ietf.org] On Behalf Of >>>>>>> >>>>>>> >>>>>>> Miguel Garcia >>>>>>> >>>>>>> >>>>>>> >>>>>>>>>>>>> Sent: 2005?9?9? 20:57 >>>>>>>>>>>>> To: 'sipping-tispan@ietf.org' >>>>>>>>>>>>> Subject: [Sipping-tispan] Requirements 02e >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> Hi: >>>>>>>>>>>>> >>>>>>>>>>>>> I have another working copy of the TISPAN >>>>>>> >>>>>>> >>>>>>> requirements, now version >>>>>>> >>>>>>> >>>>>>> >>>>>>>>>>>>> 02e: >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>> >>>>>>> http://people.nokia.net/~miguel/drafts/pre/draft-jesske-sippin >>>>>>> g-tispan >>>>>>> >>>>>>> >>>>>>>>>>>>> -r >>>>>>>>>>>>> equirements-02e.html >>>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>> http://people.nokia.net/~miguel/drafts/pre/draft-jesske-sipp >>>> >>>> >>>> ing-tispan >>>> >>>> >>>>>>>>>>> -r >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>>> equirements-02e.txt >>>>>>>>>>>> >>>>>>>>>>>> And a diff version with respect 02d: >>>>>>>>>>>> >>>>>> >>>>>> http://people.nokia.net/~miguel/drafts/pre/draft-jesske-sippin >>>>> >>>>> >>>>> g-tispan >>>>> >>>>> >>>>>>>>>>> -r >>>>>>>>>>> equirements-02d-to-e.html >>>>>>>>>>> >>>>>>>>>>> The main changes this time are: >>>>>>>>>>> >>>>>>>>>>> - Rewording of the CCBS/CCNR requirements as per our >>> >>> >>> discussion. I >>> >>>>>>>>>>> have >>>>>>>>>>> added a few definitions and try to reorder them >>> >>> >>> sequentially, so >>> >>>>>>>>>>> that they are a bit easier to understand. >>>>>>>>>>> - Clarification that the TIP requirements are for an >>> >>> >>> additional (to >>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> the >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>>> asserted) identity. >>>>>>>>>>> - Addition of the Communication Waiting requirements >>>>>>>>>>> >>>>>>>>>>> Please feel free to comment, but bear in mind that due to the >>>>>>>>>>> TISPAN meeting next week most of the TISPANers will >>> >>> >>> have limited >>> >>>>>>>>>>> time to discuss. >>>>>>>>>>> >>>>>>>>>>> /Miguel >>>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>> _______________________________________________ >>>>> Sipping-tispan mailing list >>>>> Sipping-tispan@ietf.org >>>>> https://www1.ietf.org/mailman/listinfo/sipping-tispan >>>>> >>>> >>>> >> > > _______________________________________________ > Sipping-tispan mailing list > Sipping-tispan@ietf.org > https://www1.ietf.org/mailman/listinfo/sipping-tispan > > _______________________________________________ Sipping-tispan mailing list Sipping-tispan@ietf.org https://www1.ietf.org/mailman/listinfo/sipping-tispan
- AW: AW: AW: [Sipping-tispan] Requirements 02e Jesske, R
- Re: AW: AW: AW: [Sipping-tispan] Requirements 02e Paul Kyzivat
- Re: AW: AW: AW: [Sipping-tispan] Requirements 02e Tom-PT Taylor
- RE: AW: AW: AW: [Sipping-tispan] Requirements 02e GARCIN Sebastien RD-CORE-ISS
- Re: AW: AW: AW: [Sipping-tispan] Requirements 02e Paul Kyzivat