Subject: RE: [Sip] RFC 3261 Ambiguous SIP URI table in 19.1.1

From: "Sanjay Sinha \(sanjsinh\)" <[email-masked]>
Date: Tue, 7 Nov 2006 13:36:29 -0500

I believe this is a sip-implementors questions.
 
Besides, I do not understand the question. host is only parameter in a
sip url, if there are other parameters needed they can be added. For
example if a sip Invite terminates on a pstn gateway, a user portion,
which identifies the pstn user, will be required

________________________________

	From: Matthew Gardiner [mailto:[email-masked]] 
	Sent: Tuesday, November 07, 2006 8:35 AM
	To: [email-masked]
	Subject: [Sip] RFC 3261 Ambiguous SIP URI table in 19.1.1

	Hi, 

	I am attempting to tighten up our SIP stack's behaviour
regarding which URI parameters/fields to display/hide in header fields.
This quest led me to a table known as "Table 1" in section 19.1.1(?) of
RFC 3261. This table seems to present whether or not fields such as port
and transport are optional or mandatory in headers, such as the
"Contact" header. My understanding of this table leads me to believe
that the only mandatory field for all header categories is the host
address - that's why an 'm' character only appears in the "host" row.

	So, apparently, all of the other fields are either optional or
not allowed. Surely this constraint only applies when those fields have
a their default value? What happens if a field assumes a non-default
value, surely then the presentation of this value becomes mandatory in
some header field somewhere?

	Could someone clarify how, if at all, this table is to be
interpreted regarding non-default values for URI parameters/fields?

	thanks 
	Matt   

_______________________________________________
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: "Matthew Gardiner" <[email-masked]>
Date: Wed, 8 Nov 2006 08:03:03 -0000

This is not a sip-implementors question. It concerns the accuracy of "Table 1" on Section 19.1.11/12 of RFC 3261. Putting generalizations aside, lets look at the intersection between "port" and "dialog Contact/R-Route". The table says "o" for this case.
 
Does this imply that presentation of the port assignment is optional if the port number happens to be a non-default value for the port, e.g. 5067? I doubt it. I think if the port is NOT EQUAL 5060 (5061 tls) then the table's value at this intersection should be "m".
 
It's my assumption that this table only describes the optionality for these fields, such as port, when they possess their default value. I do not think a specification should be encouraging a reader to make assumptions.
 
It seems to me that this table is not applicable for non-default values of the fields in the left-most column.
 
thanks
Matt

-----Original Message-----
From: Sanjay Sinha (sanjsinh) [mailto:[email-masked]]
Sent: 07 November 2006 18:36
To: Matthew Gardiner; [email-masked]
Subject: RE: [Sip] RFC 3261 Ambiguous SIP URI table in 19.1.1

Besides, I do not understand the question. host is only parameter in a sip url, if there are other parameters needed they can be added. For example if a sip Invite terminates on a pstn gateway, a user portion, which identifies the pstn user, will be required

  _____  

Hi, 

I am attempting to tighten up our SIP stack's behaviour regarding which URI parameters/fields to display/hide in header fields. This quest led me to a table known as "Table 1" in section 19.1.1(?) of RFC 3261. This table seems to present whether or not fields such as port and transport are optional or mandatory in headers, such as the "Contact" header. My understanding of this table leads me to believe that the only mandatory field for all header categories is the host address - that's why an 'm' character only appears in the "host" row.

So, apparently, all of the other fields are either optional or not allowed. Surely this constraint only applies when those fields have a their default value? What happens if a field assumes a non-default value, surely then the presentation of this value becomes mandatory in some header field somewhere?

Could someone clarify how, if at all, this table is to be interpreted regarding non-default values for URI parameters/fields?

thanks 
Matt

---

From: "Michael Procter" <[email-masked]>
Date: Wed, 8 Nov 2006 02:41:44 -0800

> This is not a sip-implementors question. It concerns the accuracy of
> "Table 1" on Section 19.1.11/12 of RFC 3261. Putting generalizations 
> aside, lets look at the intersection between "port" and "dialog 
> Contact/R-Route". The table says "o" for this case.
 
> Does this imply that presentation of the port assignment is optional if 
> the port number happens to be a non-default value for the port, e.g. 5067?
> I doubt it. I think if the port is NOT EQUAL 5060 (5061 tls) then the 
> table's value at this intersection should be "m".

No.  This table only describes what forms are syntactically valid.  It is useful when writing a parser, or to answer questions of the form 'Can I write this in that location?'.

Your question is whether or not omitting a non-default port value is semantically valid or not, to which the answer is 'No'.

Regards,

Michael

---

