Subject: [martini] I-D Action:draft-ietf-martini-gin-04.txt

From: [email-masked]
Date: Thu, 17 Jun 2010 16:00:01 -0700 (PDT)

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Multiple AoR reachabiliTy InformatioN Indication Working Group of the IETF.

	Title           : Registration for Multiple Phone Numbers in the Session Initiation Protocol (SIP)
	Author(s)       : A. Roach
	Filename        : draft-ietf-martini-gin-04.txt
	Pages           : 27
	Date            : 2010-06-17

This document defines a mechanism by which a SIP server acting as a
traditional Private Branch Exchange (SIP-PBX) can register with a SIP
Service Provider (SSP) to receive phone calls for UAs designated by
phone numbers.  In order to function properly, this mechanism relies
on the fact that the phone numbers are fully qualified and globally
unique.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-martini-gin-04.txt

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

---

From: "Elwell, John" <[email-masked]>
Date: Fri, 18 Jun 2010 12:28:21 +0200

Changes look good in general. I noticed the following in 5.3:

"An SSP registrar that
   receives such a URI MAY discard the "user" parameter and process the
   request as if the parameter were not present.  Alternately, it MAY
   return a 400 (Bad Request) error in response.

      Note that this requirement is talking about the user parameter of
      a URI:"

1. Instead of two "MAY"s, would it be better to have a "MUST do either ... or ..."? The present formulation allows other behaviours - I don't know whether we intend that or not.

2. In the note, what exactly does "this requirement" apply to? Presumably the "MUST" that came earlier, although if we do as I suggest in 1, we would end up with a second MUST, so we might need to say "these requirements". Depending on the resolution of 1, I think the note could do with some clarification.

John

> -----Original Message-----
> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of 
> [email-masked]
> Sent: 18 June 2010 00:00
> To: [email-masked]
> Cc: [email-masked]
> Subject: [martini] I-D Action:draft-ietf-martini-gin-04.txt
> 
> This draft is a work item of the Multiple AoR reachabiliTy 
> InformatioN Indication Working Group of the IETF.
> 
> 
> 	Title           : Registration for Multiple Phone 
> Numbers in the Session Initiation Protocol (SIP)
> 	Author(s)       : A. Roach

---

From: Adam Roach <[email-masked]>
Date: Fri, 18 Jun 2010 17:49:16 -0500

> 1. Instead of two "MAY"s, would it be better to have a "MUST do either ... or ..."? The present formulation allows other behaviours - I don't know whether we intend that or not.

I kind of did, but really only for one set of circumstances -- I didn't 
want to disallow other valid error codes (e.g., 5xx
codes) in this circumstance. But I can make that explicit:

    An SSP registrar that
    receives a "bnc" URI with a "user" parameter MUST either discard the
    "user" parameter and process the request as if the parameter were not
    present or return a 400 (Bad Request) error in response (unless some
    other error code is more appropriate).

> 2. In the note, what exactly does "this requirement" apply to? Presumably the "MUST" that came earlier, although if we do as I suggest in 1, we would end up with a second MUST, so we might need to…

Yes, the note was written prior to some expansion of that paragraph. 
I've revised it to read:

       Note that the preceding paragraph is talking about the "user"
       parameter of a URI:

       sip:[email-masked];user=phone
                                    ^^^^^^^^^^

There was some similar text in 5.2 (regarding user portions) that I'm 
updating in a congruent fashion.

/a

---

From: "Elwell, John" <[email-masked]>
Date: Mon, 21 Jun 2010 08:24:36 +0200

Thanks, that's fine.

John 

> From: Adam Roach [mailto:[email-masked]] 
> Sent: 18 June 2010 23:49
> To: Elwell, John
> Cc: [email-masked]
> Subject: Re: [martini] I-D Action:draft-ietf-martini-gin-04.txt
> 
> > 1. Instead of two "MAY"s, would it be better to have a 
> "MUST do either ... or ..."? The present formulation allows 
> other behaviours - I don't know whether we intend that or not.
> >    
> 
> > 2. In the note, what exactly does "this requirement" apply 
> to? Presumably the "MUST" that came earlier, although if we 
> do as I suggest in 1, we would end up with a second MUST, so 
> we might need to say "these requirements". Depending on the 
> resolution of 1, I think the note could do with some clarification.
> >    
>

---

From: Christer Holmberg <[email-masked]>
Date: Mon, 21 Jun 2010 14:08:11 +0200

Hi,

Q1.	As far as I remember, RFC 3261 defines an "ip" default value for the user parameter, so I guess some parsers could include it by default.

Q2.	I pretty much know what you mean by "bnc" URI, but if you are going to use that in the text I think you need some definition of it.

Q3.	400 Bad Request is sent because of "malformed syntax". Is that really the case here? I think we are talking about a service error, or a unknown destination error, or something similar.

Q4.	I am a little concerned with the rejecting the message in the first place. If the SSP does this, I believe it would reject at least more or less every call coming from PSTN, because every MGC I am aware of does insert user=phone in the Request-URI.

