Subject: [martini] #31: GIN: add text requiring Path

From: "martini issue tracker" <[email-masked]>
Date: Sun, 11 Apr 2010 03:41:21 -0000

#31: GIN: add text requiring Path
------------------------------------+---------------------------------------
 Reporter:  hkaplan@…               |       Owner:            
     Type:  enhancement             |      Status:  new       
 Priority:  major                   |   Milestone:  milestone1
Component:  gin                     |     Version:  1.0       
 Severity:  Active WG Document      |    Keywords:            
------------------------------------+---------------------------------------
 I have heard no objections to requiring RFC 3327 Path in GIN.  I therefore
 ask for section 8 example messages to be updated with the 'path' option-
 tag in the Supported header field, and for something like the following
 text to be added after the third paragraph of Section 5:

 <begin>
 The PBX MUST also support the Path mechanism in [RFC3327], and MUST
 include a 'path' option-tag in the Supported header field of the REGISTER
 request, although it MAY ignore the Path header fields returned in the
 REGISTER response.  This is necessary because Proxies between the PBX and
 the Registrar may need to insert Path header field values in the REGISTER
 request for this document's mechanism to function properly, and per
 [RFC3327] they can only do so if the UAC inserted the option-tag in the
 Supported header field.

 A Registrar compliant with this document MUST support the Path mechanism
 defined in [RFC3327].
 <end>

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

---

From: "DRAGE, Keith (Keith)" <[email-masked]>
Date: Sun, 18 Apr 2010 15:11:12 +0200

Some comments on this proposed text:

1)	It should be clearer what is altered from RFC 3327. As far as I can see, the only change here is that the SHOULD regarding the use of the option tag in Supported in all requests in RFC 3327 is altered to a MUST specifically for the REGISTER request.

2)	Move the text "although it MAY ignore the Path header fields returned in the  REGISTER response" to a separate sentence at the end of the first paragraph. I got confused with the interposition of this in the middle of discussion of option tags. Also the MAY here is exactly the MAY that exists in RFC 3327, so change to "although it MAY (in accorance with RFC 3327) ignore the Path header fields returned in the  REGISTER response"

regards

Keith

> -----Original Message-----
> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of martini issue tracker
> Sent: Sunday, April 11, 2010 4:41 AM
> To: [email-masked]
> Cc: [email-masked]
> Subject: [martini] #31: GIN: add text requiring Path
> 
> ------------------------------------+-------------------------
> ----------
> ------------------------------------+----
> ------------------------------------+-------------------------
> ----------
> ------------------------------------+----
>  I have heard no objections to requiring RFC 3327 Path in 
> GIN.  I therefore  ask for section 8 example messages to be 
> updated with the 'path' option-  tag in the Supported header 
> field, and for something like the following  text to be added 
> after the third paragraph of Section 5:
> 
>  <begin>
>  The PBX MUST also support the Path mechanism in [RFC3327], 
> and MUST  include a 'path' option-tag in the Supported header 
> field of the REGISTER  request, although it MAY ignore the 
> Path header fields returned in the  REGISTER response.  This 
> is necessary because Proxies between the PBX and  the 
> Registrar may need to insert Path header field values in the 
> REGISTER  request for this document's mechanism to function 
> properly, and per  [RFC3327] they can only do so if the UAC 
> inserted the option-tag in the  Supported header field.
> 
>  A Registrar compliant with this document MUST support the 
> Path mechanism  defined in [RFC3327].
>  <end>
> 
> --
> _______________________________________________
> martini mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/martini
>

---

From: "martini issue tracker" <[email-masked]>
Date: Mon, 19 Apr 2010 21:00:07 -0000

#31: GIN: add text requiring Path
------------------------------------+---------------------------------------
 Reporter:  hkaplan@…               |       Owner:  adam@…          
     Type:  enhancement             |      Status:  assigned        
 Priority:  major                   |   Milestone:  milestone1      
Component:  gin                     |     Version:  1.0             
 Severity:  Active WG Document      |    Keywords:                  
------------------------------------+---------------------------------------
Changes (by adam@…):

  * owner:  => adam@…
  * status:  new => assigned

-- 
Ticket URL: <https://wiki.tools.ietf.org/wg/martini/trac/ticket/31#comment:1>
martini <http://tools.ietf.org/martini/>

---

From: "martini issue tracker" <[email-masked]>
Date: Mon, 19 Apr 2010 21:40:10 -0000

#31: GIN: add text requiring Path
------------------------------------+---------------------------------------
 Reporter:  hkaplan@…               |        Owner:  adam@…          
     Type:  enhancement             |       Status:  closed          
 Priority:  major                   |    Milestone:  milestone1      
Component:  gin                     |      Version:  1.0             
 Severity:  Active WG Document      |   Resolution:  fixed           
 Keywords:                          |  
------------------------------------+---------------------------------------
Changes (by adam@…):

  * status:  assigned => closed
  * resolution:  => fixed

Comment:

 Text changed slightly per discussion on list. Addressed in -01 as:

    <t>
       Any PBX implementing the registration mechanism defined in
       this document MUST also support the Path mechanism defined
       by RFC 3327 <xref target="RFC3327"/>, and MUST include a
       'path' option-tag in the Supported header field of the REGISTER
       request (which is a stronger requirement than imposed by the
       Path mechanism itself).  This behavior is necessary because
       proxies between the PBX and the Registrar may need to insert
       Path header field values in the REGISTER request for this
       document's mechanism to function properly, and per RFC 3327
       <xref target="RFC3327"/>, they can only do so if the UAC
       inserted the option-tag in the Supported header field.  In
       accordance with the procedures defined in RFC 3327 <xref
       target="RFC3327"/>, the PBX is allowed to ignore the Path
       header fields returned in the REGISTER response.
     </t>
     <t>
       A Registrar compliant with this document MUST support the
       Path mechanism defined in RFC 3327 <xref target="RFC3327"/>.
     </t>

-- 
Ticket URL: <https://wiki.tools.ietf.org/wg/martini/trac/ticket/31#comment:2>
martini <http://tools.ietf.org/martini/>