Subject: [sipcore] draft-ietf-sipcore-rfc4244bis-11: ABNF backward compatibility

From: Brett Tate <[email-masked]>
Date: Tue, 1 Oct 2013 14:46:47 +0000

Hi,

The ABNF of draft-ietf-sipcore-rfc4244bis-11's hi-targeted-to-uri is not backwards compatible with RFC 4244.

Is this intentional?  And if so, should it be mentioned within section 16 and/or 16.1?

Thanks,
Brett

-----

draft-ietf-sipcore-rfc4244bis-11:

  History-Info = "History-Info" HCOLON hi-entry *(COMMA hi-entry)

  hi-entry = hi-targeted-to-uri *(SEMI hi-param)

  hi-targeted-to-uri = addr-spec / name-addr

RFC 4244:

  History-Info = "History-Info" HCOLON hi-entry *(COMMA hi-entry)

  hi-entry = hi-targeted-to-uri *( SEMI hi-param )

  hi-targeted-to-uri= name-addr

This email is intended solely for the person or entity to which it is addressed and may contain confidential and/or privileged information. If you are not the intended recipient and have received this email in error, please notify BroadSoft, Inc. immediately by replying to this message, and destroy all copies of this message, along with any attachment, prior to reading, distributing or copying it.

---

From: Mary Barnes <[email-masked]>
Date: Tue, 1 Oct 2013 12:41:16 -0500

I don't think it was intentional.  I backtracked and for whatever reason
that change appeared in the individual -00 and I could find no email
threads as to why we would have made that change.   It appears Dale pointed
out that issue a long time back, as well, but it seems we didn't make that
fix.

So, that is an error and we should fix that.  We have a couple other
editorial/clarification points that Dale has pointed out that we will also
include in a revision shortly.

Thanks,
Mary.

On Tue, Oct 1, 2013 at 9:46 AM, Brett Tate <[email-masked]> wrote:

> This email is intended solely for the person or entity to which it is
> addressed and may contain confidential and/or privileged information. If
> you are not the intended recipient and have received this email in error,
> please notify BroadSoft, Inc. immediately by replying to this message, and
> destroy all copies of this message, along with any attachment, prior to
> reading, distributing or copying it.
> _______________________________________________
> sipcore mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/sipcore
>

---

From: Francois Audet <[email-masked]>
Date: Tue, 1 Oct 2013 17:46:26 +0000

It does indeed look like an error to be fixed.

From: [email-masked] [mailto:[email-masked]] On Behalf Of Mary Barnes
Sent: Tuesday, October 1, 2013 10:41 AM
To: Brett Tate
Cc: [email-masked]; [email-masked]
Subject: Re: [sipcore] draft-ietf-sipcore-rfc4244bis-11: ABNF backward compatibility

I don't think it was intentional.  I backtracked and for whatever reason that change appeared in the individual -00 and I could find no email threads as to why we would have made that change.   It appears Dale pointed out that issue a long time back, as well, but it seems we didn't make that fix.

So, that is an error and we should fix that.  We have a couple other editorial/clarification points that Dale has pointed out that we will also include in a revision shortly.

Thanks,
Mary.

On Tue, Oct 1, 2013 at 9:46 AM, Brett Tate <[email-masked]<mailto:[email-masked]>> wrote:
Hi,

Thanks,
Brett

-----

RFC 4244:

This email is intended solely for the person or entity to which it is addressed and may contain confidential and/or privileged information. If you are not the intended recipient and have received this email in error, please notify BroadSoft, Inc. immediately by replying to this message, and destroy all copies of this message, along with any attachment, prior to reading, distributing or copying it.
_______________________________________________
sipcore mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/sipcore

---

From: Brett Tate <[email-masked]>
Date: Tue, 1 Oct 2013 18:26:15 +0000

Hi Mary,

It looks like Dale requested the change; however, I think that it will cause interoperability issues with rfc4244 devices if an rfc4244bis devices sends an addr-spec.  Thus I think that the change should be reverted (to be hi-targeted-to-uri= name-addr).