Q5.	One could claim (and I think Cullen did) that +123 is the same with or without user=phone. But, if the userpart contains some tel-uri parameter the meaning is not the same. For example:

+1234;param=blah with user=phone is *not* the same as +1234;param=blah without user=phone.

I know that GIN is restricted to E.164 numbers, but is there a restriction regarding the usage of tel-uri parameters?

Regards,

Christer

> [mailto:[email-masked]] On Behalf Of Elwell, John
> Sent: 21. kesäkuuta 2010 9:25
> To: Adam Roach
> Cc: [email-masked]
> > "MUST do either ... or ..."? The present formulation allows other 
> > behaviours - I don't know whether we intend that or not.
> > >    
> > 
> >     receives a "bnc" URI with a "user" parameter MUST 
> either discard 
> > the
> >     "user" parameter and process the request as if the 
> parameter were 
> > not
> > to? Presumably the "MUST" that came earlier, although if we do as I 
> > suggest in 1, we would end up with a second MUST, so we 
> might need to 
> > say "these requirements". Depending on the resolution of 1, I think 
> > the note could do with some clarification.
> > >    
> > 
> _______________________________________________
> martini mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/martini
>

---

From: Paul Kyzivat <[email-masked]>
Date: Mon, 21 Jun 2010 09:37:55 -0400

> +1234;param=blah with user=phone is *not* the same as +1234;param=blah without user=phone.

Why?

---

From: Adam Roach <[email-masked]>
Date: Mon, 21 Jun 2010 10:14:26 -0500

> Q1.	As far as I remember, RFC 3261 defines an "ip" default value for the user parameter, so I guess some parsers could include it by default.

