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

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