http://www.ietf.org/mail-archive/web/sipcore/current/msg04158.html

Thanks,
Brett

From: Mary Barnes [mailto:[email-masked]]
Sent: Tuesday, October 01, 2013 1:41 PM
To: Brett Tate
Cc: [email-masked]; [email-masked]
Subject: Re: [sipcore] draft-ietf-sipcore-rfc4244bis-11: ABNF backward compatibility

Thanks,
Mary.

Thanks,
Brett

-----

RFC 4244:

---

From: Mary Barnes <[email-masked]>
Date: Tue, 1 Oct 2013 13:38:36 -0500

Yes, you are correct - I misread the diffs and we did make the change based
on Dale's comment, but we (authors) agree that it should be consistent with
RFC 4244.

Mary.

On Tue, Oct 1, 2013 at 1:26 PM, Brett Tate <[email-masked]> wrote:

>  Hi Mary,****
>
> ** **
>
> It looks like Dale requested the change; however, I think that it will
> cause interoperability issues with rfc4244 devices if an rfc4244bis devices
> sends an addr-spec.  Thus I think that the change should be reverted (to be
> hi-targeted-to-uri= name-addr).****
>
> ** **
>
> http://www.ietf.org/mail-archive/web/sipcore/current/msg04158.html ****
>
> ** **
>
> Thanks,****
>
> Brett****
>
> ** **
>
> *From:* Mary Barnes [mailto:[email-masked]]
> *Sent:* Tuesday, October 01, 2013 1:41 PM
>
> *To:* Brett Tate
> *Cc:* [email-masked]; [email-masked]
> *Subject:* Re: [sipcore] draft-ietf-sipcore-rfc4244bis-11: ABNF backward
> compatibility****
>
>  ** **
>
> fix.  ****
> ** **
> include in a revision shortly.****
>
> ** **
>
> Thanks,****
>
> Mary. ****
>
> ** **
>
> On Tue, Oct 1, 2013 at 9:46 AM, Brett Tate <[email-masked]> wrote:***
> *
>
> Hi,
>
> https://www.ietf.org/mailman/listinfo/sipcore****
>
> ** **
>

---

From: Paul Kyzivat <[email-masked]>
Date: Tue, 01 Oct 2013 15:53:22 -0400

IIUC, the change was to permit addr-spec as well as name-addr.
And this issue is then that a 4244 implementation won't be able to parse 
that. Right?

Please ensure that the use cases are still correct after the change.

	Thanks,
	Paul

On 10/1/13 2:38 PM, Mary Barnes wrote:
> Yes, you are correct - I misread the diffs and we did make the change
> based on Dale's comment, but we (authors) agree that it should be
> consistent with RFC 4244.
>
> Mary.
>
>
> On Tue, Oct 1, 2013 at 1:26 PM, Brett Tate <[email-masked]
> <mailto:[email-masked]>> wrote:
>
>     Hi Mary,____
>
>     __ __
>
>     It looks like Dale requested the change; however, I think that it
>     will cause interoperability issues with rfc4244 devices if an
>     rfc4244bis devices sends an addr-spec.  Thus I think that the change
>     should be reverted (to be hi-targeted-to-uri= name-addr).____
>
>     __ __
>
>     http://www.ietf.org/mail-archive/web/sipcore/current/msg04158.html ____
>
>     __ __
>
>     Thanks,____
>
>     Brett____
>
>     __ __
>
>     *From:*Mary Barnes [mailto:[email-masked]
>     <mailto:[email-masked]>]
>     *Cc:* [email-masked]
>     <mailto:[email-masked]>;
>     [email-masked] <mailto:[email-masked]>
>     *Subject:* Re: [sipcore] draft-ietf-sipcore-rfc4244bis-11: ABNF
>     backward compatibility____
>
>     __ __
>
>     I don't think it was intentional.  I backtracked and for whatever
>     reason that change appeared in the individual -00 and I could find
>     no email threads as to why we would have made that change.   It
>     appears Dale pointed out that issue a long time back, as well, but
>     it seems we didn't make that fix. ____
>
>     __ __
>
>     editorial/clarification points that Dale has pointed out that we
>     will also include in a revision shortly.____
>
>     __ __
>
>     Thanks,____
>
>     Mary. ____
>
>     __ __
>
>     On Tue, Oct 1, 2013 at 9:46 AM, Brett Tate <[email-masked]
>     <mailto:[email-masked]>> wrote:____
>
>     Hi,
>
>     This email is intended solely for the person or entity to which it
>     is addressed and may contain confidential and/or privileged
>     information. If you are not the intended recipient and have received
>     this email in error, please notify BroadSoft, Inc. immediately by
>     replying to this message, and destroy all copies of this message,
>     along with any attachment, prior to reading, distributing or copying it.
>     [email-masked] <mailto:[email-masked]>
>     https://www.ietf.org/mailman/listinfo/sipcore____
>
>     __ __
>
>
>
>

