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

On 6/21/10 7:08 AM, Christer Holmberg wrote:
> 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 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.

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

>
>
>    
>> -----Original Message-----
>> From: martini-bounces@ietf.org
>> [mailto:martini-bounces@ietf.org] On Behalf Of Elwell, John
>> Sent: 21. kesäkuuta 2010 9:25
>> To: Adam Roach
>> Cc: martini@ietf.org
>> Subject: Re: [martini] I-D Action:draft-ietf-martini-gin-04.txt
>>
>> Thanks, that's fine.
>>
>> John
>>
>>      
>>> -----Original Message-----
>>> From: Adam Roach [mailto:adam@nostrum.com]
>>> Sent: 18 June 2010 23:49
>>> To: Elwell, John
>>> Cc: martini@ietf.org
>>> 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:+12145550100@example.com;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
>> martini@ietf.org
>> https://www.ietf.org/mailman/listinfo/martini
>>      