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

[Adam Roach <[e-mail]>]

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