On Wed, Aug 14, 2013 at 9:46 PM, Carsten Bormann wrote:
> On Aug 13, 2013, at 13:14, Tony Finch wrote:
>
> > MessagePack is simpler so will need even less code
>
> FWIW, earlier today I had a nice afternoon with the msgpack-ruby C code,
> converting it to encoding and decoding CBOR instead.
>
>
On 08/15/2013 11:04 AM, Graham Klyne wrote:
Hi Harald,
On 14/08/2013 19:49, Harald Alvestrand wrote:
On 08/13/2013 12:14 AM, Graham Klyne wrote:
[...]
But, in a personal capacity, not as designated reviewer, I have to
ask *why*
this needs to be a URI. As far as I can tell, it is intended for
I agree with Harald.
Both the STUN and TURN URIs really do represent what we traditionally use URIs
for: they identify a physical resource, a protocol for accessing the resource,
etc. Unlike a data URL, the STUN/TURN URI is not locally/directly
self-contained data - it's a resource identifier,
Some comments on this STUN draft and the TURN one:
1) The ABNF in these drafts leaves no room for future extension such as adding
parameters. Was that intentional?
2) Why do both of these docs repeat a lot of ABNF from RFC 3986, instead of
just referencing it? It says in the appendix some AB
On 08/15/2013 04:05 PM, Graham Klyne wrote:
> Harald,
>
> Briefly:
>
> 1. Thanks for the reference,
>
> and
>
> 2. I misunderstood what you meant by "This is a format for a piece of
> data". In light of your clarification, I withdraw my comments 3 & 4.
> Identification of the STUN service would a
On 8/15/13 8:10 AM, Harald Alvestrand wrote:
> On 08/15/2013 04:05 PM, Graham Klyne wrote:
>> Harald,
>>
>> Briefly:
>>
>> 1. Thanks for the reference,
>>
>> and
>>
>> 2. I misunderstood what you meant by "This is a format for a piece of
>> data". In light of your clarification, I withdraw my comm
On 08/15/2013 04:20 PM, Peter Saint-Andre wrote:
> On 8/15/13 8:10 AM, Harald Alvestrand wrote:
>> On 08/15/2013 04:05 PM, Graham Klyne wrote:
>>> Harald,
>>>
>>> Briefly:
>>>
>>> 1. Thanks for the reference,
>>>
>>> and
>>>
>>> 2. I misunderstood what you meant by "This is a format for a piece of
Hi Harald,
On 14/08/2013 19:49, Harald Alvestrand wrote:
On 08/13/2013 12:14 AM, Graham Klyne wrote:
[...]
But, in a personal capacity, not as designated reviewer, I have to ask *why*
this needs to be a URI. As far as I can tell, it is intended for use only in
very constrained environments, w
Harald,
Briefly:
1. Thanks for the reference,
and
2. I misunderstood what you meant by "This is a format for a piece of data". In
light of your clarification, I withdraw my comments 3 & 4. Identification of
the STUN service would appear to be a perfectly reasonable use.
...
So the remai
At 07:41 15-08-2013, The IESG wrote:
The IESG has received a request from the Reputation Services WG (repute)
to consider the following document:
- 'A Reputation Query Protocol'
as Proposed Standard
The IESG plans to make a decision in the next few weeks, and solicits
final comments on this a
At 07:43 15-08-2013, The IESG wrote:
The IESG has received a request from the Reputation Services WG (repute)
to consider the following document:
- 'A Reputation Response Set for Email Identifiers'
as Proposed Standard
The IESG plans to make a decision in the next few weeks, and solicits
fina
At 07:44 15-08-2013, The IESG wrote:
The IESG has received a request from the Reputation Services WG (repute)
to consider the following document:
- 'A Media Type for Reputation Interchange'
as Proposed Standard
The IESG plans to make a decision in the next few weeks, and solicits
final commen
At 07:45 15-08-2013, The IESG wrote:
The IESG has received a request from the Reputation Services WG (repute)
to consider the following document:
- 'A Model for Reputation Reporting'
as Informational RFC
The IESG plans to make a decision in the next few weeks, and solicits
final comments on t
At 11:48 14-08-2013, IAB Chair wrote:
This is a call for review of "List of Internet Official Protocol
Standards: Replaced by an Online Database" prior to potential
approval as an IAB stream RFC.
The document is available for inspection here:
https://datatracker.ietf.org/doc/draft-rfced-rfcxx
Hi Joe,
please see below.
Thanks,
Yaron
On 2013-08-14 01:20, Joe Hildebrand wrote:
(leaving a full response to the authors, and responding to a couple of
points I found interesting)
On 8/13/13 3:11 PM, "Yaron Sheffer" wrote:
- Arrays are prefixed by the number of elements but not b
On Aug 15, 2013, at 12:26 PM, Yaron Sheffer wrote:
>>> - One tag value you may want to consider adding is "critical" in the
>>> security sense of the word, i.e., an application is required to fail if
>>> it does not understand the value (probably best applied to map keys).
>>
>> That's also an i
David,
I agree with Sam here. The key table is analogous to the SPD in 4301,
but not
the PAD.
Another doc being developed in the KARP WG does have a "Routing
Authentication Policy
Database" (RAPD) that incorporates aspects of the PAD from 4301, as well
as some
SPD fields.
Steve
On 8/10/2013 12:29 PM, Wesley Eddy wrote:
On 8/10/2013 1:43 AM, Martin Sustrik wrote:
Hi all,
Does anyone have any idea how widely is TCPMUX (RFC 1078) protocol used?
Is it the case that there are inetd daemons in TCPMUX mode running
everywhere, or can it be rather considered a dead protocol?
Hi Paul,
I am quite sure that I fully understand the semantics of "critical"
(probably erroneously), so I'm not the right person to clarify the
various meanings of the word. I would appreciate a proposal.
Just for the record, my "critical" means: the reader must be able to
process the data i
On Aug 15, 2013, at 1:19 PM, Yaron Sheffer wrote:
> I am quite sure that I fully understand the semantics of "critical" (probably
> erroneously), so I'm not the right person to clarify the various meanings of
> the word. I would appreciate a proposal.
>
> Just for the record, my "critical" mea
In fact I answered your question precisely when I mentioned "contained"
data items (i.e., contained in the critical one). So I may be wrong but
at least I'm consistent...
I think the concept of criticality is powerful, even if in the past we
messed it up.
Thanks,
Yaron
On 2013-08-15
On Thu, Aug 15, 2013 at 9:19 PM, Yaron Sheffer wrote:
> Hi Paul,
>
> I am quite sure that I fully understand the semantics of "critical"
> (probably erroneously), so I'm not the right person to clarify the various
> meanings of the word. I would appreciate a proposal.
>
> Just for the record, my "
Hi Paul,
Sorry for the top posting. IMAP ate your mail. Responding to several remaining points:
- A parser that looks for duplicates must be able to detect that {{"a":1, "b":2}:4, {"b":2, "a":1}:5} does in fact have a duplicate key, because the two internal maps (used as keys) are
On 8/15/2013 4:18 PM, Joe Touch wrote:
>
>
> On 8/10/2013 12:29 PM, Wesley Eddy wrote:
>> On 8/10/2013 1:43 AM, Martin Sustrik wrote:
>>> Hi all,
>>>
>>> Does anyone have any idea how widely is TCPMUX (RFC 1078) protocol used?
>>> Is it the case that there are inetd daemons in TCPMUX mode running
On 13/08/2013, at 11:00 AM, Douglas Otis wrote:
>
> 1) Ensure exact digital interfaces driving projectors are fully available
> remotely.
That would be fantastic, if feasible. Much simpler than sharing through
software.
> 2) Ensure Audio access requires an identified request via XMPP prio
Total of 125 messages in the last 7 days.
script run at: Fri Aug 16 00:53:02 EDT 2013
Messages | Bytes| Who
+--++--+
7.20% |9 | 10.47% | 108804 | hal...@gmail.com
5.60% |7 | 8.58% |89136 | hadriel.kap...@o
On 15/08/13 22:18, Joe Touch wrote:
Does anyone have any idea how widely is TCPMUX (RFC 1078) protocol used?
Is it the case that there are inetd daemons in TCPMUX mode running
everywhere, or can it be rather considered a dead protocol?
Specifically, if I implement a new TCPMUX daemon how likely
On 16/08/13 03:23, Wesley Eddy wrote:
There are semantics issues to; see draft-touch-tcp-portnames-00 for
information (this is being revised for resubmission shortly, FWIW).
I totally agree. In fact, in the update to the TCP roadmap [1], we
added TCPMUX to the section on "Historic and Undeplo
28 matches
Mail list logo
