Subject: Re: [sipcore] WGLC for draft-ietf-sipcore-proxy-feature-02

From: Paul Kyzivat <[email-masked]>
Date: Sat, 02 Jun 2012 16:13:23 -0400

Just a reminder - this WGLC is open until Friday.
Shida provided a very thorough review. (Thank you Shida!)
It would be good if someone else could also look it over carefully.

	Thanks,
	Paul

On 5/18/12 11:10 AM, Paul Kyzivat wrote:
> I am issuing a WGLC for:
>
> draft-ietf-sipcore-proxy-feature-02
> (http://tools.ietf.org/html/draft-ietf-sipcore-proxy-feature-02)
>
> The WGLC will conclude at 23:59 UTC on June 8, 2012.
>
> (I'm giving it three weeks because there are a lot of things going on at
> this time - a 3gpp meeting, some holidays, etc.)
>
> Note that this is intended to satisfy our milestone: Mechanism to
> indicate proxy capabilities to both endpoints and other intermediaries
> in the path of a REGISTER transaction or dialog-forming transaction to
> IESG (PS)
>
> I'm looking for volunteers to perform a careful review of this document.
> It would be especially good to have participation of people who haven't
> previously been closely involved. Please inform me and Adam if you are
> able to do a careful WGLC review.
>
> Thanks,
> Paul (as co-chair)
> _______________________________________________
> sipcore mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/sipcore
>

---

From: Ivo Sedlacek <[email-masked]>
Date: Mon, 4 Jun 2012 14:11:37 +0200

Hello,

ISSUE: two possible ABNF rules (fcap-value-list, fcap-string-value) are defined for feature cap value. If sending entity uses fcap-value-list and receiving entity expects fcap-string-value (or vice verse), interoperability problem would occur.

PROPOSAL: the SIP feature cap specification states whether the feature caps value follows fcap-value-list ABNF rule or fcap-string-value ABNF rule. E.g.
-------------------------
4.4.3.  Feature Cap Values

   A SIP feature cap can have an associated value, or a list of values.
   A SIP feature cap value MUST conform to the ABNF defined in Section
   6.2.2.

<new>The SIP feature cap specification MUST define whether value of the feature cap follows the fcap-value-list ABNF rule or the fcap-string-value ABNF rule.</new>

   The SIP feature cap specification MUST define the syntax and
   semantics of any value defined for the SIP feature cap, including
   possible restrictions related to the usage of a specific value.

   A SIP feature cap value is only applicable for the SIP feature cap
   for which it has been defined.  For other SIP feature caps, the value
   has to be defined explicitly, even if the name or the semantics are
   identical.

   It is STRONLY RECOMMENDED to not re-use a value name that already has
   been defined for another SIP feature cap, unless the semantics of the
   values are the same.
-------------------------

Kind regards

Ivo Sedlacek

Ericsson
GF Technology, Terminal Standardization
Sweden
Office: +46 10 711 9382
[email-masked]
www.ericsson.com

This communication is confidential. We only send and receive email on the basis of the term set out at www.ericsson.com/email_disclaimer

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Paul Kyzivat
Sent: 2. června 2012 22:13
To: [email-masked]
Subject: Re: [sipcore] WGLC for draft-ietf-sipcore-proxy-feature-02

Just a reminder - this WGLC is open until Friday.
Shida provided a very thorough review. (Thank you Shida!) It would be good if someone else could also look it over carefully.

        Thanks,
        Paul

On 5/18/12 11:10 AM, Paul Kyzivat wrote:
> (I'm giving it three weeks because there are a lot of things going on
> at this time - a 3gpp meeting, some holidays, etc.)
>
> It would be especially good to have participation of people who
> haven't previously been closely involved. Please inform me and Adam if
> you are able to do a careful WGLC review.
>
> Thanks,
> Paul (as co-chair)

---

From: Paul Kyzivat <[email-masked]>
Date: Sun, 10 Jun 2012 20:06:59 +0200

Ivo,

I don't think Christer responded to you. I'll take a whack at it:

On 6/4/12 2:11 PM, Ivo Sedlacek wrote:
> Hello,
>
> ISSUE: two possible ABNF rules (fcap-value-list, fcap-string-value) are
> defined for feature cap value. If sending entity uses fcap-value-list
> and receiving entity expects fcap-string-value (or vice verse),
> interoperability problem would occur.

I trust you know that much of this syntax has been borrowed from RFC 
3840. Do you have the same issue with RFC 3840? There are some 
differences - 3840 borrows the IANA registry and procedures for adding 
to it from RFC 2506, while proxy-feature defines a new IANA registry 
that is somewhat similar to that one. (This one is more restrictive.)

In 3840 there is no explict tie between the syntax given in the IANA 
registry and the syntax in the header value. There is an implied 
relationship, in that the value had better be representable in the 
syntax of the header or else it won't be usable.

There is a lot of complexity and ugliness in 3840 in order to mesh it 
with 2506 (lets not go into why that was done - its water over the dam), 
and to facilitate callerprefs in 3841. 3841 reuses this syntax to define 
the conditions for preferences, and it allows ranges, negations, etc. 
that are reflected here. In principle it should be possible to use 
something like:

	priority=">10"
or	duplex="!full"

But the definitions of the particular features would have to allow that. 
Currently none of them do.

One area where there could be confusion is the one you raise. In 
particular, consider:
	description="SomeText"
	description="<SomeText>"

The first is a token-nobang and the second is a string-value. The only 
behavioral difference is that tokens are compared in a case-insensitive 
way, and string-values are compared in a case-sensitive way. The 
defintion of "description" says the value is string with an equality 
relationship. If you are strict you would probably say it must be a 
string-value. But others might think a token would do. I don't think 
3840 is entirely clear here. (If I was implementing it I would allow 
either.)

> PROPOSAL: the SIP feature cap specification states whether the feature
> caps value follows fcap-value-list ABNF rule or fcap-string-value ABNF
> rule. E.g.
> <new>The SIP feature cap specification MUST define whether value of the
> feature cap follows the fcap-value-list ABNF rule or the
> fcap-string-value ABNF rule.</new>

I see no reason why you couldn't, if you wished, define a feature that 
explicitly allowed values of both types.

How about

<new>The SIP feature cap specification MUST define the value(s) in 
accord with the syntax defined in section 6.2.2.</new>

	Thanks,
	Paul

---

From: Paul Kyzivat <[email-masked]>
Date: Sun, 10 Jun 2012 20:15:46 +0200

The WGLC for draft-ietf-sipcore-proxy-feature-02.
Thank you to those of you who provided comments.

I didn't see any major, or unsolvable issues. Christer indicated to me 
that he is going to issue a new version that addresses the WGLC comments 
received. Then I'll be working with the ADs on advancing this.

	Thank you,
	Paul (as co-chair)

---

From: Ivo Sedlacek <[email-masked]>
Date: Mon, 11 Jun 2012 13:22:59 +0200

Hello,

> The first is a token-nobang and the second is a string-value. The only behavioral 
> difference is that tokens are compared in a case-insensitive way, and string-values 
> are compared in a case-sensitive way. The defintion of "description" says the value 
> is string with an equality relationship. If you are strict you would probably say 
> it must be a string-value. But others might think a token would do. I don't think 
> > <new>The SIP feature cap specification MUST define whether value of  
> > the feature cap follows the fcap-value-list ABNF rule or the  
> I see no reason why you couldn't, if you wished, define a feature that explicitly 
> allowed values of both types. 
> 
> How about 
> 
> <new>The SIP feature cap specification MUST define the value(s) in accord with the 
> syntax defined in section 6.2.2.</new> 
> 

OK for me. 

Thanks for clarification.

Kind regards

Ivo Sedlacek

---

From: Christer Holmberg <[email-masked]>
Date: Mon, 11 Jun 2012 13:39:00 +0200

Hi,

Note that the first paragraph already contains the following sentence:

"A feature cap value MUST conform to the ABNF defined in Section 6.2.2."

But, I think it fits better in the second paragraph, so my suggestion is to remove the existing sentence from the first paragraph, and add Paul's suggested sentence to the second paragraph:

		"The feature cap specification MUST define the syntax and semantics 
		of any value defined for the feature cap, including possible 
		restrictions related to the usage of a specific value. The feature 
		cap specification MUST define the value(s) in accordance with the 
		syntax defined in section 6.2.2."

Regards,

Christer

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Ivo Sedlacek
Sent: 11. kesäkuuta 2012 14:23
To: Paul Kyzivat
Cc: [email-masked]
Subject: Re: [sipcore] WGLC for draft-ietf-sipcore-proxy-feature-02

Hello,

> behavioral difference is that tokens are compared in a 
> case-insensitive way, and string-values are compared in a 
> case-sensitive way. The defintion of "description" says the value is 
> string with an equality relationship. If you are strict you would 
> probably say it must be a string-value. But others might think a token 
> would do. I don't think
> > PROPOSAL: the SIP feature cap specification states whether the 
> > feature caps value follows fcap-value-list ABNF rule or 
> > fcap-string-value ABNF rule. E.g.

OK for me. 

Kind regards

Ivo Sedlacek

---

From: Paul Kyzivat <[email-masked]>
Date: Mon, 11 Jun 2012 13:45:43 +0200

WFM