Subject: [sipcore] PLEASE RESPOND -- Re: Call for adoption & WGLC: draft-barnes-sipcore-rfc4244bis-callflows

From: Adam Roach <[email-masked]>
Date: Thu, 05 Jul 2012 11:58:41 -0500

[as chair]

This has been the second call for adoption for this document, with no 
interest indicated so far. We have about a day and a half left. If 
anyone is interested in seeing it published, please respond. if you 
believe that the document is not something SIPCORE should publish, 
please respond to that effect as well.

Without any indication of interest from the working group, all we can do 
is publish the base specification without any examples of how the 
mechanism can be used.

/a

On 6/21/12 1:54 PM, Adam Roach - SIPCORE Chair wrote:
> [as chair]
>
> SIPCORE Working Group:
>
> As you are probably aware, back in June of 2010, we decided to split 
> the History-Info callflows out of the (already adopted) document 
> draft-ietf-sipcore-rfc4244bis. The callflows document was not formally 
> adopted by the working group, but remains an important informational 
> companion to the base specification.
>
> As part of the publication process, then, we would like to see 
> draft-barnes-sipcore-rfc4244bis-callflows sent to the RFC editor at 
> the same time as draft-ietf-sipcore-rfc4244bis. To that end, we are 
> announcing a two-week call for working group adoption at the same time 
> as a two-week working group last call. We feel this timing overlap is 
> appropriate due to the maturity of the document combined with the fact 
> that its text was, at a point in the past, part of an adopted working 
> group document.
>
> Interested parties should respond to this message with a clear 
> indication of whether they support the adoption of 
> draft-barnes-sipcore-rfc4244bis-callflows as a working group document 
> under the existing milestone that includes draft-ietf-sipcore-rfc4244bis.
>
> Additionally, any final comments on the contents of the document 
> should be provided during this two-week last call period.
>
> This call for adoption and WGLC ends on Friday, July 6th.
>
> The document is available here:
> http://tools.ietf.org/html/draft-barnes-sipcore-rfc4244bis-callflows-03
>
> /a

---

From: Christer Holmberg <[email-masked]>
Date: Thu, 5 Jul 2012 19:50:41 +0200

Hi,

As co-author, I am obviously interested.

Regards,

Christer

________________________________________
From: [email-masked] [[email-masked]] On Behalf Of Adam Roach [[email-masked]]
Sent: Thursday, July 05, 2012 7:58 PM
To: SIPCORE Chairs
Cc: SIPCORE (Session Initiation Protocol Core) WG
Subject: [sipcore] PLEASE RESPOND -- Re: Call for adoption & WGLC:      draft-barnes-sipcore-rfc4244bis-callflows

[as chair]

/a

> http://tools.ietf.org/html/draft-barnes-sipcore-rfc4244bis-callflows-03

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

---

From: "Olle E. Johansson" <[email-masked]>
Date: Thu, 5 Jul 2012 20:05:14 +0200

5 jul 2012 kl. 18:58 skrev Adam Roach:

> [as chair]
> 
> This has been the second call for adoption for this document, with no interest indicated so far. We have about a day and a half left. If anyone is interested in seeing it published, please respond. if you believe that the document is not something SIPCORE should publish, please respond to that effect as well.
> 
> Without any indication of interest from the working group, all we can do is publish the base specification without any examples of how the mechanism can be used.
I support publishing call flows. It really helps implementors.
Do itt.

/O
>> As you are probably aware, back in June of 2010, we decided to split the History-Info callflows out of the (already adopted) document draft-ietf-sipcore-rfc4244bis. The callflows document was not formally adopted by the working group, but remains an important informational companion to the base specification.
>> 
>> As part of the publication process, then, we would like to see draft-barnes-sipcore-rfc4244bis-callflows sent to the RFC editor at the same time as draft-ietf-sipcore-rfc4244bis. To that end, we are announcing a two-week call for working group adoption at the same time as a two-week working group last call. We feel this timing overlap is appropriate due to the maturity of the document combined with the fact that its text was, at a point in the past, part of an adopted working group document.
>> 
>> Interested parties should respond to this message with a clear indication of whether they support the adoption of draft-barnes-sipcore-rfc4244bis-callflows as a working group document under the existing milestone that includes draft-ietf-sipcore-rfc4244bis.
>> 
>> Additionally, any final comments on the contents of the document should be provided during this two-week last call period.
>> 

---
* Olle E Johansson - [email-masked]
* Cell phone +46 70 593 68 51, Office +46 8 96 40 20, Sweden

---

From: "Worley, Dale R (Dale)" <[email-masked]>
Date: Thu, 5 Jul 2012 16:17:48 -0400

> is publish the base specification without any examples of how the 

This document is useful and should be adopted.

But in regard to last-call, I note that of all of the examples, only one
involves more than one SIP domain name, and that example is a toll-free
service feeding to an AOR:  That is, all call flows are situations in
which some one administrative entity has coordinated everything, and as
a consequence, the UAS that receives the History-Info header can
"understand" all of the URIs in History-Info.

This can allow a misunderstanding of History-Info processing -- which I
have seen on this mailing list, namely that History-Info can be
interpreted "from the top", that is, starting at index 1.  Properly,
History-Info can only be successfully interpreted "from the bottom",
that is, tracking back from the URI describing the UAS, to the URI from
which it was derived, etc., back to the point where the UAS can no
longer interpret the URIs, at which point it must give up.  In general,
the UAS cannot expect to be able to understand index 1.

As a simple example that does not have this limitation, let me propose:
Alice <sip:[email-masked]> forwards to Bob
<sip:[email-masked]>, but Bob has his phone (or switch) set to
forward to Carol <sip:[email-masked]>, and Carol has set her
phone/switch to forward to David <sip:[email-masked]>.  David's
UA may be expecting calls directed to Carol, but may not know to expect
calls directed to Bob.

