> > The behavior of other URL methods is not currently specified, so > > such methods SHOULD NOT be used in the absence of a Standards Track > > document defining them. > > This addition is ok for me, altough I do not think we need to have > *Standard Track* documents to be able to use, I would just say "in the > absens of document defining them". I think having information RFC > telling how to use ftp URLs should be ok, especially as some people > might be against making such document standard track document.
I agree. As an aside, I would expect any such document not only to loosely specify the behavior of https or ftp URLs (for example), but also to introduce new notify types such as HTTPS_CERT_LOOKUP_SUPPORTED and FTP_CERT_LOOKUP_SUPPORTED. Scott Moonen (smoo...@us.ibm.com) z/OS Communications Server TCP/IP Development http://www.linkedin.com/in/smoonen From: Tero Kivinen <kivi...@iki.fi> To: Yaron Sheffer <yar...@checkpoint.com> Cc: IPsecme WG <ipsec@ietf.org>, Yoav Nir <y...@checkpoint.com>, Paul Hoffman <paul.hoff...@vpnc.org> Date: 11/25/2009 10:25 AM Subject: Re: [IPsec] #117: Hash and URL interop Yaron Sheffer writes: > Can you live with: > > Implementations MUST support HTTP. This is already in the RFC4306. > The behavior of other URL methods is not currently specified, so > such methods SHOULD NOT be used in the absence of a Standards Track > document defining them. This addition is ok for me, altough I do not think we need to have *Standard Track* documents to be able to use, I would just say "in the absens of document defining them". I think having information RFC telling how to use ftp URLs should be ok, especially as some people might be against making such document standard track document. -- kivi...@iki.fi _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
_______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
