Subject: RE: [Sip] Re: WGLC for draft-willis-sip-path-05

From: [email-masked]
Date: Tue, 7 May 2002 10:15:39 +0300

Hi Sriram !
 
Will be fixed in the next version.
Thanks for pointing this out.
 
cheers,
 Bernie

-----Original Message-----
From: ext Sriram Parameswar [mailto:[email-masked]]
Sent: 06 May, 2002 21:52
To: 'Miguel A. Garcia'; Dean Willis
Cc: [email-masked]; [email-masked]; Honeisen Bernhard (NET/Helsinki)
Subject: RE: [Sip] Re: WGLC for draft-willis-sip-path-05

Dean, Bernie, 

One more recommendation: 

** Since the draft adds an option tag "path". I would highly recommend that put "Supported:path,...." in all REGISTER's shown in the draft.

Thanks, 

Sriram 
__________________________________________ 
Sriram Parameswar              Phone: 972-685-8540 
Interactive Multimedia Server (IMS) Fax: 972-684-3986 
Nortel Networks, Richardson USA  Email: [email-masked] 

-----Original Message----- 
From: Miguel A. Garcia [ mailto:[email-masked]] 
Sent: Monday, May 06, 2002 1:36 AM 
To: Dean Willis 
Cc: [email-masked]; [email-masked]; 
[email-masked] 
Subject: [Sip] Re: WGLC for draft-willis-sip-path-05 

Dean, Bernie: 

Some comments to the Path header, mostly NITS. 

1) Regarding the tag option "Path" for the Supported header, as far as 
   I have seen before, most of the other option tags are defined in 
   lowercase. I would suggest to follow the same approach for consistency, 
   that is, define "path". 

2) The syntax defined at the end of section 3 does not allow the Path 
   header to be part of the request, only to the response. I suspect 
   this is an error. Suggestion: 

         Header field          where   proxy ACK BYE CAN INV OPT REG PRA 
         _______________________________________________________________ 
         Path                    R       ar   -   -   -   -   -   o   - 
         Path                   2xx       -   -   -   -   -   -   o   - 

3) The last sentence in section 4.1 reads: "The UA should include the 
   option tag 'Path' in any Supported headers". I suspect this inclusion 
   affects all the instances of Supported, including those in an INVITE. 
   Can you confirm this? 

4) Reference 1 (RFC 2543) and to "the binding" (section 4.3) should be 
   replaced by reference [2] (bis-09). 

5) In section 4.7, the Via in the examples do not begin with "z9hG4bK" 
   as required by bis-09. 

Thanks a lot, 

       Miguel 

Dean Willis wrote: 
> 
> I'd like to request Working Group Last Call for draft-willis-sip-path. 
> This will need to close by about 11May. 
> 
> Version -05 draft has been submitted to internet-drafts and shoudl be 
> available. 
> 
> in the meantime use: 
> 
> http://www.softarmor.com/sipwg/drafts/draft-willis-sip-path-05.txt 
> 
> or 
> 
> http://www.softarmor.com/sipwg/drafts/draft-willis-sip-path-05.html 
> 
> -- 
> Dean 

-- 
Miguel-Angel Garcia                     Oy LM Ericsson AB 
                                        Jorvas, Finland 
mailto:[email-masked]     Phone:  +358 9 299 3553 
mailto:[email-masked]        Mobile: +358 40 5140002 

_______________________________________________ 
Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip 
This list is for NEW development of the core SIP Protocol 
Use [email-masked] for questions on current sip 
Use [email-masked] for new developments on the application of sip

---

From: "Drage, Keith (Keith)" <[email-masked]>
Date: Fri, 10 May 2002 19:27:00 +0100

The only issue I can think of would concern any responsibility or not for sorting out the best order of visiting this UA inserted proxy versus any others.

If I follow the current procedures, then any UA inserted URL would be the last proxy visited on any incoming dialog to the UA. This would be after visiting any proxy inserted URLs. If this meets Bob's requirements then fine, but I do not want to see any proxy requirement or registrar requirement for reordering the Path list.

Keith

> From: Dean Willis [mailto:[email-masked]]
> Sent: 07 May 2002 19:07
> To: 'Bob Penfield'; 'Miguel A. Garcia'
> Bob asked:
> > A prior e-mail said that a UA was not allowed include a Path 
> > header. Is there a particular reason we want to prohibit the 
> > UA from contributing to the path? I can't think of a 
> > particular example, but a UA could know that a specific 
> > element needs to be on the inbound path, and that element may 
> > not be in the register path (just like a proxy adding "a Path 
> > element referencing another node" as described in section 4.2).
> 
> That's a reasonable question. It's not consistent with the original
> intent, but on first analysis, I can't think of a real reason 
> that this
> COULDN'T be done. Anybody else out there have an opinion?
> 
> >
Remainder snipped as not relevant to this issue.