headers
Brian E Carpenter | 1 Sep 04:32
Picon

Referrals - discussion and possible BOF

Hi,

Following the short discussion in the Stockholm BEHAVE
meeting, there is a proposed (not yet approved) BOF for
Hiroshima on the topic of a generic referral object.

Please see http://www.cs.auckland.ac.nz/~brian/GROBJ-BOF.txt
and if you want to discuss the topic, join the grobj <at> ietf.org
mailing list. We want to attract Applications Area discussion.

    Brian Carpenter
    (not subscribed to apps-discuss)
Permalink | Reply | 0 comments |
headers
Eliot Lear | 3 Sep 22:04
Picon
Favicon

anyone with deep mysql knowledge?

Dear all,

Does anyone know if there is an extension mechanism in MYSQL and whether
those extensions are detectable?  This has to do with an IANA port request.

Thanks in advance,

Eliot
Permalink | Reply | 2 comments |
headers
SM | 3 Sep 22:18

Re: anyone with deep mysql knowledge?

Hi Eliot,
At 13:04 03-09-2009, Eliot Lear wrote:
>Does anyone know if there is an extension mechanism in MYSQL and whether
>those extensions are detectable?  This has to do with an IANA port request.

If you mean protocol extensions, the answer is no.  Could you 
elaborate on what you mean by "extension" in relation to MySQL?

Regards,
-sm
Permalink | Reply | 1 comment |
headers
Eliot Lear | 4 Sep 07:44
Picon
Favicon

Re: anyone with deep mysql knowledge?

On 9/3/09 10:18 PM, SM wrote:
> Hi Eliot,
> At 13:04 03-09-2009, Eliot Lear wrote:
>> Does anyone know if there is an extension mechanism in MYSQL and whether
>> those extensions are detectable?  This has to do with an IANA port
>> request.
>
> If you mean protocol extensions, the answer is no.  Could you
> elaborate on what you mean by "extension" in relation to MySQL?

Just that.  Protocol extensions.

Thanks, SM.

ELiot
Permalink | Reply | 0 comments |
headers
Anthony Bryan | 8 Sep 03:44
Picon
Gravatar

Request for review of Metalink (XML for downloads) Internet Draft

We are seeking review of our Internet Draft.

http://tools.ietf.org/html/draft-bryan-metalink

Abstract

 This document specifies Metalink, an XML-based download description
 format.  Metalink describes alternate download locations (mirrors),
 checksums, and other information.  Clients can transparently use this
 information to reliably transfer files.

--

