On Jan 5, 2013, at 6:51 AM, John Levine jo...@taugh.com wrote:
So if you don't attend IEEE, quit your whining: at least you won't have
to eat he same hotel food for 2 weeks in a row...
You don't have to eat there. Check out the reviews of this restaurant
across the street:
Hi Mahmoud,
The LEACH is not a protocol worked on so far in IETF, not sure if it
standard yet elsewhere!
AB
-
Hello everybody,
I am a researcher of Master's degree , working on LEACH routing
protocol for wireless sensor networks and i need to know for which
standard does LEACH , its family
On Sat, 5 Jan 2013, Yoav Nir wrote:
I wonder if you risk a jaywalking ticket for crossing that street without a
car.
You did read the reviews, right? Sounds like you would risk more than
a ticket...
https://plus.google.com/118141773512616354020/about
Hi Hector,
I like your method, which beleive is the reason why the RFC2119 is
great help for implementors. As I mentioned before if the protocol
specification is long and complicated no doubt its language may make
it more difficult to readers or writters. Therefore, it will be nice
if the IETF
IMO, too many specs seriously overuse/misuse 2119 language, to the
detriment of readability, common sense, and reserving the terms to
bring attention to those cases where it really is important to
highlight an important point that may not be obvious to a casual
reader/implementor.
also to
As an operator, I purchase equipment and need to write RFQs. I would like
to able to ask more than does the product implement RFC whatever, I
want to also ask Please document all instances where you did not follow
all MUST and SHOULD, and why.
Otherwise I think there needs to be better
On Sat, 5 Jan 2013, Mikael Abrahamsson wrote:
Otherwise I think there needs to be better definition of what it means
to implement or support an RFC when it comes to completness and what
this means as per following SHOULD and MAY.
Also what it means following things in it that is not RFC2119
(was Re: I'm struggling with 2219 language again)
Where you want to use MUST is where an implementation might be tempted
to take a short cut -- to the detriment of the Internet -- but could
do so without actually breaking interoperability. A good example is
with retransmissions and
We can fix that, by discussing it further, or as Scott mentioned make
a survey within IETF [*]
[*] http://www.ietf.org/mail-archive/web/ietf/current/msg76582.html
AB
On 1/5/13, Abdussalam Baryun abdussalambar...@gmail.com wrote:
(was Re: I'm struggling with 2219 language again)
Where you
I totally agree with you,
AB
+++
As an operator, I purchase equipment and need to write RFQs. I would
like to able to ask more than does the product implement RFC
whatever, I want to also ask Please document all instances where
you did not follow all MUST and SHOULD, and why.
Otherwise I think
Hi Mikael
Also what it means following things in it that is not RFC2119 language.
It will mean, you should understand me/english/ietf/procedure even if
I don't have to explain, and you need to understand English well even
if you are a great implementor or great programming language speaker.
AB
On Sat, 5 Jan 2013, Abdussalam Baryun wrote:
Hi Mikael
Also what it means following things in it that is not RFC2119 language.
It will mean, you should understand me/english/ietf/procedure even if
I don't have to explain, and you need to understand English well even
if you are a great
Hi,
At its core, the value of the IETF is technical. We must always make
the best technical standards we can possibly make, adhering to the
values of rough consensus and running code. Everything else is
secondary or nobody (government or otherwise) will want to implement
what we develop. It's
--On Saturday, January 05, 2013 10:13 +0100 Mikael Abrahamsson
swm...@swm.pp.se wrote:
The problem here is that I want them to pay back some of the
money (or take back the equipment totally and give back all
money) for breach of contract, when I discover that they
haven't correctly (as in
Keep in mind only a STD is a real standard. A RFC is still only a
recommendation, a guideline. What makes it a pseudo-standard is
the # of implementations, how wide spread it is and foremost IMO, how
much embedded it is so that a change has a negative impact. At that
point, an RFC not
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
I read the responses so far, and what can be said today is that there is 2
philosophies, with supporters in both camps. The goal of the IETF is to make
the Internet work better, and I do believe that RFC 2119 is one of the
fundamental tool to reach
On 1/4/13 11:39 PM, Mikael Abrahamsson wrote:
As an operator, I purchase equipment and need to write RFQs. I would
like to able to ask more than does the product implement RFC
whatever, I want to also ask Please document all instances where you
did not follow all MUST and SHOULD, and why.
Mark,
The WG's reasoning, as stated in your message below, seems flawed.
Messages since your last communication on this matter have shown:
1) The ambiguity around arrays makes the patch format unsuitable for
common concurrent editing algorithms.
2) The ambiguity is likely to occur in the real
Robert,
I may have missed it, but can you provide a non-theoretical example of this
problem that you're suggesting exists in practice?
On Sat, Jan 5, 2013 at 4:19 PM, Robert Sayre say...@gmail.com wrote:
Mark,
The WG's reasoning, as stated in your message below, seems flawed.
Messages since
Robert,
I neither represent the WG (except in as far as I attempt to do so as document
editor), nor do I judge consensus in the WG (the Chairs do, although at this
late date, the IESG are making the decisions).
That said, if we were starting this from scratch, I *personally* could see
adding
On Sat, Jan 5, 2013 at 5:48 PM, Mark Nottingham m...@mnot.net wrote:
However, at this point, doing so really a judgement call; we have multiple
implementations, and we shouldn't
force them to change arbitrarily.
The word arbitrarily seems inappropriate here. I raised at least
four technical
On 06/01/2013, at 1:29 PM, Robert Sayre say...@gmail.com wrote:
On Sat, Jan 5, 2013 at 5:48 PM, Mark Nottingham m...@mnot.net wrote:
However, at this point, doing so really a judgement call; we have multiple
implementations, and we shouldn't
force them to change arbitrarily.
The word
On Sat, Jan 5, 2013 at 6:59 PM, Mark Nottingham m...@mnot.net wrote:
Yes, you've brought that to our attention several times. If you wanted
this spec to align with your software, it would have been much easier
if you'd got involved before Last Call.
Well, there shouldn't be any big
On Jan 5, 2013 8:20 PM, Robert Sayre say...@gmail.com wrote:
On Sat, Jan 5, 2013 at 6:59 PM, Mark Nottingham m...@mnot.net wrote:
Yes, you've brought that to our attention several times. If you wanted
this spec to align with your software, it would have been much easier
if you'd got
On Sat, Jan 5, 2013 at 8:55 PM, James M Snell jasn...@gmail.com wrote:
On Jan 5, 2013 8:20 PM, Robert Sayre say...@gmail.com wrote:
On Sat, Jan 5, 2013 at 6:59 PM, Mark Nottingham m...@mnot.net wrote:
Yes, you've brought that to our attention several times. If you wanted
this spec to
[{op:type,path:,value:array},{op:remove,path:/1}]
Problem solved. Still no bug, and still nothing I can see that needs
fixing.
I've said my piece on it to. Afaic, this spec is done and ready to go.
- James
On Jan 5, 2013 9:25 PM, Robert Sayre say...@gmail.com wrote:
On Sat, Jan 5, 2013 at
26 matches
Mail list logo
