Subject: RE: [Sip] Asserted-Identity: How to 'hint'?

From: "Drage, Keith (Keith)" <[email-masked]>
Date: Fri, 24 May 2002 11:49:34 +0100

With a 3GPP hat on, just to confirm that the "hint" is as much part of the 3GPP requirements as is the Asserted-Identity, and both are absolutely essential to the release we are trying to freeze now.

Moreover, things are now running pretty close to the wire in terms of getting this in. Can we have a decision on this as soon as possible, and then get the revised drafts out for discussion on the SIP list, so we can get a clear idea of what the SIP working group view is. I do not think we really mind what the decision is; is there an IETF equivalent of tossing a coin? Within 3GPP we have got about as far as we get on this issue without going away and making it up for ourselves.

And before anybody says yet again that this is a 3GPP only solution, I would point out that at both the SIP/SIPPING ad-hoc and in Las Vegas and on this list, the wireline operator's have been shouting for it just as much.

Keith

> -----Original Message-----
> From: Mark Watson [mailto:[email-masked]]
> Sent: 22 May 2002 14:59
> To: 'Peterson, Jon'; 'Rohan Mahy'; [email-masked]
> Subject: RE: [Sip] Asserted-Identity: How to 'hint'?
> Importance: High
> 
> 
> All,
> 
> Can we have a *decision* asap as to whether the 'hint' uses
> Asserted-Identity, or another header in another draft.
> 
> I do not mind which. If the latter I will publish an I-D 
> describing it as
> soon as we have a decision, assuming it is this week, since 
> I'm away next
> week.
> 
> If we do nothing, then I guess 3GPP will make up its own mind 
> how to do
> this, without supervision or advice from IETF, which I think 
> would  be a bad
> thing.
> 
> Regards...Mark
> 
> 
> -----Original Message-----
> From: Watson, Mark [MDN05:EP10:EXCH] 
> Sent: 20 May 2002 12:08
> To: 'Peterson, Jon'; 'Rohan Mahy'
> Cc: [email-masked]
> Subject: RE: [Sip] Asserted-Identity: How to 'hint'?
> 
> 
> The 'hint' was one of the three requirements that 3GPP 
> communicated to us in
> April. 
> It is a separate requirement from the Network Asserted 
> Identity itself, and
> so is not addressed in the requirements draft, although I 
> have been careful
> to point this out, and to point out that it is a requirement 
> nontheless, on
> several occasions.
> I believe we need the 'hint' in the same timeframe as the 
> rest of the short
> term work. 
> Whether it is the same header/draft or a different 
> header/draft is another
> question on which I will only say that we'd better make up 
> our minds pretty
> quick.
> ...Mark 
> 
> 
> > -----Original Message----- 
> > From: Peterson, Jon [mailto:[email-masked]] 
> > Sent: 19 May 2002 18:11 
> > To: 'Rohan Mahy' 
> > Cc: [email-masked] 
> > Subject: RE: [Sip] Asserted-Identity: How to 'hint'? 
> > 
> > 
> > 
> > My argument was not that the proposed hint won't work - just 
> > that it isn't 
> > necessary to solve the problem at hand. It might not be the 
> > case that the 
> > problems with the hint stop at the philosophical point you 
> > mention below. 
> > What I asked in my last mail was not whether or not we needed 
> > a hint, but 
> > rather whether or not we should table that question until we 
> > resolve the 
> > other questions at hand. I just don't want to spend the 
> > cycles arguing about 
> > the hint given our very aggressive timetable - frankly, I 
> think that 
> > reaching consensus on this hint matter might push back our 
> > dates a bit. 
> > Let's investigate this hint stuff in June, but for now just 
> > figure out how a 
> > Trust Domain can manage an asserted identity in a message. 
> > 
> > Jon Peterson 
> > NeuStar, Inc. 
> > 
> > > -----Original Message----- 
> > > From: Rohan Mahy [mailto:[email-masked]] 
> > > Sent: Sunday, May 19, 2002 8:29 AM 
> > > To: Peterson, Jon 
> > > Cc: [email-masked] 
> > > Subject: Re: [Sip] Asserted-Identity: How to 'hint'? 
> > > 
> > > 
> > > Hi, 
> > > 
> > > The requirement for a hint is well understood, limited in 
> > > scope, and well motivated in the draft.  Nobody has identified 
> > > any technical reason why the hint won't work.   Your argument 
> > > that allowing a hint weakens the strength of the language on 
> > > ignoring Asserted-Identity from untrusted parties is purely 
> > > philosophical in nature.  I don't buy your argument. 
> > > 
> > > thanks, 
> > > -rohan 
> > > 
> > > 
> > > ---- Original message ---- 
> > > >Date: Fri, 17 May 2002 16:02:11 -0500 
> > > >From: "Peterson, Jon" <[email-masked]>  
> > > >Subject: [Sip] Asserted-Identity: How to 'hint'?  
> > > >To: "[email-masked]'" <[email-masked]> 
> > > > 
> > > > 
> > > >In the course of the discussion between Mark Watson, Cullen 
> > > Jennings and 
> > > >myself about the short-term identity work, we have returned a 
> > > few times to 
> > > >the question of the infamous hint. This hint is, of course, a 
> > > way that a 
> > > >user agent (one that is not a member of the Trust Domain in 
> > > the short-term 
> > > >network asserted identity space) can provide a 'hint' to the 
> > > intermediary 
> > > >that will generate an Asserted-Identity indicating which 
> > > identity among 
> > > >several possibilities should be asserted. 
> > > > 
> > > >The need for this arises particularly from the 3G space, in 
> > > which the 
> > > >authentication process takes place independently of SIP and 
> > > does not carry 
> > > >this sort of personal identity information. It also assumes 
> > > that the 
> > > >operators of the intermediary in question are aware of 
> > > several legitimate 
> > > >identities which the user can elect to assert. 
> > > > 
> > > >It has been proposed on the mailing list and elsewhere that the 
> > > >Asserted-Identity header should be re-used by user agents 
> > > outside the Trust 
> > > >Domain to provide such a hint. I see a number of reasons for 
> > > and against 
> > > >using the Asserted-Identity for this purpose. For example, 
> > > today, there is a 
> > > >requirement that asserted-identities which are transmitted 
> > > from untrusted 
> > > >sources should not be used in any way - this would seem to 
> > > weaken that 
> > > >requirement. There is also possibly some behavior that still 
> > > needs to be 
> > > >specified (like how an intermediary would reject or otherwise 
> > > handle a 
> > > >request with an inappropriate hint) that might be impactful 
> > > to our choice. 
> > > > 
> > > >For the time being, however, I would like to suggest that 
> > > providing the hint 
> > > >is outside the scope of the current deliverables (the 
> > > asserted-identity 
> > > >requirements and mechanism drafts), which need to be 
> > > complete, as we 
> > > >discussed in the interim meeting, by the end of this month. I 
> > > believe that a 
> > > >separate draft should propose the use of Asserted-Identity or 
> > > any other 
> > > >header for this hint (in whatever timeframe is appropriate 
> > > for 3G's 
> > > >requirements), but that we should not speak to this matter in 
> > > the current 
> > > >asserted-identity deliverables. There is, as I see it, no 
> > > dependency on 
> > > >defining this hint before we dictate how intermediaries will 
> > > assert 
> > > >identities. 
> > > > 
> > > >Any comments on this plan? 
> > > > 
> > > >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 [email-masked] for questions on 
> current sip 
> > > >Use [email-masked] 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 [email-masked] for questions on current sip 
> > Use [email-masked] 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 [email-masked] for questions on current sip
> Use [email-masked] 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 [email-masked] for questions on current sip
Use [email-masked] for new developments on the application of sip

---

From: Aymeric MOIZARD <[email-masked]>
Date: Fri, 24 May 2002 13:34:34 +0200

Reading the 17.23 section about the rules used to
match a request, I found a possible issue.

The spec says: [we must check the via branch, via sent-by
parameter] "and in the case of a CANCEL
request, the method of the request that created
the transaction was also CANCEL.

In the case where a pending CANCEL is going on and
we are receiving an retransmission of INVITE. The
INVITE will contains the same via branch and sent-by
and is not a CANCEL, so it will match the CANCEL
transaction according the rules defined. (the test
expect us to test the method only for CANCEL request!)

I am true if I say that the cseq method must always
be compared and not only for CSeq?

Aymeric