-- 
(( Anthony Bryan ... Metalink [ http://www.metalinker.org ]
  )) Easier, More Reliable, Self Healing Downloads
Permalink | Reply | 0 comments |
headers
YAO Jiankang | 9 Sep 03:36
Picon

Fw: I-D Action:draft-yao-ccn-ddds-00.txt



 Dear all,
 
     This is a draft about Chinese Common Name Mapping to URI (services) based on DDDS. It is similar to ENUM which
map E.164 number to URI (services) based on DDDS. This idea has been discussed in this list a few months ago.
It seems impossible to build a global Common Name mapping for all languages.
 we hope to seek to publish this draft as informational RFC or BCP RFC through individual submission. In
China, there are running a Keyword system similar to this. If there has a RFC in IETF about  this issue, it
will help the deployment of Chinese Common Name.
 
 any comments are welcome.
 
 thanks.
 
 
 Yao Jiankang
 CNNIC 
 
 

> ----- Original Message ----- 
> From: <Internet-Drafts <at> ietf.org>
> To: <i-d-announce <at> ietf.org>
> Sent: Tuesday, September 08, 2009 10:30 PM
> Subject: I-D Action:draft-yao-ccn-ddds-00.txt 
> 
> 
>>A New Internet-Draft is available from the on-line Internet-Drafts directories.
>>
(Continue reading)

Permalink | Reply | 0 comments |
headers
YAO Jiankang | 9 Sep 03:27
Picon

Fw: I-D Action:draft-yao-ccn-ddds-00.txt

Dear all,

     This is a draft about Chinese Common Name Mapping to URI (services) based on DDDS. It is similar to ENUM which
map E.164 number to URI (services) based on DDDS. This idea has been discussed in this list a few months ago.
It seems impossible to build a global Common Name mapping for all languages.
we hope to seek to publish this draft as informational RFC or BCP RFC through individual submission. In
China, there are running a Keyword system similar to this. If there has a RFC in IETF about  this issue, it
will help the deployment of Chinese Common Name.

any comments are welcome.

thanks.


Yao Jiankang
CNNIC 


Yao Jiankang
----- Original Message ----- 
From: <Internet-Drafts <at> ietf.org>
To: <i-d-announce <at> ietf.org>
Sent: Tuesday, September 08, 2009 10:30 PM
Subject: I-D Action:draft-yao-ccn-ddds-00.txt 


>A New Internet-Draft is available from the on-line Internet-Drafts directories.
> 
> Title           : Chinese Common Name to Uniform Resource Identifier(URI) Dynamic Delegation Discovery
System(DDDS) Application(CCN)
(Continue reading)

Permalink | Reply | 0 comments |
headers
Peter Saint-Andre | 10 Sep 20:48
Favicon

f* wildcards (was: [Fwd: Re: [VCARDDAV] AD review of draft-ietf-vcarddav-carddav-07.txt])


I just noticed this aspect of a message that Alexey sent to the vCard
list a few weeks ago. I tend to agree with what Alexey reports from a
recent IESG telechat, but I wonder if it will be codified somehow;
perhaps in the server identity checking I-D we've discussed here?

-------- Original Message --------
Subject: Re: [VCARDDAV] AD review of draft-ietf-vcarddav-carddav-07.txt
Date: Mon, 17 Aug 2009 00:02:08 +0100
From: Alexey Melnikov <alexey.melnikov <at> isode.com>
To: Cyrus Daboo <cyrus <at> daboo.name>
CC: CardDAV <vcarddav <at> ietf.org>
References: <4A888C37.50400 <at> isode.com>

<snip/>

3.  Requirements Overview

  o  MUST support secure transport as defined in [RFC2818] using TLS
     [RFC5246];

This recently came up in review of
draft-ietf-geopriv-http-location-delivery-15.txt:

RFC 2818, Section 3.1 says:

 Matching is performed using the matching rules specified by
 [RFC2459].  If more than one identity of a given type is present in
 the certificate (e.g., more than one dNSName name, a match in any one
 of the set is considered acceptable.) Names may contain the wildcard
(Continue reading)

Permalink | Reply | 2 comments |
headers
Alexey Melnikov | 10 Sep 22:47
Favicon

Re: f* wildcards (was: [Fwd: Re: [VCARDDAV] AD review of draft-ietf-vcarddav-carddav-07.txt])

Peter Saint-Andre wrote:

>-----BEGIN PGP SIGNED MESSAGE-----
>Hash: SHA1
>
>I just noticed this aspect of a message that Alexey sent to the vCard
>list a few weeks ago. I tend to agree with what Alexey reports from a
>recent IESG telechat, but I wonder if it will be codified somehow;
>perhaps in the server identity checking I-D we've discussed here?
>  
>
Yes.

>- -------- Original Message --------
>Subject: Re: [VCARDDAV] AD review of draft-ietf-vcarddav-carddav-07.txt
>Date: Mon, 17 Aug 2009 00:02:08 +0100
>From: Alexey Melnikov <alexey.melnikov <at> isode.com>
>To: Cyrus Daboo <cyrus <at> daboo.name>
>CC: CardDAV <vcarddav <at> ietf.org>
>References: <4A888C37.50400 <at> isode.com>
>
><snip/>
>
>3.  Requirements Overview
>
>  o  MUST support secure transport as defined in [RFC2818] using TLS
>     [RFC5246];
>
>This recently came up in review of
>draft-ietf-geopriv-http-location-delivery-15.txt:
(Continue reading)

Permalink | Reply | 1 comment |
headers
Peter Saint-Andre | 10 Sep 23:39
Favicon

Re: f* wildcards


On 9/10/09 2:47 PM, Alexey Melnikov wrote:
> Peter Saint-Andre wrote:
> 
>> -----BEGIN PGP SIGNED MESSAGE-----
>> Hash: SHA1
>>
>> I just noticed this aspect of a message that Alexey sent to the vCard
>> list a few weeks ago. I tend to agree with what Alexey reports from a
>> recent IESG telechat, but I wonder if it will be codified somehow;
>> perhaps in the server identity checking I-D we've discussed here?
>>  
>>
> Yes.

Works for me.

This will be in version -02 of draft-saintandre-tls-server-id-check.

Peter

--
Peter Saint-Andre
https://stpeter.im/
Permalink | Reply | 0 comments |

Gmane