___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf
--
#-# Martin J. Dürst, Professor, Aoyama Gakuin University
#-# http://www.sw.it.aoyama.ac.jp mailto:due...@it.aoyama.ac.jp
___
Ietf mailing list
Ietf
jabber support (both scribing and picking up
questions/comments) for the plenary? Was this just never considered, or
has it been considered and rejected?
Regards,Martin.
--
#-# Martin J. Dürst, Professor, Aoyama Gakuin University
#-# http://www.sw.it.aoyama.ac.jp mailto:due...@it.aoyama.ac.jp
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf
--
#-# Martin J. Dürst, Professor, Aoyama Gakuin University
#-# http://www.sw.it.aoyama.ac.jp mailto:due...@it.aoyama.ac.jp
___
Ietf mailing list
Ietf@ietf.org
it
doesn't apply here, because the spec says to ignore any from= in the
URI. If yes, can you supply actual text?
Regards,Martin.
--
#-# Martin J. Dürst, Professor, Aoyama Gakuin University
#-# http://www.sw.it.aoyama.ac.jp mailto:due...@it.aoyama.ac.jp
://www.nlnetlabs.nl/ 1098 XG Amsterdam
--
Mark Nottingham http://www.mnot.net/
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf
--
#-# Martin J. Dürst, Professor, Aoyama Gakuin University
#-# http
://www.ietf.org/mailman/listinfo/ietf-announce
--
#-# Martin J. Dürst, Professor, Aoyama Gakuin University
#-# http://www.sw.it.aoyama.ac.jp mailto:due...@it.aoyama.ac.jp
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf
.
___
IETF-Announce mailing list
ietf-annou...@ietf.org
https://www.ietf.org/mailman/listinfo/ietf-announce
--
#-# Martin J. Dürst, Professor, Aoyama Gakuin University
#-# http://www.sw.it.aoyama.ac.jp mailto:due...@it.aoyama.ac.jp
___
Ietf
Hello everybody,
[For replies, please trim the cc list, thanks!]
I have been selected as the Applications Area Directorate reviewer for
this draft (for background on appsdir, please see
http://trac.tools.ietf.org/area/app/trac/wiki/ApplicationsAreaDirectorate ).
Please resolve these
.
On 06/05/2012 10:42 AM, Martin J. Dürst wrote:
Minor editorial issues:
Introduction: It would be good to have a general reference to hashing
(for security purposes) for people not utterly familiar with the subject.
Disagree. If I added that I could reasonably be asked to introduce
URIs
Hello Stephen,
This mail responds to your points on the main technical issue that I
have identified.
On 2012/06/05 20:11, Stephen Farrell wrote:
On 06/05/2012 10:42 AM, Martin J. Dürst wrote:
Hello everybody,
[For replies, please trim the cc list, thanks!]
Done, removed apps-disc
Hello Stephen, others,
On 2012/06/08 20:21, Stephen Farrell wrote:
Hiya,
On 06/08/2012 01:35 AM, Jonathan A Rees wrote:
On Thu, Jun 7, 2012 at 3:15 PM, Stephen Farrell
stephen.farr...@cs.tcd.ie wrote:
On 06/06/2012 09:33 PM, Jonathan A Rees wrote:
-- Forwarded message
Hello Stephen,
On 2012/06/09 10:45, Stephen Farrell wrote:
On 06/09/2012 01:43 AM, Sam Hartman wrote:
It's a naming
hierarchy. My main concern is whether the relative reference algorithm
described in section 5/4.2 of RFC 3986. In particular take a look at the
last part of section 1.2 of
Hello Stephen,
On 2012/06/09 22:24, Stephen Farrell wrote:
Hi Björn,
On 06/08/2012 03:16 AM, Bjoern Hoehrmann wrote:
I think the requirement in RFC 4395 section 2.6 applies here, there are
text fields in 'ni' and 'nih' addresses, so there needs to be some dis-
cussion about I18N and IRI
Hello Stephen,
On 2012/06/12 18:59, Stephen Farrell wrote:
Hi Martin,
On 06/12/2012 10:13 AM, Martin J. Dürst wrote:
Hello Stephen,
This mail responds to your points on the main technical issue that I
have identified.
On 2012/06/05 20:11, Stephen Farrell wrote:
On 06/05/2012 10:42 AM
Hello Stephen,
On 2012/06/12 20:08, Stephen Farrell wrote:
So would it work to add this:
Note that relative ni URIs can occur, for example as shown in
Figure 5. In such cases, user agents MUST construct the absolute URI
as they would in the case of an HTTP URL, that is, in the
Hello Thomas, others,
On 2012/06/13 21:48, Thomas Narten wrote:
Maybe an IESG statement on this respect can help here.
Is the existing text in RFC 5226 not sufficient? It contains extensive
text about the purpose and role of designated experts, and was revised
substantially the last time
Hello Stephen,
On 2012/06/17 22:33, Stephen Farrell wrote:
Martin,
On 06/17/2012 01:55 PM, Martin J. Dürst wrote:
This time, the situation was somewhat reversed: The expert approved the
registration, and this fact was then used as a claim that IETF Last Call
comments on the item registered
Hello Stephen, others,
On 2012/06/23 6:20, Stephen Farrell wrote:
Hi All,
I went back through the IETF LC comments and think that we've
resolved them all on the list and have the changes in this
version [1] of the draft, with the possible exception of those
below.
The issues raised but not
Hello Stephen,
On 2012/06/25 21:05, Stephen Farrell wrote:
On 06/25/2012 11:35 AM, Martin J. Dürst wrote:
Unfortunately, what I find is the following:
The justification for using a URI scheme for this is that that might
help a user agent for the speaker to better display the value
Hello Stephen,
On 2012/06/26 20:26, Stephen Farrell wrote:
Hi again Martin,
On 06/26/2012 12:11 PM, Martin J. Dürst wrote:
So the question is really, what's the use case, and what's just a
consequence of that use case. If confirmation of already available
resources (e.g. like a fingerprint
I have read this document, and based on my experience with mailing lists
both at the IETF and the W3C, it is adequate. I sincerely hope that
support for Archived-At message header fields will be provided, because
this can be extremely convenient to quickly reference a message in
communication
Hello Barry,
Thanks for explanation about errata, which must have been caused at
least in part by an erratum that I submitted recently.
Just for the record, I want to mention that the errata report form at
http://www.rfc-editor.org/errata_report.php has a type field with two
categories,
One of the advantages of a standards organization such as the IETF is
cross-concern review. For the IETF, one very strong cross-concern is
security. Another one (also for my personally) is internationalization.
Another, more vague one, is general architecture. Early running code is
very often
On 2012/12/03 23:38, Elwyn Davies wrote:
Given that there is also open source code, reviewers have the chance to
take a look at that and see the degree of hackiness involved.
Well, yes. It's easy enough to evaluate stuff such as non-descriptive
variable names, messy indenting, and weird
Hello Barry,
On 2013/07/04 9:39, Barry Leiba wrote:
Registration for IETF87 in Berlin has been suspended to consider the impact
of a change in the VAT rules on Registration Fees. We expect registration
to open as soon as this matter has been clarified.
I don't understand what the effect of
For the benefits of those (few and far between) IETF participants that
haven't memorized all RFC numbers, it would be great if announcement
such as the one below would contain a tiny bit more information about
the document itself.
E.g. just having the title of the document in announcement
26 matches
Mail list logo