Dale

---

From: Iñaki Baz Castillo <[email-masked]>
Date: Thu, 5 Jul 2012 22:40:16 +0200

2012/7/5 Adam Roach <[email-masked]>:
> interest indicated so far. We have about a day and a half left. If anyone is
> interested in seeing it published, please respond. if you believe that the
> document is not something SIPCORE should publish, please respond to that
> effect as well.
>
> Without any indication of interest from the working group, all we can do is
> publish the base specification without any examples of how the mechanism can
> be used.

Hi, I have not too much interest in how History-Info works, but a
standard document with call-flows will always help and make easier the
spec adoption. So IMHO it's a useful draft and therefore I support it.
If someday I have to implement History-Info I will be happy if this
draft has become a standard :)

Regards.

-- 
Iñaki Baz Castillo
<[email-masked]>

---

From: Marc Petit-Huguenin <[email-masked]>
Date: Thu, 05 Jul 2012 13:45:32 -0700

On 07/05/2012 01:40 PM, Iñaki Baz Castillo wrote:
>> interest indicated so far. We have about a day and a half left. If anyone
>> is interested in seeing it published, please respond. if you believe that
>> the document is not something SIPCORE should publish, please respond to
>> that effect as well.
>> 
> Hi, I have not too much interest in how History-Info works, but a standard
> document with call-flows will always help and make easier the spec
> adoption. So IMHO it's a useful draft and therefore I support it. If
> someday I have to implement History-Info I will be happy if this draft has
> become a standard :)

The current intended status is Informational, so it cannot become a standard
in its current form.

- -- 
Marc Petit-Huguenin
Email: [email-masked]
Blog: http://blog.marc.petit-huguenin.org
Profile: http://www.linkedin.com/in/petithug

---

From: Iñaki Baz Castillo <[email-masked]>
Date: Thu, 5 Jul 2012 22:46:45 +0200

> The current intended status is Informational, so it cannot become a standard

Yes sure, I just meant that if the document becomes a RFC it is then a
good documentation source for implementors.

-- 
Iñaki Baz Castillo
<[email-masked]>

---

From: Marc Petit-Huguenin <[email-masked]>
Date: Thu, 05 Jul 2012 13:58:53 -0700

On 07/05/2012 01:46 PM, Iñaki Baz Castillo wrote:
>> The current intended status is Informational, so it cannot become a
>> standard in its current form.
> 
> Yes sure, I just meant that if the document becomes a RFC it is then a good
> documentation source for implementors.
> 

No, it will be a justification for implementors to not read the standard.  But
that's better than having the examples inside the standard, I suppose.

- -- 
Marc Petit-Huguenin

---

From: <[email-masked]>
Date: Fri, 6 Jul 2012 07:22:19 +0200

I'm interested as well

Best Regards

Roland

-----Ursprüngliche Nachricht-----
Von: [email-masked] [mailto:[email-masked]] Im Auftrag von Christer Holmberg
Gesendet: Donnerstag, 5. Juli 2012 19:51
An: Adam Roach; SIPCORE Chairs
Cc: SIPCORE (Session Initiation Protocol Core) WG
Betreff: Re: [sipcore] PLEASE RESPOND -- Re: Call for adoption & WGLC: draft-barnes-sipcore-rfc4244bis-callflows

Hi,

Regards,

Christer

[as chair]

/a

---

From: Paul Kyzivat <[email-masked]>
Date: Fri, 06 Jul 2012 11:51:27 -0400

> draft has become a standard :)

And like many, you will implement to the examples, without bothering to 
look at the spec, right? :-)

	Thanks,
	Paul

---

From: Mary Barnes <[email-masked]>
Date: Fri, 6 Jul 2012 11:04:52 -0500

Yes, many do tend to follow the call flows and not so carefully read the
spec, but there's not a thing we can do about stupidity.  However, the
majority of people are visual learners and thus having a call flow document
is an extremely useful aid to understanding the spec.

I'm also hoping your comment is made as an individual and not as a chair ;)

Mary.

On Fri, Jul 6, 2012 at 10:51 AM, Paul Kyzivat <[email-masked]> wrote:

> ______________________________**_________________
> 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: Fri, 06 Jul 2012 12:12:23 -0400

On 7/6/12 12:04 PM, Mary Barnes wrote:
> majority of people are visual learners and thus having a call flow
> document is an extremely useful aid to understanding the spec.
>

Sorry - yes my comment was as individual. And it was a JOKE.
(Note the smiley.)

But it was an intentionally disparaging comment on those who implement 
to examples. In spite of people doing so I do think use cases and 
examples are a good thing.

	Thanks,
	Paul

> Mary.
>
> On Fri, Jul 6, 2012 at 10:51 AM, Paul Kyzivat <[email-masked]
> <mailto:[email-masked]>> wrote:
>
>     And like many, you will implement to the examples, without bothering
>     to look at the spec, right? :-)
>
>              Thanks,
>              Paul
>
>     _________________________________________________
>     sipcore mailing list
>     [email-masked] <mailto:[email-masked]>
>     https://www.ietf.org/mailman/__listinfo/sipcore
>     <https://www.ietf.org/mailman/listinfo/sipcore>
>
>

---

From: "Worley, Dale R (Dale)" <[email-masked]>
Date: Fri, 6 Jul 2012 13:48:19 -0400

On Fri, 2012-07-06 at 11:04 -0500, Mary Barnes wrote:
> Yes, many do tend to follow the call flows and not so carefully read
> the spec, but there's not a thing we can do about stupidity.  However,
> the majority of people are visual learners and thus having a call flow

And it's a great error-detection tool -- Are the examples correct based
on my understanding of the specification?

Dale