Subject: [martini] New GIN Draft

From: Adam Roach <[email-masked]>
Date: Tue, 18 May 2010 16:38:07 -0500

Based on the conversation we had about "user=phone" at the most recent 
interim, I have put some strawman text into the GIN document. Please 
look at the revamped section 5 -- section 5.3, in particular -- in the 
new version, and let me know whether you have any concerns about this 
proposed resolution.

New version:
   http://www.ietf.org/id/draft-ietf-martini-gin-02.txt

Diffs:
   http://tools.ietf.org/rfcdiff?url2=draft-ietf-martini-gin-02.txt

This version also removes ";user=phone" from all the examples, as was 
proposed during the phone call.

The issue around registration remains open, and I'll be sending an email 
to the list shortly to discuss it.

/a

---

From: Cullen Jennings <[email-masked]>
Date: Tue, 18 May 2010 19:26:18 -0600

On May 18, 2010, at 3:38 PM, Adam Roach wrote:

> Based on the conversation we had about "user=phone" at the most recent interim, I have put some strawman text into the GIN document. Please look at the revamped section 5 -- section 5.3, in particular -- in the new version, and let me know whether you have any concerns about this proposed resolution.

Trying to fix the looser=phone problem by adding some auto magic is doomed to failure. I rather just have clarify what needs to be done (in some document other than GIN, perhaps the SIP Forum doc) and just fix stuff to work or at least not fail in a bad way. 

Cullen Jennings
For corporate legal information go to:
http://www.cisco.com/web/about/doing_business/legal/cri/index.html

---

From: "Elwell, John" <[email-masked]>
Date: Wed, 19 May 2010 09:45:38 +0200

Although this might work, I view the autouser addition as probably going beyond what is necessary.

As I think I mentioned on the call, I tend to view the user= parameter as an extension of the user part. So it should not be included in the Contact URI of the REGISTER request, but should be included in the Request-URI of inbound requests if the user-part requires it (e.g., user=phone if the user part is a telephone-subscriber string) - this would be a matter for provisioning. I don't think this requires the autouser parameter.

By the way, there seems to be some duplication of normative statements in -02:
"A registrar that receives a URI with both a "bnc" parameter and a
   user portion MAY discard the user portion and process the the request
   as if it were not present.  Alternately, the registrar MAY return a
   400 (Bad Request) error in response."
and later:
"A registrar that receives such a
   URI MAY discard the "user" parameter and process the the request as
   if the parameter were not present.  Alternately, it MAY return a 400
   (Bad Request) error in response."

Also both have a repeated "the".

John

> -----Original Message-----
> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Adam Roach
> Sent: 18 May 2010 22:38
> To: [email-masked]
> Subject: [martini] New GIN Draft
> 
> _______________________________________________
> martini mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/martini
>

---

From: Adam Roach <[email-masked]>
Date: Wed, 19 May 2010 09:08:38 -0500

> As I think I mentioned on the call, I tend to view the user= parameter as an extension of the user part. So it should not be included in the Contact URI of the REGISTER request, but should be inclu…

I'm happy to take things that way also, but it's not what I heard people 
supporting on the call.

As I said in my slides, I think this issue is bike-shed painting of the 
worst kind. I really, *really* don't think it matters which of the six 
or seven options we discussed are selected -- they all work -- but we 
*need* to choose one and move forward.

>     (Bad Request) error in response."

They're different statements. The first one talks about the "user 
portion" of a URI:

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

While the second one talks about the "user parameter" of a URI:

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

I can see how that is a bit confusing, but don't know how to make it 
crystal clear that we're talking about different things. I would have 
hoped that the context of the text that comes immediately before those 
statements would have helped people recognize the URI component under 
discussion. Since the existing text wasn't clear enough to avoid your 
confusion, can you propose some text that would make this clearer?

> Also both have a repeated "the".

Good catch. I'll fix that.

/a

---

From: "Elwell, John" <[email-masked]>
Date: Wed, 19 May 2010 16:22:45 +0200

> From: Adam Roach [mailto:[email-masked]] 
> Sent: 19 May 2010 15:09
> To: Elwell, John
> Cc: [email-masked]
> Subject: Re: [martini] New GIN Draft
> 
> > As I think I mentioned on the call, I tend to view the 
> user= parameter as an extension of the user part. So it 
> should not be included in the Contact URI of the REGISTER 
> request, but should be included in the Request-URI of inbound 
> requests if the user-part requires it (e.g., user=phone if 
> the user part is a telephone-subscriber string) - this would 
> be a matter for provisioning. I don't think this requires the 
> autouser parameter.
> 
[JRE] I agree, so I would have preferred the simpler solution (without the autouser parameter), but it that is what others want I can live with it.

>    sip:[email-masked];user=phone
[JRE] Sorry, my careless reading. No need to change.

John

---

From: "Spencer Dawkins" <[email-masked]>
Date: Wed, 19 May 2010 09:42:25 -0500

Speaking as co-chair (first time this week - I feel like I've been slacking 
off)...

> [JRE] Sorry, my careless reading. No need to change.

I'm getting what Adam is saying, but I'm thinking that if this fuzzballed 
John Elwell, that will be a problem when GIN goes for wider review. What 
helped ME (and, perhaps, John) was the two examples that Adam provided. 
Ordinarily, I wouldn't suggest including them, but I'm thinking that we'll 
have this conversations multiple times with various ADs, review teams, and 
other members of the RAI community who are busy - so would it be wrong if 
Adam added the examples to the text, just so everyone has that clue on first 
reading?

Thanks,

Spencer, as co-chair

---

From: Adam Roach <[email-masked]>
Date: Wed, 19 May 2010 10:42:13 -0500

On 5/19/10 9:42 AM, Spencer Dawkins wrote:
> ...
> I'm getting what Adam is saying, but I'm thinking that if this 
> fuzzballed John Elwell, that will be a problem when GIN goes for wider 
> review. What helped ME (and, perhaps, John) was the two examples that 
> Adam provided. Ordinarily, I wouldn't suggest including them, but I'm 
> thinking that we'll have this conversations multiple times with 
> various ADs, review teams, and other members of the RAI community who 
> are busy - so would it be wrong if Adam added the examples to the 
> text, just so everyone has that clue on first reading?

I've added it to my draft for the sake of clarity. It will appear in the 
-03 version.

/a

---

From: "Spencer Dawkins" <[email-masked]>
Date: Wed, 19 May 2010 11:41:32 -0500

Adam, 

Thanks!

> I've added it to my draft for the sake of clarity. It will appear in the 

Spencer

---

From: Hans Erik van Elburg <[email-masked]>
Date: Wed, 26 May 2010 01:18:05 +0200

On Wed, May 19, 2010 at 4:08 PM, Adam Roach <[email-masked]> wrote:
>> As I think I mentioned on the call, I tend to view the user= parameter as
>> an extension of the user part. So it should not be included in the Contact
>> URI of the REGISTER request, but should be included in the Request-URI of
>> inbound requests if the user-part requires it (e.g., user=phone if the user
>> part is a telephone-subscriber string) - this would be a matter for
>> provisioning. I don't think this requires the autouser parameter.
>
> worst kind. I really, *really* don't think it matters which of the six or
> seven options we discussed are selected -- they all work -- but we *need* to
> choose one and move forward.

A simpler option not requiring automagic behaviour on the SSP's side,
would be to copy the user=phone to the contact when received by the
SSP. During the discussion this is what I understood that the new
parameter should control. i.e. true=copy user parameter if present,
false=do not copy user parameter.

/Hans Erik