Subject: [sipcore] I-D Action: draft-ietf-sipcore-proxy-feature-reqs-00.txt

From: [email-masked]
Date: Thu, 07 Jul 2011 09:56:28 -0700

A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Session Initiation Protocol Core Working Group of the IETF.

	Title           : Requirements for indication of features supported by a SIP proxy
	Author(s)       : Christer Holmberg
                          Ivo Sedlacek
	Filename        : draft-ietf-sipcore-proxy-feature-reqs-00.txt
	Pages           : 7
	Date            : 2011-06-19

   The Session Initiation Protocol (SIP) &quot;Caller Preferences&quot; extension
   defined in RFC 3840 provides a mechanism that allows a SIP message to
   convey information relating to the originator&#39;s supported features/
   capabilities.  This document defines requirements for a mechanism
   that would allow SIP proxies to convey information relating to the
   proxy&#39;s supported features/capabilities.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-sipcore-proxy-feature-reqs-00.txt

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

This Internet-Draft can be retrieved at:
ftp://ftp.ietf.org/internet-drafts/draft-ietf-sipcore-proxy-feature-reqs-00.txt

---

From: "Worley, Dale R (Dale)" <[email-masked]>
Date: Thu, 7 Jul 2011 14:49:08 -0400

I see in this draft:

   REQ-4: A SIP proxy MUST NOT, when indicating support of a feature/
   capability, make any assumptions that SIP entities in the signalling
   path that receive the indicator will support, or understand the
   meaning of, the feature/capability.

I think the phrasing of this can be improved.  More importantly, it doesn't
state that the proxy (that is doing the indicating) can do so even if intermediate
elements don't support the proxy-feature mechanism at all.  This might be a
more comprehensive way to express it:

   REQ-4: A SIP proxy MUST be able to indicate support of a
   feature/capability to all other SIP entities in the signaling path
   (that support this mechanism), even if some SIP entities in the
   signaling path (possibly including the UAC and/or UAS) do not
   support, or understand the meaning of, the feature/capability, or
   even this mechanism as a whole.

Dale

---

From: Christer Holmberg <[email-masked]>
Date: Thu, 7 Jul 2011 23:57:33 +0200

Hi Dale,

Your proposed change looks good, but a couple of minor suggestions:

1. I would suggest to remove the "(that support this mechanism)" part.

2. I would suggest to say "to other SIP entities", rather than "to ALL other SIP entities", as we also need to consider the directionality.

Regards,

Christer 

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Worley, Dale R (Dale)
Sent: 7. heinäkuuta 2011 21:49
To: [email-masked]
Subject: Re: [sipcore] I-D Action: draft-ietf-sipcore-proxy-feature-reqs-00.txt

I see in this draft:

I think the phrasing of this can be improved.  More importantly, it doesn't state that the proxy (that is doing the indicating) can do so even if intermediate elements don't support the proxy-feature mechanism at all.  This might be a more comprehensive way to express it:

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