---

From: Mary Barnes <[email-masked]>
Date: Tue, 1 Oct 2013 15:23:59 -0500

> And this issue is then that a 4244 implementation won't be able to parse
[MB] It's possible that some folks might be able to parse it, but we
shouldn't count on that.[/MB]

> Please ensure that the use cases are still correct after the change.
[MB] I don't think there's an issue with the call flows. [/MB]

>>     http://www.ietf.org/mail-**archive/web/sipcore/current/**
>> msg04158.html<http://www.ietf.org/mail-archive/web/sipcore/current/msg04158.html>____
>>
>>     __ __
>>
>>     Thanks,____
>>
>>     Brett____
>>
>>     __ __
>>
>>     *From:*Mary Barnes [mailto:mary.ietf.barnes@**gmail.com<[email-masked]>
>>     <mailto:mary.ietf.barnes@**gmail.com <[email-masked]>>]
>>     *Cc:* draft-ietf-sipcore-rfc4244bis@**tools.ietf.org<[email-masked]>
>>     <mailto:[email-masked]<[email-masked]>
>> >;
>>     *Subject:* Re: [sipcore] draft-ietf-sipcore-rfc4244bis-**11: ABNF
>>     The ABNF of draft-ietf-sipcore-rfc4244bis-**11's hi-targeted-to-uri
>> is
>>     not backwards compatible with RFC 4244.
>>
>>     draft-ietf-sipcore-rfc4244bis-**11:
>>
>>     ______________________________**_________________
>>     sipcore mailing list
>>     https://www.ietf.org/mailman/**listinfo/sipcore____<https://www.ietf.org/mailman/listinfo/sipcore____>
>>
>>     __ __
>>
>>
>>
>>
>>
>> ______________________________**_________________
>> sipcore mailing list
>> [email-masked]
>> https://www.ietf.org/mailman/**listinfo/sipcore<https://www.ietf.org/mailman/listinfo/sipcore>
>>
>>
> ______________________________**_________________
> sipcore mailing list
> [email-masked]
> https://www.ietf.org/mailman/**listinfo/sipcore<https://www.ietf.org/mailman/listinfo/sipcore>
>

---

From: Paul Kyzivat <[email-masked]>
Date: Tue, 01 Oct 2013 16:52:34 -0400

On 10/1/13 4:23 PM, Mary Barnes wrote:
> On Tue, Oct 1, 2013 at 2:53 PM, Paul Kyzivat <[email-masked]
> <mailto:[email-masked]>> wrote:
>
>     And this issue is then that a 4244 implementation won't be able to
>     parse that. Right?
>

No.

> [MB] I don't think there's an issue with the call flows. [/MB]

I just looked, and I think you are right.

