http://permalink.gmane.org/gmane.ietf.message-headers hourly 1 1901-01-01T00:00+00:00 http://gmane.org/img/gmane-25t.png http://gmane.org http://permalink.gmane.org/gmane.ietf.message-headers/93 On Thu, 25 Sep 2008 12:13:03 +0200, Julian Reschke <julian.reschke< at >gmx.de> wrote: Done. Anne van Kesteren 2008-10-08T09:51:26 http://permalink.gmane.org/gmane.ietf.message-headers/92 Hi, Here is the registration template (inlined) for headers the W3C Web Applications WG would like to provisionally register. (Previously the W3C Web Application Formats WG worked on this draft.) Since last time the header names have changed and some headers have been removed and added, but the overall idea is still the same. === Header field names: Access-Control-Allow-Origin (response header) Access-Control-Max-Age (response header) Access-Control-Allow-Credentials (response header) Access-Control-Allow-Methods (response header) Access-Control-Allow-Headers (response header) Origin (request header) Access-Control-Request-Method (request header) Access-Control-Request-Headers (request header) Applicable protocol: http Status: provisional Author/Change controller: W3C Web Applications Working Group http://www.w3.org/2008/webapps/ Specification documents: http://www.w3.org/TR/access-control/ (Working Draft) http://dev.w3.org/2006/waf/access-control/ (Editor's draft) === I will submit the above t Anne van Kesteren 2008-10-08T09:46:20 http://permalink.gmane.org/gmane.ietf.message-headers/91 AvK wrote back in January: > Based on feedback we renamed Method-Check-Expires to > Method-Check-Max-Age and instead of an HTTP-date it now takes > delta-seconds (RFC 2616). > > http://dev.w3.org/2006/waf/access-control/ > > > Can I simply e-mail IANA with this update or shall we go for > another two weeks review here? I'm good either way :-) If headers that we previously registered aren't needed anymore, then yes, you should tell IANA about it so that the registry can be cleaned up (<http://tools.ietf.org/html/rfc3864#section-4.5>). BR, Julian Julian Reschke 2008-09-25T10:13:03 http://permalink.gmane.org/gmane.ietf.message-headers/90 Confirmation of list posting -- confirmation ID: E1K3a4SMN-TQ The ietf.org mailing-list server has received a list posting from gim-ietf-message-headers< at >m.gmane.org to ietf-message-headers< at >ietf.org with the subject 'Re: For review: Original-Recipient' As the sender address isn't subscribed to the list, and has not been confirmed earlier, we have to request a confirmation of the address. To confirm the address, send a message to ietf-message-headers< at >ietf.org, with the same subject line as this message. (Simply sending a 'reply' to this message should work from most email interfaces, since that usually leaves the subject line in the right form. The reply's additional "Re:" is ok.) If you do not wish your posting to the list to go through, simply disregard this message. Questions to postmaster< at >ietf.org. ietf-message-headers< at >ietf.org 2008-09-07T07:10:05 http://permalink.gmane.org/gmane.ietf.message-headers/88 Header field name: Auto-Submitted Applicable protocol: mail Status: standard Author/Change controller: IETF Specification document: RFC 3834 Will send to IANA in 2 weeks barring objections. pr Pete Resnick 2008-07-10T00:37:10 http://permalink.gmane.org/gmane.ietf.message-headers/85 Test mail - please ignore if it turns out to be a dupe. The From: address is "unidirectional" (sent from a Webmail interface where I can't set a working Reply-To address, sorry). http://gmane.org/list-address.php?group=gmane.ietf.message-headers shows still the old < at >lists.ietf address, and the claranet.de Webmail tells me that this doesn't work, therefore I test now the new < at >ietf address. ---------------------------------------------------------------------------------- Hi, when draft-eai-dsn got its number it is time to add Original-Recipient to the registry. Bruce has this in draft-lilly-legacy-fields-00, but his I-D didn't move for three years. The Original-Recipient is not really a "legacy" field, it is only "unregistered". Frank ----------------------------------------------------- PERMANENT MESSAGE HEADER FIELD REGISTRATION TEMPLATE: Header field name: Original-Recipient Applicable protocol: mail Status: standard Author/Change controller: IETF Specification do xyzzy< at >claranet.de 2008-04-17T00:37:14 http://permalink.gmane.org/gmane.ietf.message-headers/84 On Sun, 27 Jan 2008 01:37:59 +0100, Anne van Kesteren <annevk< at >opera.com> wrote: The same goes for adding a new header defined by the same specification: Method-Check-Policy-Path Anne van Kesteren 2008-02-06T16:23:44 http://permalink.gmane.org/gmane.ietf.message-headers/83 Hi, Based on feedback we renamed Method-Check-Expires to Method-Check-Max-Age and instead of an HTTP-date it now takes delta-seconds (RFC 2616). http://dev.w3.org/2006/waf/access-control/ Can I simply e-mail IANA with this update or shall we go for another two weeks review here? I'm good either way :-) By the way, thanks for the help before in getting the headers provisionally registered, all worked out: http://iana.org/assignments/message-headers/prov-headers.html Kind regards, Anne van Kesteren 2008-01-27T00:37:59 http://permalink.gmane.org/gmane.ietf.message-headers/82 OE claims you wrote nothing, phhhtt... fetching MIME part: Yes, but a provisional registration based on an expired draft is "suboptimal", a permanent registration based on *some kind of public standard* (not necessarily an RFC) is better. My "marauder's map for the IETF labyrinth" (aka Brian's procdoc ION) indicates that XMPP is an SDO with some kind of IETF liaison, an "XEP" might be good enough. Okay, if Graham is no Harry Potter or XMPP fan you need an RFC :-) Maybe discuss it with the XMPP community or XMPP Council or whatever it takes - the SPF organization is far simpler, we have only one RFC to guard, or four counting those that we never wanted. If nobody needs the header field anymore don't waste time with it. Good, and what I had in mind doesn't exist anymore, better. Frank Frank Ellermann 2008-01-03T17:04:17 http://permalink.gmane.org/gmane.ietf.message-headers/81 Peter Saint-Andre 2008-01-03T15:50:21 http://permalink.gmane.org/gmane.ietf.message-headers/80 [...] IMO the Jabber-ID header field makes sense, it has a modern syntax, and might be better than attaching a complete vCard to a message: Apparently the optional "profile" associated with a JID is more or less the same as a vCard. The Last Called Jabber-ID draft (you have already fixed a minor FWS issue) only needs IESG approval and an RFC number. Whatever backchamber conspiracy "persuaded" you to "withdraw" it - but if it was the "DEA directorate" I'll scream. Frank Frank Ellermann 2008-01-03T04:51:13 http://permalink.gmane.org/gmane.ietf.message-headers/79 Peter Saint-Andre 2008-01-02T21:29:52 http://permalink.gmane.org/gmane.ietf.message-headers/78 You may have missed my point, which is precisely that using an address book or other repository which can be easily updated via VCards (or LDAP, etc.) is much more likely to yield results quickly as opposed to convincing software authors to support special-purpose code to extract unrelated data from message header fields, waiting for such special-purpose code to be written, waiting for users to upgrade, etc. Bruce Lilly 2008-01-02T21:19:10 http://permalink.gmane.org/gmane.ietf.message-headers/77 Peter Saint-Andre 2008-01-02T16:34:38 http://permalink.gmane.org/gmane.ietf.message-headers/76 N.B. replies directed to the ietf-message-headers [sic] mailing list. On Tuesday 06 November 2007 15:03:13 Peter Saint-Andre wrote: You're getting decades ahead of yourself -- see below. ...and telnet and SIP and http... Are we to see additional drafts for schemes to cram this information into telnet sessions, web site traffic, telephone calls, etc.? Or maybe you'd like to add options to send that information in every IP packet...:-) On Tuesday 06 November 2007 16:58:23 Peter Saint-Andre wrote: With the proposed scheme, you would need to: 1. convince message authors to include such information via your scheme instead of or in addition to other mechanisms. 2. convince the authors of all MUAs used by those authors to support your scheme (so that the authors CAN include it per #1) 3. convince the authors of your MUA to support your scheme on your platform of choice (ask Frank about support for OS/2...) 4. wait a decade or two for users to upgrade to the revised versions of MUAs ...and it sti Bruce Lilly 2008-01-02T01:57:15 http://permalink.gmane.org/gmane.ietf.message-headers/75 Sorry for very delayed response -- this message got 'filed' in one of those dusty corners I only look into occasionally... Anne van Kesteren wrote: Not so much an exact requirement, but I would expect the general quality of specification to be comparable with that for any standard - sufficient for creating interoperable implementations, etc. For provisional registrations, a more general statement of intent can suffice. #g Graham Klyne 2007-12-20T23:34:13 http://permalink.gmane.org/gmane.ietf.message-headers/73 Peter Saint-Andre 2007-11-26T23:11:47 http://permalink.gmane.org/gmane.ietf.message-headers/69 IMO the im/pres I-Ds are on "DNP track". xmpp: offers full I18N, Peter mentioned that only xmpp: bothered to get im/pres registry entries, I vaguely recall that xmpp: also supports SIP somehow, and the new I-D.saintandre-jabberid-07 is ready for publication. IANA knows how to create two header field registry entries for two protocols. I think it should be a "permanent" header field: | The assignment policy for such registration is "Specification | Required", as defined by RFC 2434 [3], where the specification | must be published in an RFC (standards-track, experimental, | informational or historic), or as an "Open Standard" in the | sense of RFC 2026, section 7 [1]. Note "informational" => good enough for "permanent". I don't see why this needs "Author/Change controller: XMPP Registrar", the underlying xmpp: URI RFCs are anyway controlled by the IETF. For Received-SPF we switched from "SPF Council" to "IETF" after deciding to go for PS instead of "experimental", and after the IESG flipped draft-sc Frank Ellermann 2007-11-08T19:23:06 http://permalink.gmane.org/gmane.ietf.message-headers/67 Peter Saint-Andre 2007-11-08T16:01:58 http://permalink.gmane.org/gmane.ietf.message-headers/66 A contact can be a channel of communication. In the case of your drafts, it's a channel which can be associated with a URI. If you find the header name inappropriate, you can invent another term for it. The pres: URI provides a means to retrieve presence information. It's indirectly a means of contact. Regards, -sm SM 2007-11-08T14:33:35 http://permalink.gmane.org/gmane.ietf.message-headers/65 Peter Saint-Andre 2007-11-07T23:49:05 Search the mailing list at Gmane query http://search.gmane.org/?group=$group=gmane.ietf.message-headers