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

[Christer Holmberg <[e-mail]>]

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:[e-mail]] 
	Sent: 22. kesäkuuta 2010 0:48
	To: Christer Holmberg
	Cc: Elwell, John; [e-mail]
	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:
	
	   [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.
				



			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.)
			


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

				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.
			


		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?
		
		
		

				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.
			
			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.
			


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

				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.
			
			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
		
		
		
		

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

					-----Original Message-----
					From: Adam Roach [mailto:[e-mail]]
					Sent: 18 June 2010 23:49
					To: Elwell, John
					Cc: [e-mail]
					Subject: Re: [martini] I-D Action:draft-ietf-martini-gin-04.txt
					
					On 6/18/10 5:28 AM, Elwell, John wrote:
					
					

					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.
					
					



					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
				
				

					say "these requirements". Depending on the resolution of 1, I think
					the note could do with some clarification.
					
					



					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:[e-mail];user=phone
					^^^^^^^^^^
					
					There was some similar text in 5.2 (regarding user
					
					

				portions) that I'm
				
				

					updating in a congruent fashion.
					
					/a
					
					
					

				_______________________________________________
				martini mailing list
				[e-mail]
				https://www.ietf.org/mailman/listinfo/martini
				

			>