headers
Spencer Dawkins | 1 Mar 2008 06:04

Re: Gen-ART Review of draft-ietf-smime-sha2-03.txt

Hi, Sean,

This is much better than I feared. There were just too many places in -03 
where I was guessing what was intended, for me to say "ready for 
publication", or even "almost ready with nits".

I know you don't make the decisions about when drafts are last-called, but 
when you talk to your shepherd, you might suggest looking at diffs for the 
version posted for last call. that popped up a lot of the concerns i had 
(which were also concerns that denis had).

Best wishes with the draft.

Spencer

> Spencer,
>
> Thanks for taking the time to read the draft. Responses are inline.
>
> spt
>
>>-----Original Message-----
>>From: Spencer Dawkins [mailto:spencer <at> wonderhamster.org]
>>Sent: Friday, February 29, 2008 12:27 AM
>>To: General Area Review Team
>>Cc: Sean Turner; Blake Ramsdell; ietf <at> ietf.org; tim.polk <at> nist.gov
>>Subject: Gen-ART Review of draft-ietf-smime-sha2-03.txt
>>
>>I have been selected as the General Area Review Team (Gen-ART)
>>reviewer for this draft (for background on Gen-ART, please see
(Continue reading)

Permalink | Reply | 0 comments |
headers
Joel Jaeggli | 1 Mar 2008 06:12

Audio Streaming - IETF 71 Philadelphia, PA, USA 9-14 March 2008

Greetings,

All 8 parallel tracks will be broadcast starting with the
commencement of working group sessions on Monday March 10 at 0900
EST (UTC-5) and continue until Friday at 1130 EST. Additionally it is
our intention to broadcast the IEPG meeting occurring on Sunday the 9th
starting at 1000 EST.

Because I have been asked several times in the past, note that if you
wish to use the rooms that are being recorded for impromptu meeting
during unscheduled sessions or lunch breaks that you can invite remote
participants to tune in to the appropriate stream. Recording cannot be
guaranteed for unscheduled sessions. Conversely, it should never be
assumed that recording or observation is not occurring on open
microphones, they are after all connected to the Internet.

The links for streaming sources and the schedule will be available
thanks to the continued support of the Network Startup Resource Center
in their traditional location:

http://videolab.uoregon.edu/events/ietf/

I Look forward to seeing some of you in Philadelphia and hope that this
facility remains useful for remote participants in and observers of the
IETF Process.

Regards
Joel Jaeggli
Permalink | Reply | 0 comments |
headers
Tony Finch | 2 Mar 2008 21:50
Picon
Favicon

draft-duerst-iana-namespace-00.txt

The latest RISKS gibes an example of the magnitude of the problem of
unwanted traffic caused by using URLs instead of URNs for protocol
identification URIs. Perhaps the security considerations section of the
draft should describe some ways of mitigating it?

http://catless.ncl.ac.uk/Risks/25.07.html#subj9

Tony.
--

-- 
f.a.n.finch  <dot <at> dotat.at>  http://dotat.at/
TYNE DOGGER FISHER GERMAN BIGHT HUMBER THAMES: WESTERLY 6 TO GALE 8. ROUGH OR
VERY ROUGH. SQUALLY WINTRY SHOWERS. MODERATE OR GOOD.
Permalink | Reply | 16 comments |
headers
Julian Reschke | 2 Mar 2008 21:54
Picon
Picon

Re: draft-duerst-iana-namespace-00.txt

Tony Finch wrote:
> The latest RISKS gibes an example of the magnitude of the problem of
> unwanted traffic caused by using URLs instead of URNs for protocol
> identification URIs. Perhaps the security considerations section of the
> draft should describe some ways of mitigating it?
> 
> http://catless.ncl.ac.uk/Risks/25.07.html#subj9
> 
> Tony.

I think this is a misunderstanding.

The URI of a DTD is needed to fetch the DTD. The W3C suffers from 
clients that refetch the DTD all the time.

Contrary to that, XML processors do not resolve namespace URIs, they are 
purely used as identifiers.

BR, Julian
Permalink | Reply | 6 comments |
headers
Ned Freed | 3 Mar 2008 00:23

Re: draft-duerst-iana-namespace-00.txt

> Tony Finch wrote:
> > The latest RISKS gibes an example of the magnitude of the problem of
> > unwanted traffic caused by using URLs instead of URNs for protocol
> > identification URIs. Perhaps the security considerations section of the
> > draft should describe some ways of mitigating it?
> >
> > http://catless.ncl.ac.uk/Risks/25.07.html#subj9
> >
> > Tony.

> I think this is a misunderstanding.

> The URI of a DTD is needed to fetch the DTD. The W3C suffers from
> clients that refetch the DTD all the time.

> Contrary to that, XML processors do not resolve namespace URIs, they are
> purely used as identifiers.

That's certainly how things are supposed to work. It may or may not be how they
actually work.

Some years back one of my email addresses ended up in a few of the headers of a
MIME test message corpus. This corpus isn't part of any standard and was never
widely promoted, and there's no obvious path by which an address in a test
message header would or should be replied to. Yet the fact remains that over
the years I've received hundreds of bogus responses as a result of this
inclusion.

The bottom line is that if something is syntactically usable people will screw
up and use it; the only question is how often. For example, I could easily see
(Continue reading)

Permalink | Reply | 5 comments |
headers
Tim Bray | 3 Mar 2008 02:49
Favicon
Gravatar

Re: draft-duerst-iana-namespace-00.txt

On Sun, Mar 2, 2008 at 3:23 PM, Ned Freed <ned.freed <at> mrochek.com> wrote:
>  > Contrary to that, XML processors do not resolve namespace URIs, they are
>  > purely used as identifiers.
>
>  That's certainly how things are supposed to work. It may or may not be how they
>  actually work.

I agree with Ned that the Security considerations or some other piece
of the doc should explicitly cover this issue.  -Tim
Permalink | Reply | 4 comments |
headers
Dan Karp | 3 Mar 2008 08:07
Favicon

Re: Last Call: draft-ietf-imapext-sort (INTERNET MESSAGE ACCESS PROTOCOL - SORT AND THREAD EXTENSIONS) to Proposed Standard


Let's step back for a moment.

The purpose of sorting in mail clients is so that users can find
messages they're looking for.

After sorting on INTERNALDATE, the user skips down the "Received" column
to the range that their target messages fall in.  And, voila!  The
messages are there.

After sorting on SUBJECT, the user skips through the results to the set
of messages with the correct normalized subject.  This works because the
user mentally normalizes the Subject header in the same way that the
SORT extension does.  (The transform's easy to do, and years of mail
client use have trained them to do this; they're not looking under 'R'
for "re: Your Brains".)  And, voila!  They find the messages.

But sorting on FROM?  That's where things break down for the draft.

I took a look at 7 different mail clients: Gmail, mutt, Outlook Express,
PC-Pine, Thunderbird, Yahoo! Mail, and Zimbra.  In every single one of
these clients, there is a list of mail messages.  And in that list,
every client has a "From" column.  And every one of those "From" columns
contains the RFC2822 display-name of the From header of the relevant
message, or the RFC2822 addr-spec if there's no display-name.  Every
single one.

Gmail ("search, not sort") doesn't allow you to sort on "From".  But
every other client offers a "From" sort.  And every client *but* PC-Pine
does it exactly the same way: A straight text sort on the data displayed
(Continue reading)

Permalink | Reply | 16 comments |
headers
Mark Crispin | 3 Mar 2008 08:53
Favicon

Re: Last Call: draft-ietf-imapext-sort (INTERNET MESSAGE ACCESS PROTOCOL - SORT AND THREAD EXTENSIONS) to Proposed Standard


On Sun, 2 Mar 2008, Dan Karp wrote:
> Once the draft makes it to Proposed Standard, getting a second draft out
> with a variant version of these sorts becomes exponentially harder.

When there is both a de facto standard that has existed for over 10 years, 
and a completely incompatible de jure standard created because some guy 
didn't like the de facto standard, then getting any standard becomes 
impossible.

The SORT specification is infinitely extensible.  The original keys are 
there, and remain there forever.  However, nothing prevents the creation 
of FROM2, FROM.PLUS, ZIMBRAFROM, etc. as extensions to the keys.  That is, 
all new forms of SORT would be a superset.

The only thing that a client need concern itself about with a server is if 
the server implements (at least) the SORT level it desires.  If the client 
just cares about the original, 10+ year old, keys, then any server SORT 
will work, because all SORT is a superset of the original.

Should you get your way, there would be now two incompatible sets of keys. 
There would be the set that has been around for more than a decade, and 
the new incompatible set that *subsets* the original set instead of 
*supersets* it.

Clients would have to know which set is implemented by the server.  If the 
server implements the wrong set, then the client will have to do all the 
work in the client.  The end result is sufficient fear, uncertainty, and 
doubt that nobody will use server-based SORT at all.
(Continue reading)

Permalink | Reply | 0 comments |
headers
Julian Reschke | 3 Mar 2008 09:05
Picon
Picon

Re: draft-duerst-iana-namespace-00.txt

Tim Bray wrote:
> On Sun, Mar 2, 2008 at 3:23 PM, Ned Freed <ned.freed <at> mrochek.com> wrote:
>>  > Contrary to that, XML processors do not resolve namespace URIs, they are
>>  > purely used as identifiers.
>>
>>  That's certainly how things are supposed to work. It may or may not be how they
>>  actually work.
> 
> I agree with Ned that the Security considerations or some other piece
> of the doc should explicitly cover this issue.  -Tim

In the meantime, one could ask the W3C whether they see a lot of traffic 
on popular namespace URIs, such as XHTML, XSLT or Atom.

BR, Julian
Permalink | Reply | 3 comments |
headers
Iljitsch van Beijnum | 3 Mar 2008 11:12
Favicon

Re: IPv6 <at> IETF-71, especially Jabber

On 29 feb 2008, at 15:34, Iljitsch van Beijnum wrote:

> What's going on with the preparations to turn off IPv4 at IETF-71?
> It's been really quiet surrounding that topic since the initial
> discussion.

It's good to hear that work is going on behind the scenes.

> So... does anyone know a place to obtain a Jabber account that's
> usable over IPv6? I assumed psg.com would be a good candidate, but
> even though psg.com has a AAAA record, jabber.psg.com doesn't.

I've had a couple of offers in private email (thanks for those!) but  
I've decided to go into another direction with this, and set up a  
transport relay translator (RFC3142) on a FreeBSD server. This is a  
combination special network interface and a daemon that listens on an  
IPv6 TCP port and forwards the session to the IPv4 destination encoded  
in the low bits of the IPv6 address. See the faithd man page

For the next two weeks, the translator will be open for everyone on  
prefix 2001:1af8:5:f::/96 on ports 5222 and 5223. So if, like me, you  
use Google Talk for Jabber you can connect to 2001:1af8:5:f:: 
209.85.137.125 (or 2001:1af8:5:f::d155:897d) rather than  
209.85.137.125. (Replace the IPv4 bits with that of your Jabber server  
if you use another Jabber server.) This has of course the slight  
downside that you can only use Jabber when you have IPv6 connectivity.  
I fixed this by setting up a hostname that has both the translated  
address and the normal address: googletalk.runningipv6.net.

A side effect is that the SSL certificate now doesn't match the
(Continue reading)

Permalink | Reply | 0 comments |

Gmane