[Sip] Question on RFC3840/3841 - matching of list values

"Christer Holmberg" <christer.holmberg@ericsson.com> Fri, 18 January 2008 13:26 UTC

Return-path: <sip-bounces@ietf.org>
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1JFrEr-0007Vl-C8; Fri, 18 Jan 2008 08:26:29 -0500
Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1JFrEq-0007Vf-0F for sip-confirm+ok@megatron.ietf.org; Fri, 18 Jan 2008 08:26:28 -0500
Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JFrEp-0007VL-KL for sip@ietf.org; Fri, 18 Jan 2008 08:26:27 -0500
Received: from mailgw4.ericsson.se ([193.180.251.62]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1JFrEo-0003EW-2l for sip@ietf.org; Fri, 18 Jan 2008 08:26:27 -0500
Received: from mailgw4.ericsson.se (unknown [127.0.0.1]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id 6356E21447; Fri, 18 Jan 2008 14:26:25 +0100 (CET)
X-AuditID: c1b4fb3e-ac5ebbb0000007e1-71-4790a9010181
Received: from esealmw128.eemea.ericsson.se (unknown [153.88.254.121]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id 445C921347; Fri, 18 Jan 2008 14:26:25 +0100 (CET)
Received: from esealmw113.eemea.ericsson.se ([153.88.200.4]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Fri, 18 Jan 2008 14:26:24 +0100
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Date: Fri, 18 Jan 2008 14:26:24 +0100
Message-ID: <CA9998CD4A020D418654FCDEF4E707DF0422916E@esealmw113.eemea.ericsson.se>
In-Reply-To: <478633C4.2060209@cisco.com>
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
Thread-Topic: Question on RFC3840/3841 - matching of list values
Thread-Index: AchTmf6noFFXdaVITfq5Wi/PDr3BpAGFJA+A
References: <CA9998CD4A020D418654FCDEF4E707DF03F7A681@esealmw113.eemea.ericsson.se> <038901c852c3$d222b750$bd4a6c6b@sisodomain.com> <4784D96A.5010104@cisco.com> <040101c852e3$a627f730$bd4a6c6b@sisodomain.com> <004401c8533f$8d197500$bd4a6c6b@sisodomain.com> <CA9998CD4A020D418654FCDEF4E707DF03FA6BD8@esealmw113.eemea.ericsson.se> <006401c85386$59ec2370$bd4a6c6b@sisodomain.com> <478629C1.5090404@cisco.com> <CA9998CD4A020D418654FCDEF4E707DF03FD0FDC@esealmw113.eemea.ericsson.se> <478633C4.2060209@cisco.com>
From: "Christer Holmberg" <christer.holmberg@ericsson.com>
To: "Paul Kyzivat" <pkyzivat@cisco.com>, <sip@ietf.org>
X-OriginalArrivalTime: 18 Jan 2008 13:26:24.0803 (UTC) FILETIME=[B9138730:01C859D5]
X-Brightmail-Tracker: AAAAAA==
X-Spam-Score: 0.0 (/)
X-Scan-Signature: cbb41f2dbf0f142369614756642005e3
Cc:
Subject: [Sip] Question on RFC3840/3841 - matching of list values
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Session Initiation Protocol <sip.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/sip>, <mailto:sip-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:sip@ietf.org>
List-Help: <mailto:sip-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/sip>, <mailto:sip-request@ietf.org?subject=subscribe>
Errors-To: sip-bounces@ietf.org

 
Hi,

One question is I have is related to the matching of list values.

First, when a user registers the SIP methods is supports, it can be a
list of methods (e.g. methods="INVITE, BYE,....)

Then, when a request comes, it is automatically assigend an implicit
method preference, e.g. (methods="INVITE").


But, what if the request also contains a list of values.



Assume the user registers the following feature-tag, with a list of
values:

myTag=a,b

Which will generate (| (myTag=a) (myTag=b))

Now, I can receive the following in the Contact:


1.	myTag=a,b			I assume that is a match
2.	myTag=a			Is that a match?
3.	myTag=b			Is that a match?
4.	myTag=b,a			Is that a match?
5.	myTag=a,b,c			Is that a match?



Now, IF it is enough that either a or b in my request is needed for a
match, but I want both a AND b to match, I guess I would have to do the
following:

Accept-Contact:*, myTag=a
Accept-Contact:*, myTag=b

(or, Accept-Contact: *;myTag=a, *;myTag=b

...which would generate:

(& (myTag=a) (myTag=b))


Regards,

Christer








> -----Original Message-----
> From: Paul Kyzivat [mailto:pkyzivat@cisco.com] 
> Sent: 10. tammikuuta 2008 17:04
> To: Christer Holmberg
> Cc: Mahesh Anjanappa; sip@ietf.org
> Subject: Re: [Sip] Question on RFC3840/3841
> 
> Christer,
> 
> RFC3840 by itself, without 2533, is *not* sufficient to 
> understand how to do the matching.
> 
> I put an appendix in RFC 4596 that gives an algorithm without 
> reference to 2533. I *think* it is right, but of course it is 
> not normative.
> 
> Note that IMO none of this is intuitive or straightforward. 
> Every time I get a detailed question on it I have to do a 
> bunch of review before I can answer it. (But maybe that's 
> just because I don't have enough neurons left.)
> 
> 	Paul
> 
> Christer Holmberg wrote:
> > Paul,
> > 
> > Regarding the matching, are you saying that reading RFC3840 
> is enough 
> > to understand how the matching is done in a "SIP 
> environment"? Or, do 
> > I also need to read RFC2533?
> > 
> > I have some questions on the matching, but I will come back to them 
> > later. I still have some reading to do.
> > 
> > Regards,
> > 
> > Christer
> > 
> >  
> > 
> >> -----Original Message-----
> >> From: Paul Kyzivat [mailto:pkyzivat@cisco.com]
> >> Sent: 10. tammikuuta 2008 16:21
> >> To: Mahesh Anjanappa
> >> Cc: Christer Holmberg; sip@ietf.org
> >> Subject: Re: [Sip] Question on RFC3840/3841
> >>
> >>
> >>
> >> Mahesh Anjanappa wrote:
> >>> Yes the ';' is a mistake. But i'm not sure if  each 
> Contact should 
> >>> contain "alice@atlanta.com"
> >> Well, it has to have a URI to be syntactically correct.
> >>
> >> Your problem is that you are trying to express something 
> that cannot 
> >> be expressed with the callee caps syntax. It only maps to 
> a subset of 
> >> the syntax supported by RFC 2533.
> >>
> >>> because the predicate that i'm trying to represent is as follows 
> >>> meanig to say alice supports a communication which whose
> >> capability is
> >>> Duplex Audio + One Way Video.
> >> You just can't say that. Sorry.
> >>
> >> A little history may help you to understand, though it won't solve 
> >> your
> >> problem:
> >>
> >> The initial draft for callerprefs came out a very long 
> time ago. (The 
> >> earliest draft I have is -03 which came out in november of 
> 2000.) It 
> >> set the basic syntax and the initial set of capabilities.
> >>
> >> It was however very weak on the semantics of matching. I 
> eventually 
> >> got involved because I was interested in it and identified many of 
> >> the semantic issues. Jonathan and I worked on it for a long time.
> >> Eventually, because of some review comments I think, 
> Jonathan tried 
> >> to define the semantics using RFC 2533 because it was a 
> standard that 
> >> seemed to be at least partially suitable to the task. (In 
> retrospect 
> >> this may not have been such a good idea, since it adds an 
> additional 
> >> layer of complexity.)
> >>
> >> RFC 2533 syntax is much richer. But it was not a goal to 
> provide that 
> >> richness. (Mapping that all onto SIP header syntax would 
> be awful.) 
> >> It was only used as an intermediate form to define the 
> semantics of 
> >> the SIP headers.
> >>
> >> Its understood that there are lots of things one might want to 
> >> express that you can't express.
> >>
> >> If you aren't already aware of it, you might want to look 
> at RFC 4596 
> >> (Guidelines for Usage of the Session Initiation Protocol 
> (SIP) Caller 
> >> Preferences Extension).
> >>
> >> 	Paul
> >>
> >>> If each of the COntact contains alice@atlanta.com wouldnt it be 
> >>> interpreted as " alice supports duplex audio and oneway video 
> >>> separatley and not both at the same time".
> >>> Actually i'm not quite sure how to represesnt the 
> predicate in the 
> >>> Contact header correctly, hence my Queries. It all stems from the 
> >>> statement which you too noted " There MUST only be one
> >> instance of any
> >>> feature tag in feature-param." in RFC 3840
> >>>
> >>>
> >>> Predicate:
> >>> ------------
> >>> & ( & (sip.audio) (sip.duplex=full) )
> >>>    (  & (sip.video) (sip.duplex=receive-only) )
> >>>
> >>> regards
> >>> Mahesh
> >>> ----- Original Message ----- From: "Christer Holmberg" 
> >>> <christer.holmberg@ericsson.com>
> >>> To: "Mahesh Anjanappa" <mahesha@samsung.com>om>; "Paul Kyzivat" 
> >>> <pkyzivat@cisco.com>
> >>> Cc: <sip@ietf.org>
> >>> Sent: Thursday, January 10, 2008 11:30 AM
> >>> Subject: RE: [Sip] Question on RFC3840/3841
> >>>
> >>>
> >>>
> >>> Shouldn't each Contact also contain "alice@atlanta.com"?
> >>>
> >>> Also, why do you have ";" at the end of each Contact?
> >>>
> >>> Regards,
> >>>
> >>> Christer
> >>>
> >>>
> >>>
> >>>> -----Original Message-----
> >>>> From: Mahesh Anjanappa [mailto:mahesha@samsung.com]
> >>>> Sent: 10. tammikuuta 2008 6:16
> >>>> To: Paul Kyzivat
> >>>> Cc: sip@ietf.org; Christer Holmberg
> >>>> Subject: Re: [Sip] Question on RFC3840/3841
> >>>>
> >>>> hi Paul,
> >>>> Sorry there is a mistake in Contact header i 
> described.Following is 
> >>>> what i wanted to:
> >>>> Contact:sip:alice@atlanta.com;
> >>>> Contact:audio;duplex=full;
> >>>> Contact:video;duplex=recieve-only;
> >>>>
> >>>> Thanks
> >>>> Mahesh
> >>>> ----- Original Message -----
> >>>> From: "Mahesh Anjanappa" <mahesha@samsung.com>
> >>>> To: "Paul Kyzivat" <pkyzivat@cisco.com>
> >>>> Cc: <sip@ietf.org>rg>; "Christer Holmberg"
> >>>> <christer.holmberg@ericsson.com>
> >>>> Sent: Wednesday, January 09, 2008 10:48 PM
> >>>> Subject: Re: [Sip] Question on RFC3840/3841
> >>>>
> >>>>
> >>>>> Thanks Paul.
> >>>>> So would it be right if i have a Contact Headers describing
> >>>> Duplex Audio &
> >>>>> one-way Video Capabilities as follows?
> >>>>>
> >>>>>    Contact:sip:alice@atlanta.com;
> >>>>>    Contact:sip:audio;duplex=full;
> >>>>>    Contact:sip:video;duplex=recieve-only;
> >>>>>
> >>>>> NOTE: The Predicate(for above) for which i'm attempting 
> is & ( & 
> >>>>> (sip.audio) (sip.duplex=full) )
> >>>>>    (  & (sip.video) (sip.duplex=receive-only) )
> >>>>>
> >>>>> regards
> >>>>> Mahesh
> >>>>>
> >>>>> ----- Original Message ----- > From: "Paul Kyzivat" 
> >>>> <pkyzivat@cisco.com>
> >>>>> To: "Mahesh Anjanappa" <mahesha@samsung.com>
> >>>>> Cc: "Christer Holmberg" <christer.holmberg@ericsson.com>om>;
> >>>> <sip@ietf.org>
> >>>>> Sent: Wednesday, January 09, 2008 7:55 PM
> >>>>> Subject: Re: [Sip] Question on RFC3840/3841
> >>>>>
> >>>>>
> >>>>>>
> >>>>>> Mahesh Anjanappa wrote:
> >>>>>>> hi
> >>>>>>> That is my understanding as well. But if that is the case
> >>>> then it should
> >>>>>>> apply to Contact header as well
> >>>>>>> when describing Capabilities using Feature parameters in
> >>>> Contact Header.
> >>>>>>> But i'm not sure if it applies the same way. I had posted
> >>>> this question
> >>>>>>> long ago but didnt get any comments on it.
> >>>>>> The rule forbidding multiple instances of a parameter
> >>>> applies to all
> >>>>>> headers, so it applies to Contact.  E.g. the following
> >> is illegal:
> >>>>>> Contact:sip:alice@atlanta.com;methods="INVITE";methods="CANCEL"
> >>>>>>
> >>>>>> Paul
> >>>>>
> >>>>>
> >>>>> _______________________________________________
> >>>>> 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