Subject: [martini] #60: Optionality of Service-Route etc.

From: "martini issue tracker" <[email-masked]>
Date: Thu, 22 Jul 2010 16:26:19 -0000

#60: Optionality of Service-Route etc.
------------------------------------------------+---------------------------
 Reporter:  john.elwell@…                       |       Owner:     
     Type:  defect                              |      Status:  new
 Priority:  minor                               |   Milestone:     
Component:  gin                                 |     Version:     
 Severity:  In WG Last Call                     |    Keywords:     
------------------------------------------------+---------------------------
 In section 7:
 "The following sections describe the means by which this mechanism
    interacts with relevant REGISTER-related extensions currently defined
    by the IETF."

 Perhaps there should be clarification as to whether or not this document
 requires support of any of these mechanisms. For example, I don't think
 there is any intention to mandate support of the Service-Route header
 field - section 7.4 just gives information on the impact if the mechanism
 is used. Similarly Path is optional, beyond the specific bits mandated
 elsewhere. I don't think there is any intention to mandate support for the
 registration event package (7.2) or SIP-Outbound (7.3). Concerning support
 for public and temporary GRUUs (7.1), I think this is the subject of a
 separate discussion. Depending on what is decided for each of these,
 either a blanket statement in 7 or individual statements in 7.1/2/3/4
 should be added.

-- 
Ticket URL: <http://trac.tools.ietf.org/wg/martini/trac/ticket/60>
martini <http://tools.ietf.org/martini/>

---

From: Brian Lindsay <[email-masked]>
Date: Fri, 23 Jul 2010 13:26:48 +0000

Hi, 

  Similar to my comment on GRUU earlier in the week, I would like to see these remain optional as far as the draft is concerned. 

 I had interpreted the existing intent of Section 7 as describing how the mechanisms work with gin registration (and extending the mechanisms if need be), but not coupling/requiring that a gin registration implementation also implement these mechanisms. If that intent needs to be strengthened in the text that's fine.

Thanks
   Brian

-------------
Brian Lindsay
Sr. Architect, System Architecture
GENBAND
Office: +1.613.763.3459      
www.genband.com

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of martini issue tracker
Sent: Thursday, July 22, 2010 12:26 PM
To: [email-masked]
Cc: [email-masked]
Subject: [martini] #60: Optionality of Service-Route etc.

#60: Optionality of Service-Route etc.
------------------------------------------------+-----------------------
------------------------------------------------+----
 Reporter:  john.elwell@...                       |       Owner:     
     Type:  defect                              |      Status:  new
 Priority:  minor                               |   Milestone:     
Component:  gin                                 |     Version:     
 Severity:  In WG Last Call                     |    Keywords:     
------------------------------------------------+-----------------------
------------------------------------------------+----
 In section 7:
 "The following sections describe the means by which this mechanism
    interacts with relevant REGISTER-related extensions currently defined
    by the IETF."

 Perhaps there should be clarification as to whether or not this document  requires support of any of these mechanisms. For example, I don't think  there is any intention to mandate support of the Service-Route header  field - section 7.4 just gives information on the impact if the mechanism  is used. Similarly Path is optional, beyond the specific bits mandated  elsewhere. I don't think there is any intention to mandate support for the  registration event package (7.2) or SIP-Outbound (7.3). Concerning support  for public and temporary GRUUs (7.1), I think this is the subject of a  separate discussion. Depending on what is decided for each of these,  either a blanket statement in 7 or individual statements in 7.1/2/3/4  should be added.

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

---

From: "Elwell, John" <[email-masked]>
Date: Fri, 23 Jul 2010 16:00:46 +0200

Right, so in that case I would propose the addition of the following sentence to the end of the first paragraph of section 7:
"With the exception of requirements in section 5.1 relating to the Path header field (RFC 3327), this document does not mandate support for any of the mechanisms discussed in this section. Any requirements in the sub-sections below apply only if the mechanism concerned is supported."

John 

> From: Brian Lindsay [mailto:[email-masked]] 
> Sent: 23 July 2010 14:27
> To: Elwell, John; [email-masked]
> Subject: RE: [martini] #60: Optionality of Service-Route etc.
> 
> Hi, 
> 
>   Similar to my comment on GRUU earlier in the week, I would 
> like to see these remain optional as far as the draft is concerned. 
> 
>  I had interpreted the existing intent of Section 7 as 
> describing how the mechanisms work with gin registration (and 
> extending the mechanisms if need be), but not 
> coupling/requiring that a gin registration implementation 
> also implement these mechanisms. If that intent needs to be 
> strengthened in the text that's fine.
> 
> 
> Thanks
>    Brian
> 
> -------------
> Brian Lindsay
> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of martini issue tracker
>  Perhaps there should be clarification as to whether or not 
> this document  requires support of any of these mechanisms. 
> For example, I don't think  there is any intention to mandate 
> support of the Service-Route header  field - section 7.4 just 
> gives information on the impact if the mechanism  is used. 
> Similarly Path is optional, beyond the specific bits mandated 
>  elsewhere. I don't think there is any intention to mandate 
> support for the  registration event package (7.2) or 
> SIP-Outbound (7.3). Concerning support  for public and 
> temporary GRUUs (7.1), I think this is the subject of a  
> separate discussion. Depending on what is decided for each of 
> these,  either a blanket statement in 7 or individual 
> statements in 7.1/2/3/4  should be added.
> 
> --

---

From: Brian Lindsay <[email-masked]>
Date: Fri, 23 Jul 2010 14:57:08 +0000

Hi John,

   That looks pretty good.

   Thanks
     Brian

-----Original Message-----
From: Elwell, John [mailto:[email-masked]] 
Sent: Friday, July 23, 2010 10:01 AM
To: Brian Lindsay; [email-masked]
Subject: RE: [martini] #60: Optionality of Service-Route etc.

John 

>   Similar to my comment on GRUU earlier in the week, I would like to 
> see these remain optional as far as the draft is concerned.
> 
>  I had interpreted the existing intent of Section 7 as describing how 
> the mechanisms work with gin registration (and extending the 
> mechanisms if need be), but not coupling/requiring that a gin 
> registration implementation also implement these mechanisms. If that 
> intent needs to be strengthened in the text that's fine.
> 
> 
> Thanks
>    Brian
> 
> -------------
> Brian Lindsay

---

From: Hadriel Kaplan <[email-masked]>
Date: Fri, 23 Jul 2010 11:16:31 -0400

Sounds good.

(though as an aside, unlike gruu and outbound, Service-Route support is not indicated in the REGISTER request and thus not really useful if it's not mandatory and tied to gin, but that's a more generic problem anyway)

-hadriel

> From: [email-masked] [mailto:[email-masked]] On Behalf
> Of Elwell, John
> Subject: Re: [martini] #60: Optionality of Service-Route etc.
> 
> Right, so in that case I would propose the addition of the following
> sentence to the end of the first paragraph of section 7:
> "With the exception of requirements in section 5.1 relating to the Path
> header field (RFC 3327), this document does not mandate support for any of
> the mechanisms discussed in this section. Any requirements in the sub-
> sections below apply only if the mechanism concerned is supported."
> 
> John
>