Inlining of comments is getting out of hand, so I won't.
The example you quoted in draft-ietf-simple-presence-01 has been changed
in draft-ietf-simple-presence-03, apparently because you convinced
Jonathon. This does imply that he believes one contact entry in a
REGISTER can supercede another in the same REGISTER. But I don't think
it is clear that the bis actually requires this.
Given valid reasons for it to work differently, I think this requires
some discussion and eventually some clarification in the text.
Paul
"Ngo, Dai (c)" wrote:
>
> Paul,
>
> Comments in line.
>
> Dai
>
> -----Original Message-----
> From: Paul Kyzivat [mailto:[EMAIL PROTECTED]]
> Sent: Friday, October 12, 2001 1:47 PM
> To: Ngo, Dai (c)
> Cc: [EMAIL PROTECTED]
> Subject: Re: [Sip-implementors] Re: Need clarification on callerprefs
>
> Dai - thanks for responding. I have included further discussion below.
>
> Paul
>
> >
> > Contact: sip:[EMAIL PROTECTED]; language="en"; q=1.0,
> > sip:[EMAIL PROTECTED]; language="es"; q=0.2
> >
> > My question is: is this a legal construction in a Contact header?
> > >>>>>> yes.
> > Normally, if there had been a prior registration of
> >
> > Contact: sip:[EMAIL PROTECTED]; language="en"; q=1.0
> >
> > and a new registration was received containing
> >
> > Contact: sip:[EMAIL PROTECTED]; language="es"; q=0.2
> >
> > then the new contact would *replace* the old one.
> > >>>>>> No. These are two different contacts because the language parameter
> > is used for matching.
>
> >Why do you say that? The callerprefs draft gives rules for matching
> >between the Accept-Contact and Reject-Contact in a request to a set of
> >Contact entries. But it says nothing about changing the matching rules
> >used by a registrar when processing a REGISTER request. The bis document
> >says
>
> >"If a SIP URI in a registration Contact header field differs from
> >existing registrations according to the rules in Section 2.1, it is
> >added to the list of registration. If it is equivalent, according to
> >these rules, to an existing registration, all Contact header field
> >parameters for this entry are updated accordingly."
>
> >In other words, the matching is on the url only. These parameters are
> >not url parameters, they are extension header parameters, and so should
> >not participate in the matching.
>
> ****** You're right. The callerprefs draft spec does not explicitly say it.
> It's just my interpretation. Here is the extraction from section 2 "Overview
> of Operation" of the callerprefs draft that I based on:
> "When a UA registers, it places these parameters in the
> Contact headers to characterize the URIs it is registering. This
> allows the proxy to have information about the contact addresses for
> a user. The parameters are also mirrored in the Contact header in a
> REGISTER response."
> And in section 5.1 "Contact, Accept-Contact and Reject-Contact Parameters"
> of the same draft, it says:
>
> "This specification adds the following extension parameters to the
> Contact header field and defines the same parameters for the Accept-
> Contact and Reject-Contact header fields. These parameters apply to a
> single URI. When used in a Contact header, they specify
> characteristics of the URI in the header. When used in the Accept-
> Contact or Reject-Contact headers, they specify rules to apply for
> matching URIs."
>
> It also states that the description, methods and priority parameters will
> not participate in the matching operation.
>
> >
> > 2) a REGISTER request with multiple contact entries is processed much
> > like multiple REGISTER requests each with a single contact entry. If two
> > contact entries mention the same URI, each one in turn replaces the
> > previous one. Only the last remains. No error occurs.
> >
> > >>>>> I think this is the current behavior.
>
> >Whose? Is this behavior conformant to the documents, or are the
> >documents ambiguous?
>
> **** You're correct again. My statement came as a result of the response
> from J. Rosenberg included as follows:
>
> From: Ngo, Dai (c) [mailto:[EMAIL PROTECTED]]
> Sent: Friday, August 10, 2001 3:36 PM
> To: [EMAIL PROTECTED]
> Subject: [Simple] Preference for Individual URI
>
> >All,
> >In section "5.1 Contact, Accept-Contact and Reject-Contact Parameters" of
> the
> >draft-ietf-sip-callerprefs-04.txt it states that the Methods parameter,
> >Description parameter, and priority parameter for a contact header are NOT
> >used in the matching operation described in Section 6.4.1 of the same
> draft.
> >In addition, the contact URI comparison is based on SIP URI matching
> >rules.
>
> >This implies that in the following example described in the
> draft-ietf-simple-
> >presence-01.txt, the second contact:
> ><sip:[EMAIL PROTECTED]>;methods="SUBSCRIBE" will completely *REPLACE* the
> >first contact: <sip:[EMAIL PROTECTED]>;methods=MESSAGE;description="open"
> due
> >to the fact that the contact URI <sip:[EMAIL PROTECTED]> is the same
> >for
> >both:
>
> > REGISTER sip:example.com SIP/2.0
> > Via: SIP/2.0/UDP pua.example.com:5060
> > To: <sip:[EMAIL PROTECTED]>
> > From: <sip:[EMAIL PROTECTED]>
> > Call-ID: [EMAIL PROTECTED]
> > CSeq: 1 REGISTER
> > Contact: <sip:[EMAIL PROTECTED]>;methods="MESSAGE"
> > ;description="open"
> > Contact: <sip:[EMAIL PROTECTED]>;methods="SUBSCRIBE"
> > Expires: 600
>
> Excellent observation. You are correct.
>
> >
> >So if I'm login into a computer and have one SIP URI
> <sip:[EMAIL PROTECTED]>,
> >the only choice I have is to send a REGISTER with:
> > contact: <sip:[EMAIL PROTECTED]>;methods="MESSAGE,
> >SUBSCRIBE";description="open".
>
> Yes.
>
> >
_______________________________________________
Sip-implementors mailing list
[EMAIL PROTECTED]
http://lists.cs.columbia.edu/mailman/listinfo/sip-implementors