From: "Matthew Gardiner" <[email-masked]>
Date: Wed, 8 Nov 2006 15:28:37 -0000

> No.  This table only describes what forms are syntactically valid.  It is useful when writing a parser, 
> or to answer questions of the form 'Can I write this in that location?'.

Fair enough

> Your question is whether or not omitting a non-default port value is semantically valid or not, to which the answer is 'No'.

Yes, that's right, I'm glad that someone understood my question.

It's a shame, IMO, that RFC 3261 does not clarify this a little better. For example, suppose I have received a Record-Route "sip:192.168.2.1:5067", is it necessary to include the port specification in the Request-URI and/or the Route-set? The answer to that question is not inferred by the mentioned table and surrounding text.

thanks
Matt 

-----Original Message-----
From: Michael Procter [mailto:[email-masked]]
Sent: 08 November 2006 10:42
To: Matthew Gardiner; Sanjay Sinha (sanjsinh); [email-masked]
Subject: RE: [Sip] RFC 3261 Ambiguous SIP URI table in 19.1.1

Regards,

Michael

---

From: "Matthew Gardiner" <[email-masked]>
Date: Wed, 8 Nov 2006 16:05:12 -0000

> As a general rule, URIs should not be 'adjusted' as you work with them.

Maybe not, but their presentation to the outside world, should be in certain contexts. That was my reason for visiting this table in the first place. Case in point, the port and transport parameters being disallowed in the To: and From: headers as mandated by this table. (Still not sure why these parameters are disallowed here?).

I visited this table in attempt to clarify some code in our stack, but the result was further confusion!

thanks
Matt

---

Date: Wed, 8 Nov 2006 07:50:24 -0800

X-MS-TNEF-CorreFrom [email-masked] Wed Nov 08 11:08:34 2006
Content-class: urn:content-classes:message
Subject: RE: [Sip] RFC 3261 Ambiguous SIP URI table in 19.1.1
Date: Wed, 8 Nov 2006 16:05:12 -0000
From: "Matthew Gardiner" <[email-masked]>
To: "Michael Procter" <[email-masked]>,
	"Sanjay Sinha (sanjsinh)" <[email-masked]>, <[email-masked]>

thanks
Matt

---

From: "Michael Procter" <[email-masked]>
Date: Wed, 8 Nov 2006 07:50:24 -0800

Matthew Gardiner wrote:
> 
> > No.  This table only describes what forms are syntactically valid.
It
> is useful when writing a parser,
> > Your question is whether or not omitting a non-default port value is
> semantically valid or not, to which the answer is 'No'.
> 

;-)

> It's a shame, IMO, that RFC 3261 does not clarify this a little
better.
> For example, suppose I have received a Record-Route
> "sip:192.168.2.1:5067", is it necessary to include the port
specification
> in the Request-URI and/or the Route-set? The answer to that question
is
> not inferred by the mentioned table and surrounding text.

RFC 3261 does clarify this, but not in that section.  You might find it
useful to look at Sec 19.1.4, and note that "sip:192.168.2.1:5067" is
not 
equivalent to "sip:192.168.2.1".  If the URIs are not equivalent, then
in some sense they refer to different entities.  

As a general rule, URIs should not be 'adjusted' as you work with them.
If
you make a change that would cause the tests in sec 19.1.4 to deem the
new
URI not equivalent to the old URI, then you can expect interoperability
problems sooner or later.

Regards,

Michael

lator: 
To: "Matthew Gardiner" <[email-masked]>,
	"Sanjay Sinha \(sanjsinh\)" <[email-masked]>, <[email-masked]>
Cc: 

Matthew Gardiner wrote:
> 
> > No.  This table only describes what forms are syntactically valid.
It
> is useful when writing a parser,
> > Your question is whether or not omitting a non-default port value is
> semantically valid or not, to which the answer is 'No'.
> 

;-)

> It's a shame, IMO, that RFC 3261 does not clarify this a little
better.
> For example, suppose I have received a Record-Route
> "sip:192.168.2.1:5067", is it necessary to include the port
specification
> in the Request-URI and/or the Route-set? The answer to that question
is
> not inferred by the mentioned table and surrounding text.

RFC 3261 does clarify this, but not in that section.  You might find it
useful to look at Sec 19.1.4, and note that "sip:192.168.2.1:5067" is
not 
equivalent to "sip:192.168.2.1".  If the URIs are not equivalent, then
in some sense they refer to different entities.  

As a general rule, URIs should not be 'adjusted' as you work with them.
If
you make a change that would cause the tests in sec 19.1.4 to deem the
new
URI not equivalent to the old URI, then you can expect interoperability
problems sooner or later.

Regards,

Michael