And, if they're going to be used in a SIP-PBX that uses GIN for 
registration, they need to be changed. (To reiterate the arguments that 
started this thread in the first place: it would be questionable to 
include a "user" parameter on a URI that has no user portion. And these 
won't. So I doubt your theoretical case exists.)

> Q2.	I pretty much know what you mean by "bnc" URI, but if you are going to use that in the text I think you need some definition of it.

I'll add a definition.

> Q3.	400 Bad Request is sent because of "malformed syntax". Is that really the case here? I think we are talking about a service error, or a unknown destination error, or something similar.

Pretty much, yes. Again, the objection that started this whole 
bike-shed-painting exercise was an assertion that inclusion of a "user" 
parameter on a SIP URI with no user portion was syntactically invalid. 
So I think "400" is the right way to go.

> Q4.	I am a little concerned with the rejecting the message in the first place. If the SSP does this, I believe it would reject at least more or less every call coming from PSTN, because every MGC I…

What?

No.

No, no, no, no, no, no, no, no, no.

It's *not* getting requests with "bnc" on them from anywhere but SIP-PBX 
registrations. This doesn't even slightly apply to the case you're 
describing.

> +1234;param=blah with user=phone is *not* the same as +1234;param=blah without user=phone.

It could be. That's a site-local decision to make. "user=phone" is just 
as ambiguous in both cases.

>>>>      receives such a URI MAY discard the "user" parameter
>>>>          
>>> and process the
>>>        
>>>>      request as if the parameter were not present.
>>>>          
>>> Alternately, it MAY
>>>        
>>>>         Note that this requirement is talking about the user
>>>>          
>>> parameter of
>>>        
>>>>         a URI:"
>>>>
>>> Yes, the note was written prior to some expansion of that
>>>        
>> paragraph.
>>      
>>> I've revised it to read:
>>>
>>> There was some similar text in 5.2 (regarding user
>>>        
>> portions) that I'm
>>

---

From: Christer Holmberg <[email-masked]>
Date: Mon, 21 Jun 2010 23:28:14 +0200

Hi,

>won't. So I doubt your theoretical case exists.)

I am talking about the SSP procedure. Is there a spelling error in section 5.3?

>So I think "400" is the right way to go.

I agree that a SIP URI with no user portion, and user=phone, is invalid. 

But, I don't think user=ip is invalid. Can you show some text/ABNF which shows that?

>registrations. This doesn't even slightly apply to the case you're

Again, I am not talking about the SIP-PBX, but the SSP, which can get the request from wherever.

>It could be. That's a site-local decision to make. "user=phone" is just as ambiguous in both cases.

user=phone means that the userpart shall be parsed as a tel URL. Of course a site COULD decide to do that also in other cases.

Regards,

Christer

---

From: Adam Roach <[email-masked]>
Date: Mon, 21 Jun 2010 16:47:31 -0500

Christer:

I think you've gotten really far off into the weeds here. Let's look at 
section 5.3 closely. The first paragraph talks gives you the proper scope:

    [T]o avoid any ambiguity in handling at the SIP-PBX, the following
    normative behavior is imposed on its interactions with the SSP.

So, what we're talking about here is the registration process between 
the SIP-PBX and the SSP.

Registration.

Only registration.

Nothing but registration.

Just registration.

Which is only coming from the PBX.

Now, let's look at the the next sentence:

     When a SIP-PBX registers with an SSP using a "bnc" contact, that 
contact MUST NOT include a "user" parameter.

That's a restriction on the PBX. During registration, the PBX is not 
allowed to send a "user" parameter on a Contact URI that also has a 
"bnc" parameter. Pretty straightforward stuff, really.

    An SSP registrar that receives such a URI...

(that is, a URI with both "bnc" and "user" parameters)

    ... MUST either discard the "user" parameter and process the request 
as if the
    parameter were not present or return a 400 (Bad Request) error in 
response.

Now, we're still in a sentence talking about getting both a "bnc" 
parameter (WHICH CAN ONLY HAPPEN IN A REGISTER MESSAGE FROM THE SIP-PBX) 
and a "user" parameter. So this restriction can only ever apply to a 
REGISTER message that an SSP gets from a PBX.

Does that clear things up for you?

/a

On 6/21/10 4:28 PM, Christer Holmberg wrote:
> Hi,
>
>>> Q1. As far as I remember, RFC 3261 defines an "ip" default value for 
>>> the user parameter, so I guess some parsers could include it by default.
>>
>>
>>> Q3. 400 Bad Request is sent because of "malformed syntax". Is that 
>>> really the case here? I think we are talking about a service error, 
>>> or a unknown destination error, or something similar.
>>
>>
>>> Q4. I am a little concerned with the rejecting the message in the 
>>> first place. If the SSP does this, I believe it would reject at 
>>> least more or less every call coming from PSTN, because every MGC I 
>>> am aware of does insert user=phone in the Request-URI.
>>
>>
>> What?
>>
>> No.
>>
>>> Q5. One could claim (and I think Cullen did) that +123 is the same 
>>> with or without user=phone. But, if the userpart contains some 
>>> tel-uri parameter the meaning is not the same. For example:
>>
> user=phone means that the userpart shall be parsed as a tel URL. Of 
> course a site COULD decide to do that also in other cases.
>
> Regards,
>
> Christer
>
>
>

---

From: Christer Holmberg <[email-masked]>
Date: Tue, 22 Jun 2010 07:30:41 +0200

Hi Adam,

Ok, if this only applies to the registration it clear things up.

To make it a little more clear, maybe you could talk say "that receives such contact", instead of "SIP URI".

"An SSP registrar that receives a REGISTER request with such a contact MAY discard the "user" parameter and process the request as if the parameter were not present."

Regards,

Christer

________________________________

	From: Adam Roach [mailto:[email-masked]] 
	Sent: 22. kesäkuuta 2010 0:48
	To: Christer Holmberg
	Cc: Elwell, John; [email-masked]
	Subject: Re: [martini] I-D Action:draft-ietf-martini-gin-04.txt

	Christer:
	
	I think you've gotten really far off into the weeds here. Let's look at section 5.3 closely. The first paragraph talks gives you the proper scope:

	So, what we're talking about here is the registration process between the SIP-PBX and the SSP. 
	
	Registration.
	
	Only registration.

	Just registration.

	
	    When a SIP-PBX registers with an SSP using a "bnc" contact, that contact MUST NOT include a "user" parameter.
	
	That's a restriction on the PBX. During registration, the PBX is not allowed to send a "user" parameter on a Contact URI that also has a "bnc" parameter. Pretty straightforward stuff, really.

	
	   ... MUST either discard the "user" parameter and process the request as if the
	   parameter were not present or return a 400 (Bad Request) error in response.
	
	Now, we're still in a sentence talking about getting both a "bnc" parameter (WHICH CAN ONLY HAPPEN IN A REGISTER MESSAGE FROM THE SIP-PBX) and a "user" parameter. So this restriction can only ever apply to a REGISTER message that an SSP gets from a PBX.

	/a

		Hi,

		

		

			What?
			
			No.

		

			

		Regards,
		
		Christer

				-----Original Message-----
				From: [email-masked]
				[mailto:[email-masked]] On Behalf Of Elwell, John
				Sent: 21. kesäkuuta 2010 9:25
				To: Adam Roach
				Cc: [email-masked]
				Subject: Re: [martini] I-D Action:draft-ietf-martini-gin-04.txt
				
				Thanks, that's fine.
				
				John

					-----Original Message-----
					From: Adam Roach [mailto:[email-masked]]
					Sent: 18 June 2010 23:49
					To: Elwell, John
					Cc: [email-masked]
					Subject: Re: [martini] I-D Action:draft-ietf-martini-gin-04.txt

					
					"An SSP registrar that

					and process the

					Alternately, it MAY

					parameter of

					a URI:"

					I kind of did, but really only for one set of circumstances
					-- I didn't
					want to disallow other valid error codes (e.g., 5xx
					codes) in this circumstance. But I can make that explicit:
					
					An SSP registrar that

				either discard

					the

				parameter were

					not
					present or return a 400 (Bad Request) error in response (unless
					some
					other error code is more appropriate).

				might need to

				paragraph.

					I've revised it to read:

					

				portions) that I'm

					/a