Dai - thanks for responding. I have included further discussion below.
Paul
"Ngo, Dai (c)" wrote:
>
> Comments in line.
>
> -- Dai
>
> -----Original Message-----
> From: Paul Kyzivat [mailto:[EMAIL PROTECTED]]
> Sent: Friday, October 12, 2001 10:22 AM
> To: [EMAIL PROTECTED]
> Subject: [Sip-implementors] Re: Need clarification on callerprefs
>
> I have another question about callerprefs, in addition to the earlier
> messages I have posted on this subject. This is primarily a question
> about the handling of REGISTER by a registrar, but the question only
> makes sense in the context of the changes to the Contact header proposed
> in draft-ietf-sip-callerprefs-04.
>
> Section 5.1 says: "This specification adds the following extension
> parameters to the Contact header field ... These parameters apply to a
> single URI. When used in a Contact header, they specify characteristics
> of the URI in the header."
>
> Now, suppose I want to specify that a given URI is fully capable in
> English and slightly capable in Spanish. This is a reasonable thing to
> want to specify, and there seems to be a way to do it:
>
> 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.
>
> As far as I can tell,
> the bis is silent on what should happen if two contacts with the same
> URI are present in the same register request. I can see three possible
> interpretations:
>
> 1) upon receipt of the REGISTER request, the registrar first removes any
> previously registered contact entries that match any of the contact
> entries in this REGISTER request. Then all the contact entries in this
> register request are saved.
>
> 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?
>
> 3) a REGISTER request with multiple contact entries containing the same
> URI is considered erroneous, and results in an error such as 400 Bad
> Request.
>
> Of these, (1) is compatible with the example above while the others
> aren't. (2) is a silly interpretation - it is never useful. (3) forbids
> a useful application and is extra work to detect.
>
> I would like to see a clarification somewhere that (1) is the required
> behavior. I don't know if this belongs in draft-ietf-sip-rfc2543bis-*,
> or in draft-ietf-sip-callerprefs-*.
>
> Thanks,
> Paul Kyzivat
> Cisco Systems
> _______________________________________________
> Sip-implementors mailing list
> [EMAIL PROTECTED]
> http://lists.cs.columbia.edu/mailman/listinfo/sip-implementors
_______________________________________________
Sip-implementors mailing list
[EMAIL PROTECTED]
http://lists.cs.columbia.edu/mailman/listinfo/sip-implementors
