Section 8 states
Applications MUST not set contradictory flags at the same time.
I think the document should specify what the API must do if
contradictory flags are set. That would be the normative MUST, not
the above statement of the obvious.
Brian
Brian,
Section 8 states
Applications MUST not set contradictory flags at the same time.
I think the document should specify what the API must do if
contradictory flags are set. That would be the normative MUST, not
the above statement of the obvious.
Thanks for your review, Brian!
I
On 2007-05-21 12:47, Jari Arkko wrote:
Brian,
Section 8 states
Applications MUST not set contradictory flags at the same time.
I think the document should specify what the API must do if
contradictory flags are set. That would be the normative MUST, not
the above statement of the
I have been selected as the General Area Review Team (Gen-ART)
reviewer for this draft (for background on Gen-ART, please see
http://www.alvestrand.no/ietf/gen/art/gen-art-FAQ.html).
Please resolve these comments along with any other Last Call comments
you may receive. Apologies for the late
All;
There are three opportunities each year to be a Host and Sponsor of an
IETF meeting in venues throughout the world. The IETF calendar with the
regions targeted for the meetings can be found at:
http://www3.ietf.org/meetings/0mtg-sites.txt. The Host may even suggest
a particular city
All;
Based upon feedback received an adjustment was made in March of 2013.
Please advise if any further modification to the proposed IETF Meeting
schedule below is desired.
Thanks
Ray Pelletier
IAD
2011
16IETF 80Mar 27 - Apr 1
17IETF 81Jul 24 - 29
18IETF 82
On 5/19/07, Tim Bray [EMAIL PROTECTED] wrote:
Well Rob, I think the community at large and the IESG in particular
would welcome suggestions on what to do with this one.
Sorry Tim, can't agree with that assertion. At least some people seem
to be content with handwaving, if the current Atompub
On Sunday, May 20, 2007 01:41:29 PM -0700 Eric Rescorla
[EMAIL PROTECTED] wrote:
I agree that these specs should explicitly specify which TLS version
to support. As a practical matter, this is either 1.0 or 1.1, since
1.2 is not yet finished. Unfortunately, which one to require isn't
really
On Mon, 21 May 2007, Jeffrey Hutzelman wrote:
...
It seems to me that specs should _not_ explicitly specify which TLS version
to support, and should instead refer to an STD number. Applications don't
generally specify which verisons of IP or TCP to use, and TLS is at a similar
level of
The IESG has received a request from the Dynamic Host Configuration WG
(dhc) to consider the following document:
- 'DHCPv4 Relay Agent Flags Suboption '
draft-ietf-dhc-relay-agent-flags-03.txt as a Proposed Standard
The IESG plans to make a decision in the next few weeks, and solicits
final
The charter of the S/MIME Mail Security (smime) working group in the
Security Area of the IETF has been updated. For additional information,
please contact the Area Directors or the working group Chairs.
+++
S/MIME Mail Security (smime)
==
Currect Status: Active
All;
Based upon feedback received an adjustment was made in March of 2013.
Please advise if any further modification to the proposed IETF Meeting
schedule below is desired.
Thanks
Ray Pelletier
IAD
2011
16IETF 80Mar 27 - Apr 1
17IETF 81Jul 24 - 29
18IETF 82Nov
The IESG has approved the following document:
- 'ESS Update: Adding CertID Algorithm Agility '
draft-ietf-smime-escertid-06.txt as a Proposed Standard
This document is the product of the S/MIME Mail Security Working Group.
The IESG contact persons are Tim Polk and Sam Hartman.
A URL of
13 matches
Mail list logo
