Subject: [Sip] FW: [Sip-implementors] doubt/bug with RFC-3455

From: "Nataraju A B" <[email-masked]>
Date: Mon, 23 Jan 2006 17:17:04 +0530

Hi All, 

I am posting the same query here in sipping since I did not get any
convincing answers in sip-Implementors list...... 

Thanks & Regards,
Nataraju A.B.

-----Original Message-----
From: [email-masked]
[mailto:[email-masked]] On Behalf Of Nataraju
A B
Sent: Friday, January 20, 2006 11:57 AM
To: [email-masked]
Subject: [Sip-implementors] doubt/bug with RFC-3455

Hi All, 

I have a doubt in the rfc 3455 with respect to P-Associated-URI syntax, 

Excerpt from RFC-3455 
<<<
4.1.2 Usage of the P-Associated-URI header

   The registrar inserts the P-Associated-URI header field into the 200
   OK response to a REGISTER request.  The header field value is
   populated with a list containing zero or more URIs that are
   associated to the address-of-record.
   If the registrar supports the P-Associated-URI header extension, then
   the registrar MUST always insert the P-Associated-URI header field in
   all the 200 OK responses to a REGISTER request, regardless of whether
   the REGISTER was an initial registration, re-registration, or
   de-registration and regardless of whether there are zero or more
   associated URIs.

it says if the registrar supports P-Associated-URI, then it has to
insert the P-Asserted-URI in 200 OK response for REGISTER 
while defining the ABNF for the same its been mentioned as 

      P-Associated-URI       = "P-Associated-URI" HCOLON
                               (p-aso-uri-spec)
                               *(COMMA p-aso-uri-spec)
      p-aso-uri-spec         = name-addr *(SEMI ai-param)
      ai-param               = generic-param

This ABNF syntax says as one or more, not zero or more number of
p-aso-uri-spec, 

Now my question is? 
1) Why do we need to insert the P-Associated-URI header if there are no
entry to fill in ? 
2) How do we specify the zero or more P-Associated-URI header values ? 

Best Regards,
Nataraju A.B. 
Kodiak Networks  Ind Pvt Ltd
"Change your thoughts, and you change your world."

_______________________________________________
Sip-implementors mailing list
[email-masked]
https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors

_______________________________________________
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: Miguel Garcia <[email-masked]>
Date: Tue, 24 Jan 2006 08:24:05 +0200

Hi Nataraju.

The spirit of the document was to have a simple mechanism where the UAC 
can notice if the P-Associated-URI extension is supported by the 
registrar. The idea was that, if the extension is supported, the 
registrar includes the header in the 200 OK response. That obviously 
requires the possibility of having an empty header, if the user under 
registration, does not have an associated URI.

Unfortunately, as you discovered, the formal syntax does not reflect 
this fact, and there is a contradiction between the formal syntax and 
the normative text. In this case, I consider the normative text to be 
correct (not the syntax).

BR,

       Miguel

-- 
Miguel A. Garcia           tel:+358-50-4804586
sip:[email-masked]
Nokia Research Center      Helsinki, Finland

---

From: Paul Kyzivat <[email-masked]>
Date: Tue, 24 Jan 2006 10:24:44 -0500

> correct (not the syntax).

Hmm. I buy the text as describing things that are not expressable in 
ABNF. But its a bit much to expect someone to process messages that 
conflict with the ABNF based on the text.

	Paul

>> Excerpt from RFC-3455 <<<
>> insert the P-Asserted-URI in 200 OK response for REGISTER while 
>> defining the ABNF for the same its been mentioned as
>> Now my question is? 1) Why do we need to insert the P-Associated-URI 
>> header if there are no
>> entry to fill in ? 2) How do we specify the zero or more 
>> P-Associated-URI header values ?
>> Best Regards,
>> Nataraju A.B. Kodiak Networks  Ind Pvt Ltd