>         <mailto:[email-masked]>
>         <mailto:[email-masked] <mailto:[email-masked]>>> wrote:
>
>              Hi Mary,____
>
>              __ __
>
>
>         http://www.ietf.org/mail-__archive/web/sipcore/current/__msg04158.html
>         <http://www.ietf.org/mail-archive/web/sipcore/current/msg04158.html>
>         ____
>
>              __ __
>
>              Thanks,____
>
>              Brett____
>
>              __ __
>
>              *From:*Mary Barnes [mailto:[email-masked]
>         <mailto:[email-masked]>
>              <mailto:[email-masked]
>         <mailto:[email-masked]>>]
>              *Cc:* [email-masked]
>         <mailto:[email-masked]>
>              <mailto:[email-masked]
>         <mailto:[email-masked]>>;
>         <mailto:[email-masked] <mailto:[email-masked]>>
>              *Subject:* Re: [sipcore]
>         draft-ietf-sipcore-rfc4244bis-__11: ABNF
>              On Tue, Oct 1, 2013 at 9:46 AM, Brett Tate
>         <[email-masked] <mailto:[email-masked]>
>              <mailto:[email-masked] <mailto:[email-masked]>>>
>         wrote:____
>
>
>              Hi,
>
>              The ABNF of draft-ietf-sipcore-rfc4244bis-__11's
>         hi-targeted-to-uri is
>              draft-ietf-sipcore-rfc4244bis-__11:
>
>              _________________________________________________
>              sipcore mailing list
>         <mailto:[email-masked] <mailto:[email-masked]>>
>         https://www.ietf.org/mailman/__listinfo/sipcore____
>         <https://www.ietf.org/mailman/listinfo/sipcore____>
>
>              __ __
>
>
>
>
>
>         _________________________________________________
>         sipcore mailing list
>         https://www.ietf.org/mailman/__listinfo/sipcore
>         <https://www.ietf.org/mailman/listinfo/sipcore>
>
>
>     _________________________________________________
>     sipcore mailing list
>     https://www.ietf.org/mailman/__listinfo/sipcore
>     <https://www.ietf.org/mailman/listinfo/sipcore>
>
>

---

From: Shida Schubert <[email-masked]>
Date: Tue, 1 Oct 2013 15:56:37 -0700

On Oct 1, 2013, at 1:23 PM, Mary Barnes <[email-masked]> wrote:

> And this issue is then that a 4244 implementation won't be able to parse that. Right?
> [MB] It's possible that some folks might be able to parse it, but we shouldn't count on that.[/MB] 
> 

 I can confirm this. 

 Shida

---

From: [email-masked] (Dale R. Worley)
Date: Wed, 2 Oct 2013 15:20:46 -0400 (EDT)

> From: Mary Barnes <[email-masked]>
> 

It's unfortunate, because essentially everywhere else where a header
has this general syntax, either a name-addr or an addr-spec is
allowed.  But for upward compatibility, we're stuck with what 4244
allowed.

> [MB] I don't think there's an issue with the call flows. [/MB]

I searched both drafts, and all hi-entries use name-addrs.

Dale

---

From: [email-masked] (Dale R. Worley)
Date: Fri, 4 Oct 2013 14:00:58 -0400 (EDT)

However, we should carefully consider what we are doing here.  All the
recent versions, from -06 to -11, use the "hi-targeted-to-uri =
addr-spec / name-addr" syntax.  The WGLCs seem to have been on the -06
and -09 versions.  So we're on thin ice here, changing a significant
technical element of the draft.  What do the chairs think, officially?

Dale

---

From: Paul Kyzivat <[email-masked]>
Date: Fri, 04 Oct 2013 15:43:37 -0400

> technical element of the draft.  What do the chairs think, officially?

I think this flew under the radar and most people didn't even realize it 
was changed. I personally was in favor of the change just for reasons of 
consistency, but hadn't recognized the backward compatibility issue.

No functionality is lost here. The only difference the change made was 
to allow "<" and ">" to be omitted in some cases.

The only risk I see is that somebody has *deployed* code that uses 
addr-spec. But since the new version hasn't become an RFC yet I don't 
have a lot of sympathy.

So I think we should be fine with this fix.

	Thanks,
	Paul

---

From: "DRAGE, Keith (Keith)" <[email-masked]>
Date: Sun, 6 Oct 2013 15:15:51 +0000

By all means post a request for WG approval of the change, but the general working principle was compatibility where possible.

Regards

Keith

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf
> Of Paul Kyzivat
> Sent: 04 October 2013 20:44
> To: Dale R. Worley
> Cc: [email-masked]