Thank you.That seems a reasonable compromise among the constraints.
Ypyrs,Joel
Sent via the Samsung Galaxy S® 6, an AT 4G LTE smartphone
Original message From: Ben Campbell Date:
1/27/17 14:17 (GMT-06:00) To: marianne.moh...@orange.com Cc: Joel Halpern
On 27 Jan 2017, at 11:15, marianne.moh...@orange.com wrote:
Hi Joel,
I have submitted a new version (v-13) of the draft.
I have addressed your comment for IPv6 addresses format in the
example.
Concerning your major comment, the discussion is leaded by Ben.
To that point: Please note that
Hi Joel,
I have submitted a new version (v-13) of the draft.
I have addressed your comment for IPv6 addresses format in the example.
Concerning your major comment, the discussion is leaded by Ben.
I hope I have correctly address your comment.
At this point I will defer to the relevant ADs.
As far as I can tell, although the entry was created by an Informational
RFC, the registry still claims that it is standards track.
And since this document is defining behavior, it behaves more like a
standards track document than an Informational
> On Dec 15, 2016, at 10:35 PM, Joel M. Halpern wrote:
>
> I see your point about this adding a value to the entry created by RFC 4458.
> Is there a reason this can not simply be PS? The fact that 4458 is
> Informational does not, as far as I can tell, justify continuing
I see your point about this adding a value to the entry created by RFC 4458.
Is there a reason this can not simply be PS? The fact that 4458 is
Informational does not, as far as I can tell, justify continuing the
error. While this is for a 3GPP usage, it appears to have been reviewed
by the
Hi Joel,
Thanks for the comments. There has been a fair amount of discussion
about the status of the draft. The situation is clearly not optimal, and
I welcome input on how to straighten it out.
The rational so far has been that this draft updates RFC 4588, which is
informational. It adds
Reviewer: Joel Halpern
Review result: Ready with Issues
Major:
This document defines a new code for use in SIP, and specifies new
behavior both for the code itself and for its use in history-info. I
am thus confused as to how this can be an informational RFC. It looks
like it either