Re: Last Call: draft-allbery-afs-srv-records (DNS SRV Resource Records for AFS) to Proposed Standard
Hi, --On January 8, 2010 7:28:51 AM -0800 The IESG wrote: The IESG has received a request from an individual submitter to consider the following document: - 'DNS SRV Resource Records for AFS ' as a Proposed Standard This spec needs to wait on the IANA SRV registry document (draft-ietf-tsvwg-iana-ports) that is being revised and also blocking a couple of SRV-related drafts I have been working on too. Once that is done it should register its new services using the new procedure. -- Cyrus Daboo ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Last Call: draft-daboo-srv-caldav (Use of SRV records for locating CalDAV and CardDAV services) to Proposed Standard
Hi Patrik, --On June 23, 2010 8:52:45 PM +0200 Patrik Fältström wrote: In principle, example.com is the proper domain to authenticate, but in practice, that causes a lot of problems. Consider the case where the target of the redirection is a separate entity from the origin; this could arise, for example, in a situation whereexample.com has outsourced its calendaring services to calendardserverfoobar.com. So, the "connect the dots" is to: - Announce the fact example.com is hosted at calendarserverfoobar.com (with some URL) in DNS - Secure that announcement in DNS with DNSSEC - Verify the SSL (for example) cert for the connection to calendarserverfoobar.com matches So the srv-caldav (and srv-email) drafts reference Section 3 of draft-saintandre-tls-server-id-check which describes how clients can go about verifying a server identity when using TLS under various circumstances, including an initial discovery via SRV records. - Do application layer authentication etc over the then encrypted connection Sounds ok? Well the key here is DNSSEC of course! -- Cyrus Daboo ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Last Call: draft-daboo-srv-caldav (Use of SRV records for locating CalDAV and CardDAV services) to Proposed Standard
Hi Patrik, --On June 22, 2010 8:54:22 AM +0200 Patrik Fältström wrote: I have together with Olaf Kolkman suggested a new RR type that I call URI that work similarly to what is described in this draft (regarding the owner of the RRSET), but a URI in the RDATA. It has been posted to the namedroppers list a few times...but maybe that has been wrong. Maybe Apps Area should have been notified about the work a bit more... Cyrus has asked a few questions about it, and maybe it is me that have not reached out to the Caldav people enough? I have tried to push it through via the DNS people in the IETF, but there have not been enough traction. I did chat with a few server implementors about this and the feeling was SRV + .well-known is a good solution that can quickly be deployed. Some points: 1) SRV's are very deployable today - a new RR will be harder to deploy. 2) There is a push to support SRV's with other protocols (e.g. draft-daboo-srv-email for IMAP, POP3, and Submission) so from an operational standpoint its likely to be more common. 3) .well-known is useful in the absence of any DNS records. i.e. if no SRV/URI were available, a client can still try auto-discovery by attempting an HTTP connection to the host (derived from user input) and the .well-known path. -- Cyrus Daboo ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Last Call: draft-daboo-srv-caldav (Use of SRV records for locating CalDAV and CardDAV services) to Proposed Standard
Hi Patrik, --On June 23, 2010 10:07:44 PM +0200 Patrik Fältström wrote: I did chat with a few server implementors about this and the feeling was SRV + .well-known is a good solution that can quickly be deployed. Some points: 1) SRV's are very deployable today - a new RR will be harder to deploy. 2) There is a push to support SRV's with other protocols (e.g. draft-daboo-srv-email for IMAP, POP3, and Submission) so from an operational standpoint its likely to be more common. 3) .well-known is useful in the absence of any DNS records. i.e. if no SRV/URI were available, a client can still try auto-discovery by attempting an HTTP connection to the host (derived from user input) and the .well-known path. Hmm...regarding the new RR, the only thing I can think of today is the need for some changes in the provisioning system from which one create the DNS zones. I do not know of any DNS code today that can not handle "unknown" DNS RR Types, but maybe I am wrong? I am though confused over (1) as this is 2010 and not 1998. I am thinking more of client APIs. Regarding (3), I think it is sad people move redirects and lookups and functionality to be on top of HTTP instead of IP. And I do not understand "in the absence of DNS"...that is an interesting situation ;-) Specifically to use that as the foundation for the architecture to use for calendaring, that is -- I hope -- one of the more fundamental applications on the Internet. Sorry - bad wording on my part. What I meant was "in the absence of a service-type to hostname mapping in the DNS". -- Cyrus Daboo ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Last Call: draft-daboo-srv-caldav (Use of SRV records for locating CalDAV and CardDAV services) to Proposed Standard
Hi Paul, --On June 24, 2010 8:59:18 AM -0700 Paul Hoffman wrote: As someone who normally has that "different view", I support a new RRTYPE in this case because the option of reusing SRV is not sufficient: it requires DNS-SRV-followed-by-HTTP. I think a new RRTYPE that keeps the DNS lookup entirely in the DNS protocol far outweighs reusing SRV but requiring HTTP on both sides. "in this case" as in the draft under discussion? If so, I don't don't understand your position. The protocols/services being referenced by the draft are HTTP protocols, so it is always going to be SRV-followed-by-HTTP. What is more, simply getting a generic host/path is not sufficient for client configuration - additional steps are required to find the principal resource of the user for whom the client is setting up an "account" (as described in the draft). -- Cyrus Daboo ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Last Call: draft-daboo-srv-caldav (Use of SRV records for locating CalDAV and CardDAV services) to Proposed Standard
Hi Patrik, --On June 24, 2010 6:32:48 PM +0200 Patrik Fältström wrote: "in this case" as in the draft under discussion? If so, I don't don't understand your position. The protocols/services being referenced by the draft are HTTP protocols, so it is always going to be SRV-followed-by-HTTP. What is more, simply getting a generic host/path is not sufficient for client configuration - additional steps are required to find the principal resource of the user for whom the client is setting up an "account" (as described in the draft). The only real differences are, I think (correct me here if I am wrong Cyrus): draft-daboo-srv-caldav uses SRV + an http transaction towards a "well known path", followed by the normal caldav HTTP transactions. Well, I think .well-know/caldav should be "normal" for CalDAV irrespective of whether SRV or URI is setup. That still provides major advantages to clients and server admins. draft-faltstrom-uri uses the new RR Type URI (that give the path, that does not have to be the same all over the place), followed by the normal caldav HTTP transactions. Personally, I think first of all the URI RR can be useful for many things (else I would not have written the draft in the first place) and will push this to an RFC status. I can certainly see where it would be useful. However, I question your comments in Section 9 of your draft: specifically that URI should be viewed as a replacement for SRV. URI (may) make sense for "resource" discovery, but I don't believe that is true for "service" discovery - I think SRV still makes the best sense for that. -- Cyrus Daboo ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: draft-douglass-timezone-xml-00 & Presence
Hi James, --On July 6, 2010 2:39:09 PM -0500 "James M. Polk" wrote: How is this unique wrt to what Presence has provided in XML for 4-6 years? A comparison is at least preferable to what already exists for timezones in XML, IMO. Can you provide a specific reference to what you are referring to? -- Cyrus Daboo ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
RE: draft-douglass-timezone-xml-00 & Presence
Hi Glen, --On July 7, 2010 10:45:23 AM +0700 Glen Zorn wrote: > How is this unique wrt to what Presence has provided in XML for 4-6 > years? A comparison is at least preferable to what already exists for > timezones in XML, IMO. Can you provide a specific reference to what you are referring to? For example, see http://www.w3.org/TR/timezone/. Our draft is not about how you represent timezone (UTC offsets) in date-time values (which is mostly what that w3.org reference talks about). Our draft is about representing timezone definitions (standard time offsets, daylight saving time rules, how they varying over time, etc) in XML. This is akin to iCalendar's VTIMEZONE data or zoneinfo data found on Unix systems (and in a more "raw" form the Olson timezone database). One of the primary goals for this is to support exchange of timezone definitions between system via a timezone service protocol (draft-douglass-timezone-service - another draft we submitted a short while ago). I believe this is clear in our draft, though admittedly the abstract may not convey that in as much detail as it should (and I will endeavor to beef up the abstract to clarify this). -- Cyrus Daboo ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: TSV-DIR review of draft-daboo-srv-caldav-05
Hi Joe, --On July 16, 2010 2:55:42 PM -0700 Joe Touch wrote: 1) the document contains a section discussing the registration of caldev and caldevs (Sec 3); a corresponding section for carddev and carddevs should be added. As noted in the fourth paragraph of the introduction, the CardDAV service types have been defined in [I-D.ietf-vcarddav-carddav] currently in the RFC Editor queue. 2) the IANA recommendation that these four service names be added as aliases to http and https (correspondingly) does not seem correct. If these are indeed aliases, then this specification should recommend the use of either "http" or "https" (correspondingly) in the SRV records, without the need for new names. However, I believe the intent is that the caldev and/or carddev servers could exist on other ports than the typical web server; as such, they should be registered as service names (as per the existing SRV registry, e.g.), NOT as aliases in either the SRV registry (which has no such concept) or the IANA ports table. I.e., these new names should be registered as service names, not as aliases. This should be sufficient for the purposes of this document. In [I-D.ietf-vcarddav-carddav], after much debate with the IESG and the associated working group, the approach of registering the service types as aliases was agreed upon as a stop gap measure until the IANA SRV registry is setup. draft-daboo-srv-caldav follows that same approach. 3) The use of a required URI suffix (/carddev or /caldev) seems to be too fixed. draft-cheshire-dnsext-dns-sd (intended as standards track) indicates a way to embed this information in the a TXT record with the same DNS name as the SRV record; RFC 5507 represents the IAB (informational) position that most additional information should be included in new RR types (though it's unclear this could easily support URI suffixes). My concern is that this document does neither; it embeds this information in this document as a requirement, rather than presenting it as a configurable option with a default. I would prefer to see the latter (regardless of how), to indicate the URI suffix if not the 'default' as specified in this document. RFC5785 defines the .well-known URI - I think it is very clear that, given that CalDAV and CardDAV are in effect web-services, making use of .well-known is the right thing to do. There is no need for any additional data in the DNS. What is more, the .well-known approach is in fact useful in the absence of SRV - it can minimise the information users would have to enter. I don't see this approach as being "too fixed" - the whole point about .well-known is to fix things like this. -- Cyrus Daboo ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: TSV-DIR review of draft-daboo-srv-caldav-05
t web clients want fixed paths for finding out things about web servers. This spec simply extends that to allow CalDAv and CardDAV clients to quickly find the paths to their relevant services. Arguably ./well-known is just as "dynamic" as SRV in that the .well-known resources can use HTTP redirect to any arbitrary host/port/path combination. All we are doing is "fixing" the name of the .well-known via a registry - which seems to me exactly the same process as registering the SRV service types. -- Cyrus Daboo ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: TSV-DIR review of draft-daboo-srv-caldav-05
is the case, then I don't see why URI is needed, vs SRV/TXT (with a path= in the TXT). I do not like the mechanism proposed in draft-daboo-srv-caldav. Definitely not. But that is a different thing than requiring rough consensus on a generic way of finding an endpoint of a connection for a service. Luckily, Maastricht is a week from now and we can talk about it. I'm up for that. -- Cyrus Daboo ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Registration of media type application/calendar+xml
Hi Keith, (cc'ing Apps area ADs - I believe Peter intends to "sponsor" this draft so he at least should be aware of our discussion here) --On September 9, 2010 9:44:07 PM -0400 Keith Moore wrote: This was a bad idea when it was first proposed (if I recall correctly) around ten years ago, and it's still a bad idea. An XML representation for iCalendar is vital if we are to keep iCalendar relevant in the web-based world. The drive for this work comes from a number of areas - in particular the smart grid effort sponsored by NIST will make use of this as part of the standards suite they are defining. Whenever you define an alternate representation of something, there will inevitably be skew between the original representation and the alternate representation. iCalendar is itself extensible in terms of the addition of new properties and parameters. The trivial mapping of the iCalendar object model to our XML schema allows such extensions to be trivially mapped. This remains true even if you define mapping rules between the two (as you do in this document). The problem with mapping rules, which I believe I pointed out around ten years ago, is that the rules are specific to a particular version of iCalendar. If either iCalendar is extended, or the XML representation is extended, there's no guidance as to how to map the extended format into the other representation. If iCalendar is extended in such a way that it is no longer compatible with the XML mapping, then it would really be a completely new version that would itself not be compatible with the existing iCalendar v2.0. If that happens, well compatibility has clearly been thrown out the window. In addition, defining a new calendar format harms interoperability even if you can keep the two representations in sync. The reason is that it's no longer sufficient for a calendar application to support just one representation of calendar data. In order to reliably interoperate, it must at least able to read both, and it probably needs to be able to write both. That, and when sending calendar data to other applications, either both representations must be sent, or some way of negotiating which format to use is needed, or the user must be asked to choose which format to export. Correct - having two representations can cause problems like this. However, with the advent of HTTP-based calendar protocols, the content negotiation mechanisms in HTTP (e.g. Accept header) can be used to push most of the burden for this on servers rather than clients. Please withdraw this proposal, or at least withdraw the types application until the proposal has enjoyed more review. Having a MIME type for this representation is critical to enabling content negotiation features. I feel strongly that this is a valid and useful proposal and we are already seeing uptake in the form of smart grid work and others. Whilst this is an individual submission, I would point you to <https://datatracker.ietf.org/doc/draft-ietf-vcarddav-vcardxml/> which is the product of the vCardDAV working group. That specification defines a mapping of vCard to XML which follows the same basic design of our iCalendar-in-XML work. -- Cyrus Daboo ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Registration of media type application/calendar+xml
Hi Tony, --On September 10, 2010 8:41:05 AM +0100 Tony Finch wrote: If you have a beef with the iCalendar data model, feel free to try to come up with a better one. Funny you should say that :-) http://fanf.livejournal.com/104586.html That is a beef about timezones - one piece of iCalendar, but my no means all of it. I disagree with your suggestion of using a location to represent a timezone - there are a number of reasons why that won't work - not least that many events often do not have a physical location associated with them. That said work is going on to move to a "timezone by reference" rather than "timezone by value" model for iCalendar. There are many driving forces behind that, including several of the points you mention, plus the fact that often times the timezone definition included in iCalendar data is larger than (character-wise) then the actual event information, wasting bandwidth. To that end several options are being proposed. We have already posted a draft for a generic timezone service (<https://datatracker.ietf.org/doc/draft-douglass-timezone-service/>) - a server that can be queried for timezone definitions based on standard IDs (Olson identifiers). This allows clients and servers to get timely updates to timezone information (rather than having to wait for the next OS upgrade). We are working on defining how "timezone by reference" will work with the CalDAV calendar access protocol (RFC4791). Since that uses HTTP, simple client/server negotiation options exist to facilitate that. Note that the timezone service is not intended to just be used by iCalendar related tools - but we expect/hope that any device that needs to cache timezone definitions (e.g. unix zoneinfo data) can also make use of that. Best place to continue this particular aspect of the discussion would be the ietf-calsify WG mailing list. -- Cyrus Daboo ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Registration of media type application/calendar+xml
Hi Julian, --On September 10, 2010 12:11:27 PM +0200 Julian Reschke wrote: If your programmer is spending 70% of his coding time dealing with a presentation layer, even one as convoluted as iCalendar, you should fire him. It's not like regular expression parsers are hard to come by these days. Nor are libraries that can parse standard formats hard to come by. Can iCalendar be parsed reliably with regexps? (just asking). The Python vobject library that we use in our CalDAV server (http://calendarserver.org) does use regular expressions for parsing entire lines (after applying line "unfolding" of the overall text object), and then parsing out pieces of those. That is used for both iCalendar and vCard. -- Cyrus Daboo ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Registration of media type application/calendar+xml
Hi Keith, --On September 10, 2010 1:40:16 AM -0400 Keith Moore wrote: But here's the acid test. If you can define a mapping from iCalendar to XML that doesn't require any string constants to describe it (other than for iCalendar keywords that imply nesting, and separators that are used in a regular fashion in iCalendar), and if you can define the inverse mapping from XML to iCalendar without naming more than a couple of specific element or parameter names - then I'll concede that the mapping will probably continue to work in the face of extensions to the iCalendar data model. Otherwise, I'm highly dubious. That is precisely the goal of draft-daboo-et-al-icalendar-in-xml. iCalendar components, properties, parameters and values all map to XML in a consistent manner with no need to "special case" based on type or value. New components, properties, parameters, values, either registered with IANA or using X- prefixes map in exactly the same way. Conversion to/from XML is trivial - I have coded at least one half of that and I know others who have done both ways.It should also be easy to put together an XSLT to go from XML to iCalendar - with the only possible difficulty being having to apply escaping and line folding as required by iCalendar. -- Cyrus Daboo ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Registration of media type application/calendar+xml
Hi Keith, --On September 10, 2010 10:09:11 AM -0400 Keith Moore wrote: That is precisely the goal of draft-daboo-et-al-icalendar-in-xml. iCalendar components, properties, parameters and values all map to XML in a consistent manner with no need to "special case" based on type or value. But you're not doing that in the draft. You explicitly list every keyword. Every time a new component, property, parameter, etc is added to iCalendar, the mapping code will have to change also. The trick is to be able to translate between formats, with no changes to the code needed even when the format is extended. Fair enough. We can adjust e.g. Section 3.7 that talks about only X- extensions to also refer to any new iCalendar data objects. The basic premise being that new iCalendar data object names map directly to an XML element name. After each table in the previous sections we can add a reference to section 3.7 with a statement that that is how new items will be handled. Conversion to/from XML is trivial - I have coded at least one half of that and I know others who have done both ways.It should also be easy to put together an XSLT to go from XML to iCalendar - with the only possible difficulty being having to apply escaping and line folding as required by iCalendar. That would be great, again provided you don't have to explicitly list every keyword. It still wouldn't convince me that XML iCalendar is sufficiently valuable to be worth the degraded interoperability. But if you're going to have two formats, being able to automatically convert between them is the best way to do that. It has always been our intent to have a 1-to-1 mapping between the two. We in fact went out of our way to ensure that the XML schema would not restrict in anyway what could be done with new iCalendar data objects. -- Cyrus Daboo ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Registration of media type application/calendar+xml
Hi Keith, --On September 9, 2010 10:51:10 PM -0400 Keith Moore wrote: An XML representation for iCalendar is vital if we are to keep iCalendar relevant in the web-based world. The drive for this work comes from a number of areas - in particular the smart grid effort sponsored by NIST will make use of this as part of the standards suite they are defining. Somebody needs to talk some sense into those people. Defining another calendar format will only harm interoperability. It doesn't save any calendar implementation from needing to implement another parser, because if it wants to interoperate with existing products or be able to read old events it's still going to have to support iCalendar and probably vCalendar also. So what's the _technical_ (not political) benefit from doing this? First of all look at the mess we have got into with contacts (see recent discussion on the vcarddav WG mailing list). There we now have vCard, PoCo, OpenSocial and some new thing the OMA is doing (and their are lots of private apis too). Yet vCard has been around for a long time - why didn't those other folks just use that or at least propose fixes or extension to vcard that would satisfy their issues? Well, certainly in the case of PoCo one clear requirement was for a simple web/browser based solution - so they designed JSON and XML representations. The same mess could happen to iCalendar too. In fact there are already lots of examples of "private" apis using XML to represent calendar data, see e.g. Google GDATA. Plus I know of some public event services that uses their own custom XML format for event publishers to submit calendar data to them. In fact the initial impetus for this work did come from one such public events company that really wanted to use iCalendar rather than some home grown solution, but really wanted that as XML. Sure you can argue that they should be made to parse iCalendar format, but why should they have to write their own new parser when they already have reliable, efficient XML processing available. Frankly the important thing here is the semantics of the iCalendar model, not the syntax. I want developers to only have to concentrate on getting the semantics right without worry too much about the syntax. Now I can understand your concern about poor interoperability when it comes to having the two data formats. I think for the HTTP-based world (CalDAV, iSchedule, web-services) this is really not a big deal given the content negotiation options. For something like iMIP (iCalendar in email) it is a much bigger problem. Speaking for myself only, and not my co-authors, I think I would be OK with adding a statement that iMIP messages SHOULD NOT use the application/calendar+xml format, or at the very least require both text/calendar and application/calendar+xml in e.g. a multipart/alternative (though I would worry that the later would cause existing clients problems, and lead to message bloat). IETF's job is to provide technical leadership, not to follow bad advice. Instead of caving into them, what we need to do is publish a draft called "Translating Everything into XML Considered Harmful". Ah, yes. I seem to recall something similar for the use of HTTP - perhaps the author of RFC 3205 would like to author this new document too :-) -- Cyrus Daboo ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Registration of media type application/calendar+xml
Hi Ned, --On September 10, 2010 7:48:26 AM -0700 Ned Freed wrote: Unfortunately, now that I've had a chance to look at draft-daboo-et-al-icalendar-in-xml-06.txt a little more, I find that it doesn't do this well. For example, instead of mapping a property like dtstamp to something like: 20080205T191224Z it maps it to: 20080205T191224Z This means that additional properties will necessitate a schema update. Not good, and I believe this needs to be fixed. There was a lot of debate over the choice of element names vs element attributes to name the iCalendar data objects. Really the key to your argument is whether or not it is vital to be able to validate the XML via the schema - I think our contention was that was not a requirement. More important is validating the semantics of the calendar data (e.g. DTEND always >= DTSTART, ORGANIZER always present in iTIP messages) and I believe no one is going to want to do that via the XML schema. If you feel strongly about this I suggest you bring this issue up on the vCardDAV WG mailing list wrt to the vcard-in-xml spec which uses the same design as icalendar-in-xml. If there is agreement there to change, then we would likely re-align icalendar-in-xml to match. -- Cyrus Daboo ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Registration of media type application/calendar+xml
Hi Keith, --On September 10, 2010 12:43:53 PM -0400 Keith Moore wrote: Fair enough. We can adjust e.g. Section 3.7 that talks about only X- extensions to also refer to any new iCalendar data objects. The basic premise being that new iCalendar data object names map directly to an XML element name. After each table in the previous sections we can add a reference to section 3.7 with a statement that that is how new items will be handled. That would help. But why do you need specific rules for any of the iCalendar data object names? I can understand one or two exceptional cases, but if the mapping you have is truly adaptable, it shouldn't need many of those rules. OK, I'll discuss with my fellow authors to see what we can do to better clarify our intent. Maybe we actually state the naming/mapping rules at the very start of section 3 as the "fundamental" set of rules, but we still keep the tables in there as a useful reference back to the iCalendar spec. -- Cyrus Daboo ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Gen-ART review of draft-ietf-vcarddav-webdav-mkcol-05
Hi Spencer,
Thanks for your review - I was on vacation last week so I am only getting
around to replying now.
--On August 7, 2009 6:36:41 AM -0500 Spencer Dawkins
wrote:
Comments identified as "Spencer (clarity)" are provided for editors, but
are not part of the Gen-ART review.
Abstract
This specification extends the Web Distributed Authoring and
Versioning (WebDAV) MKCOL method to allow collections of arbitrary
resourcetype to be created and to allow properties to be set at the
same time.
Spencer (clarity): I know that RFC 4918 didn't provide an expansion for
MKCOL until about page 46 (or maybe 25, in passing), but since MKCOL
appears in the abstract for this document, it might be helpful to
s/MKCOL/MKCOL ("Make Collection")/ here. MKCOL is defined at first use in
the Introduction, so that's fine - this is only a suggestion about the
abstract.
Sure - seems reasonable. Change done in my working copy.
3. WebDAV extended MKCOL
The WebDAV MKCOL request is extended to allow the inclusion of a
request body. The request body is an XML document containing a
single DAV:mkcol XML element as the root element. The Content-Type
Spencer (minor): if I'm reading this paragraph correctly, I'd suggest
"The request body is an XML document that MUST contain a single DAV:mkcol
XML element as the root element" here - the last sentence in this
paragraph makes me think the requirement is normative, but it doesn't
look normative to 2119 scanners :-)
As per comments from Julian I won't make this change.
request header MUST be set appropriately for an XML body (e.g., set
to "text/xml" or "application/xml"). XML-typed bodies for an MKCOL
request that do not have DAV:mkcol as the root element are reserved
for future usage.
As per the PROPPATCH method ([RFC4918], Section 9.2), servers MUST
process any DAV:set instructions in document order (an exception to
the normal rule that ordering is irrelevant). Instructions MUST
either all be executed or none executed. Thus, if any error occurs
Spencer (clarity): this sentence reads roughly to me, and it's 2119
language, so needs to be clear. I suggest "The set of instructions MUST
be executed atomically; either all are executed or none are executed".
The text here is an exact copy of that in 4918. Strictly speaking all
instructions are executed, it is just that some succeed and some fail.
Perhaps better text is:
"If any one instruction fails to execute successfully, then all
instructions MUST fail (i.e., either all succeed or all fail)".
during processing, all executed instructions MUST be undone and a
proper error result returned. Failure to set a property value on the
collection MUST result in a failure of the overall MKCOL request -
i.e. the collection is not created.
3.5. Example: Successful Extended MKCOL Request
Spencer (minor): Perhaps this should be s/Successful/Unsuccessful/? It's
returning a 403/424 :D
Fixed.
4. Replacing Existing MKxxx Methods
Spencer (clarity): Hmm. This section (and 4.1, and 4.1.1) aren't quite
about REPLACING existing MKxxx methods, but more like "Providing MKxxx
functionality using extended MKCOL". Would that be clearer? The current
text in 4.1 sent me looking to see whether "replacement" meant
"deprecation" (it doesn't, if I'm reading clearly), for example.
Well ultimately I would like to see MKCALENDAR deprecated in favor of
extended MKCOL - however, given the ever growing deployments of CalDAV that
is probably not going to happen any time soon.
So, I have changed the title to:
"Using Extended MKCOL as an Alternative to MKxxx Methods"
and changed "replace" to "alternative for" in a couple of places.
--
Cyrus Daboo
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf
Re: The IETF and the SmartGrid
Hi, --On October 12, 2009 9:04:28 PM -0700 Fred Baker wrote: Is there any planned ad-hoc meeting/session related to this topic in Hiroshima meeting? Well, ROLL and 6lowpan are relevant. http://trac.tools.ietf.org/bof/trac/wiki and specifically http://trac.tools.ietf.org/bof/trac/wiki/BifIETF76 has a BOF called 6lowapp that is likely equally relevant, which is to say not designed specifically for the smart grid but potentially usable there. At this point, I'm not sure that the IETF has decided that the Smart Grid needs anything we haven't already given it in the Internet Architecture. It might, but I for one don't know yet what it would be. Perhaps a "reliable multicast" transport, perhaps a "route me differently" flag in IPv6 (which multipath TCP could also use), perhaps permission to send from a multicast group address, perhaps something else. At this point I don't think we honestly know what would help them. Looks like we may have a bar BOF. As a side comment, please note that the Calendaring and Scheduling Consortium (CalConnect) is also working with the SmartGrid folks on a calendaring standard for their needs. In particular CalConnect is promoting the use of iCalendar (RFC5545) via an XML representation (<http://tools.ietf.org/html/draft-daboo-et-al-icalendar-in-xml-00>). I would encourage all IETF participants from all areas to look at the SmartGrid work and see if other IETF technologies may be a good fit for the work they are proposing. Let's not have them re-invent the wheel. -- Cyrus Daboo ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Last Call: draft-ietf-imapext-sort (INTERNET MESSAGE ACCESS PROTOCOL - SORT AND THREAD EXTENSIONS) to Proposed Standard
Hi Mark, --On February 27, 2008 10:26:44 AM -0800 Mark Crispin <[EMAIL PROTECTED]> wrote: > The proposed changes in the comments below create significiant > incompatibilities with multiple interoperable client and server > implementations that have been in production use and widely distributed > worldwide for several years. > > The result of making any of these changes would be instability and > inconsistency between implementations, creating an environment in which > nobody can use these extensions because there is no reliable behavior. > > This document and its protocol are not new. Both have been around for > many years, and their publication was delayed unreasonably, due to (what > is now generally recognized to have been) a false belief that > internationalization had to be solved first. > > Any of these changes would add further multi-year delay to this protocol > and specification. Some of these involve considerable complexity which > will require long discussion to hammer down. > > I recommend that these issues be punted to future work in new standards. +1 - as written both SORT and THREAD can be easily extended with new behaviors as needed. The current document describes what has been deployed to date. Whilst there has been much chatter in the past about defining new e.g. thread methods, nothing has come from any of that. So either people are happy with what is there now, or no one really cares that much about either of these because most clients in use do offline sort/thread anyhow. -- Cyrus Daboo ___ IETF mailing list IETF@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Last Call: draft-ietf-imapext-sort (INTERNET MESSAGE ACCESS PROTOCOL - SORT AND THREAD EXTENSIONS) to Proposed Standard
Hi Dan, --On March 2, 2008 11:07:50 PM -0800 Dan Karp <[EMAIL PROTECTED]> wrote: > The purpose of sorting in mail clients is so that users can find > messages they're looking for. Actually you need to look at your use cases in more detail because a lot of times searching is a much better solution than sorting. e.g. the case of trying to find email from a particular person - a search is much better. Yes you do have to do a little more work to setup the search (type something in) rather than the single click sorting requires, but on large mailboxes you will usually see what you want immediately without having to scroll through the sorted list looking for what you want. For the most part I question why anyone would really want to sort on any of the text fields. The only sort I have found useful is sort by size - and then only to help in culling large messages when my quota-limited mailboxes get full. The rest of the time I either use no sort, or threading, or view filtering (view only the results of a search). View filtering can often be done with a single click (e.g. option-click on the from address of a message currently in view causes the view to show only those messages with that address). This is far superior to sorting. At least that works well for me. Others may have different ways of processes their email where sorting may make more sense. -- Cyrus Daboo ___ IETF mailing list IETF@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: wiki for IETF71 IPv6 experience Re: IPv6 @ IETF-71, especially Jabber
Hi Leslie, --On March 5, 2008 10:09:53 AM -0500 Leslie Daigle <[EMAIL PROTECTED]> wrote: > As mentioned last week -- the wiki is now accessible: > > http://wiki.tools.isoc.org/IETF71_IPv4_Outage > Currently getting a 503 error from the server. -- Cyrus Daboo ___ IETF mailing list IETF@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Last Call: draft-freed-sieve-environment (Sieve Email Filtering: Environment Extension) to Proposed Standard
Hi Sam, --On March 18, 2008 4:51:42 AM -0400 Sam Hartman <[EMAIL PROTECTED]> wrote: > This extension appears to conflate two unrelated things: information > about the interpreter context and information about the message. > > I don't think these two sets of information are similar enough that the > same interface should be used to get to both of them. > > In particular I believe that the remote-host and remote-ip variables > are inappropriate and should not be standardized. > > I believe an applicability statement should be added to the extension > making it clear that this extension is only for interpreter state and > that another extension should be designed for examining information > about the message. > I am confused as to which items you think relate to a message as opposed to the interpreter state. This extension is supposed to be all about interpreter state - tests against messages are handled in the SIEVE base and the other extensions. -- Cyrus Daboo ___ IETF mailing list IETF@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Proposed Experiment: More Meeting Time on Friday for IETF 73
Hi Eliot, --On July 18, 2008 11:41:15 AM +0200 Eliot Lear <[EMAIL PROTECTED]> wrote: I oppose this experiment. I already donate to my employer a significant amount of travel time on weekends without wanting to add to it. Flight schedules are tightening, thanks to the cost of fuel, which means that having sessions on Friday at all poses a problem now, if I want to get back by Saturday. Having afternoon sessions would put a nail in that coffin. +1 I propose two alternative experiments: 1. Required agendas and Approval No session can be approved without a posted agenda. Many agendas are late, which makes it difficult for people to know where they have to be and when. This is particularly true of working groups that meet more than once. The dhc chairs in particular have done a really good job of providing the working group with an opportunity to comment on the agenda prior to upload. Approval of agenda by either WG or AD (I could make arguments for both) would also limit stupid stuff. Just because I've written a draft doesn't make it intersting to anyone else. 2. More meeting rooms per venue. While this one adds expense in one way it can reduce in hotel and food costs to counterbalance. The real downside is that people will have to be pickier as to which meetings they attend. I have a third option, which will probably be controversial: 3. Do away with the social on Tuesday night and instead have more sessions at that time rather than later on Friday. -- Cyrus Daboo ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Proposed Experiment: More Meeting Time on Friday for IETF 73
Hi, --On July 18, 2008 7:20:37 AM -0700 Eric Rescorla <[EMAIL PROTECTED]> wrote: 2. People's ability to meet tends to expand to fill out the available meeting time. I think this is a key point. Rather than expanding the number of slots why don't we look at using the time we have more efficiently. Some questions to ask include: How much work at a meeting could actually have been done on the mailing list beforehand? What work do we do at a meeting that can't be easily done via a mailing list? Do we spend too much time with overviews of drafts that really should have been read by all attendees beforehand? Maybe it would be good for the first session on Monday to be an "Area Overview" session where an overview of all the latest drafts can be "presented" to give people a broader view of what is going on? Actually I have often felt that the IESG plenary would be a good place for area directors to give status updates/overviews of the work going on in their areas. Are 2 1/2 hour sessions really valuable, or would two shorter sessions be better? -- Cyrus Daboo ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Strong Opposition due to spam backscatter. Re: Last Call: draft-ietf-sieve-refuse-reject-07 and -08 (Sieve Email Filtering: Reject and Extended Reject Extensions) to Proposed Standard
Hi Matthew, --On September 10, 2008 3:13:33 PM -0700 Matthew Elvey <[EMAIL PROTECTED]> wrote: > Lisa D reported being told: "There is strong WG consensus behind [-07]". > Lisa D specifically claimed the WG chairs indicated there was. CHAIRS: > Can you each please confirm that you stated that there is strong WG > consensus behind [-07]? Yes, I can confirm that and firmly believe that the overall consensus of the WG is to publish the -07 draft. I don't believe there is a need to re-poll the WG on this, but if the IESG would be more comfortable doing so given your comments I am happy to do so. Also, if other WG participants wish to speak up in support of one position or another right now, they are certainly free to do so. The history of this effort is quite clear in my opinion. The WG decided to enhance the existing 3028 reject command to allow use of "reject" behavior at SMTP/LMTP protocol time. At the moment I believe your main point is that you want the spec to mandate that ereject MUST only result in SMTP/LTMP protocol rejection and indeed that all implementations must support protocol level rejection. On the several occasions you have brought this issue to the WG mailing list it has been explained in detail that there are plenty of key use cases where only doing SMTP protocol rejection is not possible (e.g. in the very common case where there are multiple recipients of the message and one recipient's script erejects, whilst another does not). I think the current wording in the -07 spec is perfectly clear that implementations must make every effort to do protocol level rejection whenever possible. For example, the first section of 2.1.1 states: Sieve implementations that are able to reject messages at the SMTP/ LMTP level MUST do so and SHOULD use the 550 response code. Also, section 2.1 states: The ereject action MUST NOT be available in environments that do not support protocol level rejection I think those are pretty strong statements about the use of ereject and protocol level rejections. I don't see why or how these need to be changed. Unfortunately, claiming that the current specification results in a "spam-friendly RFC" is going to anger a lot of people who have spent a lot of time trying to address spam issues as best as possible. It totally misrepresents the efforts of the SIEVE WG. I realize, Matthew, that you have very strong opinions on this, but I fear such comments are not going to result in forward progress. If you feel that the IETF needs to publish a document stating that all email systems MUST support protocol level rejections (which I think is what you want to require of all implementors), then I suggest that you publish a new I-D to do just that and garner support for moving that forward in the IETF. At this point I consider WG consensus to be for publishing -07 - albeit with the various comments from IETF last call appropriately addressed by the authors. -- Cyrus Daboo ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Last Call: draft-cheshire-dnsext-dns-sd (DNS-Based Service Discovery) to Informational RFC
Hi, --On November 4, 2008 6:28:19 AM -0800 The IESG <[EMAIL PROTECTED]> wrote: The IESG has received a request from an individual submitter to consider the following document: - 'DNS-Based Service Discovery ' as an Informational RFC The IANA section of the dns-sd draft describes a process for registration of SRV service identifiers, but there is another draft doing the same thing: <http://www.ietf.org/internet-drafts/draft-gudmundsson-dns-srv-iana-registry-00.txt>. So which of these two drafts is meant to define the actual SRV service type registry? -- Cyrus Daboo ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Last Call: 'Calendaring Extensions to WebDAV (CalDAV)' to Proposed Standard (draft-dusseault-caldav)
nts on ietf- discuss mailing list. --reschke]] -> Not fixed. Correct. Section 7.5., para. 1: Some calendaring REPORTs defined in this document allow partial retrieval of calendar object resources. A CalDAV client MAY specify what information to return in the body of a calendaring REPORT request. [[anchor29: Why does this simple statement require RFC2219 terminology? Please don't over-use it. In particular, please check that all "MAY" requirements really are needed for the purposes outlined in RFC2219. --reschke]] -> This one was fixed, but I think there are more of these, such as in para 2. Agreed several of the other paragraphs in that section need to use 'may' instead of 'MAY'. We will provide a note to the RFC editor for that. Section 7.8., para. 4: The request body MUST be a CALDAV:calendar-multiget XML element (see Section 9.9). If the Request-URI is a collection resource, then the DAV:href elements MUST refer to calendar object resources within that collection, and they MAY refer to calendar object resources at any depth within the collection. As a result the "Depth" header MUST be ignored by the server and SHOULD NOT be sent by the client. [[anchor42: Bad idea. Just stick with RFC3253/RFC3744 terminology (invalid depth values are rejected by the server, not ignored). This leaves the possibilily to later define semantics for these values. --reschke]] If the Request-URI refers to a non-collection resource, then there MUST be a single DAV:href element that is equivalent to the Request-URI. -> Not fixed. We felt multiget was a special case here as depth is really not relevant since the actual resources 'touched' by the report are explicitly listed in the request. i.e. the server does not do any hierarchy traversal per-se as it would for PROPFIND or other REPORTs, so Depth is never going to be used. Section 8.4., para. 3: For calendar sharing and scheduling use cases, one might wish to find the calendar belonging to another user. If the other user has a calendar in the same repository, that calendar can be found by using the principal namespace required by WebDAV ACL support. For other cases, the authors have no universal solution but implementers can consider whether to use vCard [RFC2426] or LDAP [RFC2251] standards together with calendar attributes [RFC2739]. [[anchor55: LDAP reference is outdated. --reschke]] -> Not fixed. Will get fixed via note to RFC editor. Section 8.5.2., para. 1: CalDAV clients SHOULD support downloading of external attachments referenced by arbitrary URI schemes, by either processing them directly, or by passing the attachment URI to a suitable "helper application" for processing, if such an application exists. CalDAV clients MUST support downloading of external attachments referenced by the "http" URI scheme, and MAY support downloading of external attachments referenced by the "https" URI scheme. An external attachment could be: [[anchor59: Very confusing: MAY, SHOULD and MUST requirements for basically the same thing. In particular, the MAY for "https" is bogus, because the spec just stated that the client SHOULD support arbitrary schemes. --reschke]] -> Not fixed. We did not feel this needed to be changed. Section 9.5., para. 7: Note: The CALDAV:calendar-data XML element is specified in requests and responses inside the DAV:prop XML element as if it were a WebDAV property. However, the CALDAV:calendar-data XML element is not a WebDAV property and as such it is not returned in PROPFIND responses nor used in PROPPATCH requests. [[anchor62: For this reason, I think a syntax where it can't be confused with a property whould be better. --reschke]] -> Not fixed, but I didn't expect that :-) Right - such a change would be a major change to the spec and would seriously impact many existing implementations. Note that we did originally have the calendar-data element as a non-property element in the multi-status response, but that lead to issues with how to indicate that there was an error with reading that data as opposed to error/success with the properties. i.e. we would have had to increase the amount of extra XML in the multi-status to tie together a status element with the calendar-data. Overall it was felt making it a property would be better all around. -- Cyrus Daboo ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: TLS requirements (Last Call: draft-ietf-atompub-protocol to Proposed Standard)
Hi Robert, --On March 13, 2007 3:23:22 PM -0400 Robert Sayre <[EMAIL PROTECTED]> wrote: This text is actively misleading, because it suggests RFC 4346 is included for informational purposes. The text should read: "At a minimum, client and server implementations MUST be capable of being configured to use HTTP Basic Authentication [RFC2617] in conjunction with a TLS connection as specified by [RFC2818] and [RFC4346]." The text that got used in CalDAV (which is about to be published) is: o MUST support transport over TLS [RFC2246] as defined in [RFC2818] (note that [RFC2246] has been obsoleted by [RFC4346]); with 2246, 2818 and 4346 all normative references. These type of "up-references" are not ideal and I believe there was some discussion going on somewhere about how better to deal with this type of situation. -- Cyrus Daboo ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Do you want to have more meetings outside US ?
Hi Peter, --On July 30, 2007 2:11:38 PM -0600 Peter Saint-Andre <[EMAIL PROTECTED]> wrote: Further, in-person meetings are so second-millennium. How about greater use of text chat, voice chat, and video chat for interim meetings? Are three in-person meetings a year really necessary if we make use of collaborative technologies that have become common in the last 15 years? All that will do is shift the discussion from "where shall we hold the meeting" to "what time/timezone shall we have for our conf call". Given that we have people participating from across the globe, trying to arrange a time that is acceptable for all participants will be just as hard as trying to find a meeting venue acceptable to all. Unfortunately we don't have scheduling tools that will help resolve issues like that (or at least make it easier than a multiple party email exchange/negotiation) - but some of us are working on that! -- Cyrus Daboo ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: draft-ietf-ngtrans-ipv6-smtp-requirement
Hi, --On Wednesday, July 9, 2003 5:31 PM +0900 Jun-ichiro itojun Hagino <[EMAIL PROTECTED]> wrote: | I still want the document (or the contents of it) be published, as | it contains critical guidelines for IPv6/v4 dual stack SMTP operation. | I would like to ask IESG to decide and take appropriate actions, | such as: | - poke SMTP experts, let them work on the topic and produce an RFC | - let me handle the document as an individual submission and publish | it as an RFC The ietf-smtp mailing list is still active. Consider posting and discussing this document there: <mailto:[EMAIL PROTECTED]> List-Archive: <http://www.imc.org/ietf-smtp/mail-archive/> List-ID: List-Subscribe: <mailto:[EMAIL PROTECTED]> -- Cyrus Daboo
Re: POP3 prograsm that enforce old message policies
Hi Dan, --On Monday, September 8, 2003 13:08 -0400 Dan Kolis <[EMAIL PROTECTED]> wrote: | Another way to do this is via EHLO and then your client would have to | subscribe to the "feature" of some timed self delete or you would be | denied access totally. This would make sure the user is given a heads up | on the whole thing. | | This would be super clean. Your program (in your national language) warns | you the server is going to enforce some message removal method. | | With the excellent thinking in the development of these... I'm surprised | that's not how it works. See RFC 2449 - POP3 EXTENSIONS. In particular the EXPIRE capability. That allows a server to advertise its message retention policy. I'm not sure how many clients/servers currently implement it, but it is there as an official extension. -- Cyrus Daboo
Bad mailing list practice?
A public mailbox (accessible by anyone with an IMAP client) just received a mailman reminder about a subscription to this list. That message contained a clear-text password (actually several in this case). Whilst mailman does have an option for subscribers to turn off the password reminder I think it is bad practice to have that default to 'on' for new subscribers given that mailing lists are often piped into public archives. -- Cyrus Daboo ___ Ietf mailing list [EMAIL PROTECTED] https://www1.ietf.org/mailman/listinfo/ietf
Re: Authentication/Session tracking question [was: HTTP/1.1Protocol: Help Needed
Hi Keith, --On May 13, 2005 12:55:16 AM -0400 Keith Moore wrote: Regarding your SMTP analogy, I don't think it is the case that adding another authentication flavor to HTTP is as simple as it was to add authentication to SMTP - first, because HTTP is much more complex than SMTP (especially in how it negotiates protocol options); second, because SMTP has a much cleaner extension model than HTTP (thank you mtr); third, because the relationships between principals tend to be different for HTTP than for SMTP; and fourth, because in the case of HTTP servers there is a significant investment in existing authentication databases and the types of credentials they support which did not exist for SMTP when authentication was added to it. Its worth noting that the current CalDAV effort <http://www.ietf.org/internet-drafts/draft-dusseault-caldav-05.txt> (which is attempting to use WebDAV as the basis for a calendaring and scheduling protocol) would benefit from sharing an authentication database with other related services - email (IMAP, POP, SMTP etc) being the best example. Those existing protocols now typically use SASL for the authentication exchange so it would seem natural to want SASL in HTTP too so that CalDAV could be easily integrated into such environments. Unfortunately the HTTP SASL draft <http://www.ietf.org/internet-drafts/draft-nystrom-http-sasl-12.txt> proposing such a scheme has been stalled for quite a while, so progress on this front is limited. Also, I don't think it would help with the session tracking issue either. -- Cyrus Daboo ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: calendar file for IETF
Hi Eliot, --On July 21, 2005 9:23:16 PM +0200 Eliot Lear <[EMAIL PROTECTED]> wrote: For the daring, there is http://www.ofcourseimright.com/~lear/ietf63.ics. I claim no competence in any of this. No responsibility if you miss your meetings. No promises to update it. But it works for me. Thanks for the file. Unfortunately it is not a valid iCalendar file as the VERSION property is missing. That property is required by the iCalendar specification (rfc2445 section 4.6). To fix this, just add the following line below the 'BEGIN:VCALENDAR' line: VERSION:2.0 In addition, each VEVENT component needs to have a UID property with a unique identifier in each one. Whilst the syntax of section 4.6.1 of rfc2446 implies that that parameter is optional, the description for the parameter itself (section 4.8.4.7) actually says it MUST be present. The Calisfy working group is attempting to fix ambiguities in the spec like that, amongst other things. I did 'fix' my version of the file with suitable changes and was able to import it correctly into my client. Also, I note there is a new updated agenda out that is different from the one you posted. BTW I think it might be worthwhile for the folks working on tools for IETF processes to look into having an automatic iCalendar generator for IETF agendas as a lot of people now have iCal capable clients that they could use to display the agendas. Another case where we should eat our own dog food! -- Cyrus Daboo ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: calendar file for IETF
Hi Elwyn, --On July 27, 2005 12:06:58 AM +0100 Elwyn Davies <[EMAIL PROTECTED]> wrote: It reads in to Thunderbird OK, but the result is less pretty than Eliot's effort. Eliot's version appears to lay out the multiple events in a partcular timeslot evenly across the available space, whereas Bill's results in different sized blocks and in some cases some of the events appear to be hiding others. Looking at the .ics sources it is not obvious why this should be. Clearly Bill's has additional useul info... need a merge of the two! One important (IMHO) issue is that Bill's ics does not use timezone info for the times. Since I'm not going to be in Paris, but do want to listen in to some sessions, having proper timezone info in the ics would allow me to see the times adjusted to my own local timezone without having to do any math in my head! Couple of other points: - Some lines were longer than 72 characters - Some SUMMARY's contained raw HTMl mark-up However, it imported fine into my client. -- Cyrus Daboo ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: calendar file for IETF
Hi Eliot, --On July 27, 2005 8:04:17 AM +0200 Eliot Lear <[EMAIL PROTECTED]> wrote: I couldn't agree with you more regarding multiple overlapping events. They're all designed for the case where one might double-book, and even on occasion triple book, but 8 or 9 events? None of them deal with that correctly. I could go on and on about what these Calendar programs don't do, but as I'm not going to fix them... Actually, the client I'm working on does do a pretty good job of laying out the events in IETF meetings. The reason for that is that I actually used the IETF meeting schedule as an example of a complex schedule that had to be displayed properly, and designed the system so that the IETF meetings look nice when displayed. The algorithm for doing that was of course designed to be generic enough to handle other complex schedules too. -- Cyrus Daboo ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: IETFs... the final Friday?
Hi Brian, --On January 24, 2006 2:06:20 PM +0100 Brian E Carpenter <[EMAIL PROTECTED]> wrote: 2. it would be much appreciated, subject to financial limits, to have some wireless connectivity through Friday afternoon. It may be enough just to keep the terminal room open as long as possible (with both wired and wireless access only in that area) but allow wireless in the meeting rooms to be dismantled after all meetings are done. -- Cyrus Daboo ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: About cookies and refreshments cost and abuse
Hi JORDI, --On March 23, 2006 5:32:29 PM -0600 JORDI PALET MARTINEZ <[EMAIL PROTECTED]> wrote: So my suggestion to be reasonable and fair to all, will be to provide together with our registration pack, a given number of refreshment tickets, enough to cover the average needs. The problem with tickets is who do you get to collect them? Presumably this would have to be hotel staff - at which point the costs will go up as they would likely need to employ more staff to collect tickets in addition to bringing out new trays etc. That would probably lead to having to have fewer refreshment stations and result in longer queues to get those refreshments. Something that might help with at least the estimation process that is currently done, would be to include a breakfast/break sign-up option on the online registration form. The form already asks about attendance at the Sunday reception, so why not extend that to the refreshment breaks? Obviously not everyone registers before hand (what is the percentage BTW?) but this still might be better... -- Cyrus Daboo ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: [Ietf-caldav] Last Call comment on Etag requirements in draft-dusseault-caldav-12
Hi Julian, --On June 5, 2006 8:30:25 PM +0200 Julian Reschke <[EMAIL PROTECTED]> wrote: I notice that draft-dusseault-caldav-12 now is in IESG Evaluation (<https://datatracker.ietf.org/public/pidtracker.cgi?command=view_id&dTag =11253>). For the record: as far as I can tell, the issue that I raised below is critical (given the fact that we have a separate activity to clarify this in HTTP), and has not been addressed. It's not clear to me whether the client issue it attempts to solve really is important. If it is, there is a simpler way to accomplish this ([1]) that doesn't risk making CalDAV incompatible with other specs extending HTTP (or HTTP itself, for that matter). We are planning on addressing this ETag issue in a revision now that last-call is over. Authors are discussing right now. -- Cyrus Daboo ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Internet Draft Final Submission Cut-Off Today
Hi Martin, --On February 26, 2013 at 9:28:23 PM +0100 Martin Rex wrote: Finding the current time in UTC could reasonably be left as an exercise for the reader... I have a recurring remote participation problem with the IETF Meeting Agendas, because it specifies the time of WG meeting slots in local time (local to the IETF Meeting), but does not give the local time zone *anywhere*. I would appreciate if the local time zone indication would be added like somewhere at the top of the page, to each IETF meeting agenda. The good news is the iCalendar data available for the agenda does have the correct timezone specified, so if you import the iCalendar data into your calendar client (of course assuming you use one) then you will be able to view the sessions correctly adjusted to whatever local time you have your client set for. That said, it would still be nice to include the timezone information on the agenda page. It is worth noting that daylight saving time starts on the Sunday morning of the IETF meeting, so all the agenda times are in fact UTC -4 hours for Sunday and later days, but UTC -5 for Saturday. -- Cyrus Daboo
Re: Time zones in IETF agenda
Hi Tim, --On February 27, 2013 at 9:20:09 AM + Tim Chown wrote: I would appreciate if the local time zone indication would be added like somewhere at the top of the page, to each IETF meeting agenda. So in this interesting discussion of UTC, Martin has actually made an excellent point. Having UTC listings for the agenda would be very helpful, or an alternative agenda showing UTC. Do use a calendar (iCalendar) client to manage your own time? If so, the iCalendar "feed" of the agenda will provide everything you need in terms of viewing the events in whatever timezone you want. Having an alternative text agenda in UTC still requires mental arithmetic to convert to one's own local time - a lot harder for those living in zones with a large offset, or an offset with a 1/2 hour component to it. Better would be an option on the webpage to allow the text-based agenda to be displayed in a chosen timezone. -- Cyrus Daboo
Re: Time zones in IETF agenda
Hi John, --On March 1, 2013 7:13:44 PM + John Levine wrote: Florida will be at UTC-4 (which we call EDT) as of early Sunday morning, so a meeting at noon in Florida any day of IETF 86 will be at 0800 UTC. Yow - wrong way around. The correct time for a noon meeting in Florida is 16:00 UTC (12:00 - (-4:00)). -- Cyrus Daboo
Re: Regarding call Chinese names
Hi Simon, --On July 11, 2013 at 3:58:10 PM +0200 Simon Perreault wrote: We submitted two drafts to help people here to correctly call chinese people names: http://tools.ietf.org/html/draft-deng-call-chinese-names-00 http://tools.ietf.org/html/draft-zcao-chinese-pronounce-00 Very cool! Thanks for writing this! I have a question: I think I've seen Chinese names written in both orders. That is, sometimes "Hui Deng" will be written "Deng Hui". Am I right? Does this happen often? What is the most common order? Is there a way to guess what order a name is written in? Sometimes it's not easy for non-Sinophones to know which part is the given name and which part is the family name. Well that actually brings up a good technical point! In iCalendar (RFC5545) we have properties to represent the organizer and attendee of meetings. A parameter (attribute) of those properties is "CN" - defined to be the "common name" of the corresponding calendar user. Obviously that is a single string and typically the concatenation of first name/last name. But that of course is a very "Western" approach. I have had several people request that iCalendar instead define new parameters for "FIRST-NAME" and "LAST-NAME". That then gives clients the option of re-ordering those for display purposes based on user locales and preferences. So, from a technical standpoint, it seems better to always represent user names using components (last, first, middle)? vCard does have an "N" property where individual components of a name can be broken out. -- Cyrus Daboo
Re: Regarding call Chinese names
Hi Simon, --On July 11, 2013 at 4:28:05 PM +0200 Simon Perreault wrote: So, from a technical standpoint, it seems better to always represent user names using components (last, first, middle)? vCard does have an "N" property where individual components of a name can be broken out. I'm nowhere near an expert on this topic, but I distinctly remember during the vCard 4 effort some participants saying that some cultures just don't separate names into parts. In those cultures, you would just have *a name*. Like an opaque, atomic blob I guess. True. And in the iCalendar world attendees can also be non-human entities like rooms or resources, which typically do not have separate components for their names (e.g., "Conference Room 1", "HD Projector", etc). But that case can be handled by simply specifying the full name in the "LAST-NAME" field and leave the others blank. -- Cyrus Daboo
Re: An IANA Registry for DNS TXT RDATA (I-D Action: draft-klensin-iana-txt-rr-registry-00.txt)
Hi Phillip, --On August 30, 2013 at 10:16:46 AM -0400 Phillip Hallam-Baker wrote: Service discovery requires prefixes. Here is a draft that works fine (except for the IETF review mistake). Just put IETF last call on it: http://tools.ietf.org/html/draft-gudmundsson-dns-srv-iana-registry-04 I believe that draft was superseded by RFC6335 and all service names (SRV prefix labels) are now recorded at <http://www.iana.org/assignments/service-names-port-numbers/service-names-port-numbers.xhtml> - indeed several of those come from RFCs I have written that add new SRV names. -- Cyrus Daboo
Re: pgp signing in van
Hi Peter, --On September 8, 2013 at 5:19:51 PM -0600 Peter Saint-Andre wrote: But until the MUAs across the board support it out of the box, I believe most people don't know about it or know what it means. So that's an opportunity to educate people. For instance, perhaps the Internet Society might be interested in taking on that task. Is there a reason you choose to use "inline" signing with PGP rather than multipart/signed? Is that a technical reason (e.g., poor interoperability)? -- Cyrus Daboo pgpTVGNPylnNQ.pgp Description: PGP signature
Re: Last Call: (Collection Synchronization for WebDAV) to Proposed Standard
include a statement on backwards compatibility (i.e., in an appendix state that clients/servers MAY use/accept the old Depth approach). If we do that we would need to proceed as follows: state that sync report can only be used with Depth:0, add a new request header to define the scope of the sync (e.g. Sync-Depth with values 1 and infinite). If we require Sync-Depth to be present, then we have a means for servers to detect old clients and handle Depth in a backwards compatible manner. The response body for a successful request MUST be a DAV: multistatus XML element, which MUST contain one DAV:sync-token Maybe s/one/a single/ Not sure why - "one DAV:xxx" is used in several places and I think is pretty clear. ... Preconditions: (DAV:valid-sync-token): The DAV:sync-token element value MUST be a valid token previously returned by the server. A token can become invalid as the result of being "out of date" (out of the range of change history maintained by the server), or for other reasons (e.g. collection deleted, then recreated, access control changes, etc...). Does the sync-token need to originate from the same collection? Yes of course. Perhaps changing the first sentence to: The DAV:sync-token element value MUST be a valid token previously returned by the server for a synchronization report executed on the same request-URI. 3.3. Depth behavior Servers MUST support both Depth:1 and Depth:infinity behavior with the DAV:sync-collection report. Clients MUST include either a Depth:1 or Depth:infinity request header with the DAV:sync-collection report. See above; this contradicts the base definition of REPORT. As stated above, I really don't think this is a contradiction of 3253. In the case where a mapping between a member URI and the target collection was removed, then a new mapping with the same URI created, the member URI MUST be reported as changed and MUST NOT be reported as removed. The client could tell that this happened if the DAV:resourceid property was included. A member URI MUST be reported as changed if its mapped resource's entity tag value (defined in Section 3.11 of [RFC2616]) has changed since the request sync-token was generated. It should be mentioned that this only works well with resources that are not content-negotiated. Unless the content negotiation was done as part of the original full sync request? For example, consider a server that records changes using a monotonically increasing integer to represent a "revision number" and uses that quantity as the DAV:sync-token value (appropriately encoded as a URI). Assume the last DAV:sync-token used by the client was "http://example.com/sync/10";, and since then 15 additional changes have occurred. If the client executes a DAV:sync-collection request with a DAV:sync-token of "http://example.com/sync/10";, without a limit the server would return 15 DAV:response elements and a DAV: Why 15? Is the assumption that any change to the server causes exactly one resource to change? What if there were 15 changes to the same resource? OK, I will clarify the example to imply that the 15 changes are for separate resources. Proposed change: From: and since then 15 additional changes have occurred To: and since then 15 additional changes to different resources have occurred Why do we have DAV: prefixes on some of the DTD elements? I haver removed the DAV: prefix in the actual definitions, but kept them in the comments. OK? -- Cyrus Daboo ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Last Call: (Collection Synchronization for WebDAV) to Proposed Standard
Hi Julian, --On December 14, 2011 5:29:16 PM +0100 Julian Reschke wrote: I am not convinced the use of Depth in sync report is violating the definition in 3253. In some ways it is a matter of how you look at the It does. RFC 3253 defines the response format for Depth 0, and then states how the format for Depth > 0 is derived from that; essentially by packaging into . This means that reports that do not support Depth 0 can not be defined. It also means that a report that uses for Depth 0, and which supports depths > 0, will have to packages inside . Well I don't consider the text there very clear at all. In fact I think it is very much tailored to the 3253 use cases and not flexible enough for other general purpose use of REPORT. It states this: The DAV:prop element of a DAV:response for a given resource MUST contain the requested report for that resource. Which implies "packaging" of multistatus within the DAV:prop element, which seems completely wrong to me. sync. Your viewpoint is that the report asks the collection for its changes - in that case, yes, Depth:0 would apply. The other view is that the report asks each of the child resources to list their change status, in which case Depth:1 and Depth:infinity also makes sense. Which viewpoint is taken probably depends on actual implementation rather than any perceived protocol restrictions. What Depth 0 means is just a matter of definition. If you want to make Depth 0 mean "request-URI and all of it's direct members", that's fine. It just will give funny results when you use it with other Depths *and* follow the RFC 3253 definition in these cases. So would it hurt to allow this spec to override the 3253 "nested multistatus" requirement in the interests of generating a compact response specific to this type of report? Given that I feel the sync report is vital for WebDAV operations, for in particular CalDAV and CardDAV, I want to ensure this draft proceeds as a standard, not informational. If you feel strongly about this use of Depth, in spite of my comments above, then I would be willing to make some changes, provided we also include a statement on backwards compatibility (i.e., in an appendix state that clients/servers MAY use/accept the old Depth approach). If we do that we would need to proceed as follows: state that sync report can only be used with Depth:0, add a new request header to define the scope of the sync (e.g. Sync-Depth with values 1 and infinite). If we require Sync-Depth to be present, then we have a means for servers to detect old clients and handle Depth in a backwards compatible manner. Not happy having to add a new header field just for that. A simpler approach might be to just assign a different report name, and then allow all depths. I think if you insist on requiring Depth => nested multistatus, then we either add a new header or perhaps a element inside the request body (and that would also be reasonable in terms of being able to support backwards compatibility). At this point I would prefer the later as being least disruptive to existing implementations. In the case where a mapping between a member URI and the target collection was removed, then a new mapping with the same URI created, the member URI MUST be reported as changed and MUST NOT be reported as removed. The client could tell that this happened if the DAV:resourceid property was included. A member URI MUST be reported as changed if its mapped resource's entity tag value (defined in Section 3.11 of [RFC2616]) has changed since the request sync-token was generated. It should be mentioned that this only works well with resources that are not content-negotiated. Unless the content negotiation was done as part of the original full sync request? How would that work? For instance, the common case for Conneg is using Accept:, but Accept: on REPORT specifies the expected media type for the REPORT response. Yes, that's a problem with WebDAV in general. OK, so we should probably punt on per-resource content-negotiation within the report itself (though I could see us wanting to support that in the future, in which case it would probably be done through extensions elements in the request body). So what do we need to do to address this? State that the etags returned in the report are always for the non-content-negotiated representation of each child resource? I think that is already implied by the definition of DAV:getetag, so perhaps we should state that we are referring to that value, which is the non-content negotiated entity tag. -- Cyrus Daboo ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Last Call: (Collection Synchronization for WebDAV) to Proposed Standard
Hi Ken, --On December 14, 2011 12:29:18 PM -0500 Ken Murchison wrote: ... other collection props the report asked for ... <http://example.com/ns/sync/1234 I don't necessarily see a problem with sync report using multistatus, but perhaps the sync-token should be returned in a prop response element for the collection rather than as an added element of multistatus. That won't work when the "limiting/truncation" option is used as the multistatus response for the collection indicates an overall status error, rather than using propstat. -- Cyrus Daboo ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Gen-ART review of draft-daboo-webdav-sync-06
problems, so I would rather leave this unchanged. If there is an official IETF policy on using "real names" in examples, then I would be happy to change to follow that, but I am not aware of anything like that. Nit: idnits 2.12.12 reports that draft-ietf-vcarddav-carddav has been published as RFC 6352; the RFC Editor will correct this if a new version of the draft is not required for other reasons. Fixed in my working copy. -- Cyrus Daboo ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Second Last Call: (Sieve Notification Mechanism: SIP MESSAGE) to Proposed Standard
Hi SM, --On January 26, 2012 1:16:12 PM -0800 SM wrote: I have not seen any feedback from IETF participants affiliated with Huawei. I'll highlight a comment made by John Klensin: There is feedback along those lines on the SIEVE WG mailing list. Please see the thread started by Pete on this issue last year: <http://www.ietf.org/mail-archive/web/sieve/current/msg05178.html>. That thread covers all the WG debate on this issue up until the two recent last calls. -- Cyrus Daboo ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Second Last Call: (Sieve Notifica tion Mechanism: SIP MESSAGE) to Proposed Standard
Hi SM, --On January 26, 2012 9:15:00 AM -0800 SM wrote: The minutes from the last WG session does not mention who chaired the session. Did the WG Chair bring the Note Well to the attention of the WG? I was the chair present at that meeting. Apologies for not including that detail in the minutes. All the meetings I chair include the Note Well as the second slide in presentations I put together (which seems to be common practice), and indeed you can see that in the uploaded slides. -- Cyrus Daboo ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Issues relating to managing a mailing list...
Hi,
--On March 14, 2012 11:48:08 PM -0400 John C Klensin
wrote:
Let me add to the reasons the observation that there are still
some of us who read IETF mailing lists on airplanes or in other
environments with limited, expensive, or zero connectivity. If
everything is in the email message then downloading messages
with POP3 or synchronizing a local ("offline") copy with IMAP is
easy and easy to automate. No need to read those messages at
all before heading for the airport (or whatever). If some
messages have important stuff in URL references, it creates a
nightmare because the only way to find those is to skim all the
messages before departure.
Along those lines how about setting up an IETF IMAP server with mailboxes
for each mailing list hosted by the IETF? That way anyone with a capable
IMAP client (one that can separately download text and attachments as
preferred by the user on a per-mailbox basis) can choose to sync the
messages as they prefer based on their own circumstances. What is more, if
people use the IMAP server as their main way to access to the mailing lists
there are other big benefits: the mailboxes provide a comprehensive
searchable archive of messages directly within the email client, users can
subscribe with an option to not have list email delivered to their own
account - that would remove the need to deliver lots of messages.
Yes, this would be a fairly big infrastructure change, but there are
significant benefits and flexibility to using IMAP as a shared mailing list
repository.
--
Cyrus Daboo
Re: Issues relating to managing a mailing list...
Hi Pete, --On March 15, 2012 10:49:25 AM -0500 Pete Resnick wrote: Along those lines how about setting up an IETF IMAP server with mailboxes for each mailing list hosted by the IETF? There has been a discussion under way for some time to get that to happen. I believe RFP's are being thought about (or written). Right, so isn't this, <http://tools.ietf.org/html/draft-sparks-genarea-mailarch-05>, entirely satisfiable via IMAP? At the very least I think that draft needs another requirement: * Users must be easily able to reply to archived messages using their email client of choice. In particular, replies need to preserve threading information in the form of References and In-Reply-To email headers. -- Cyrus Daboo
Re: MHonArc mail archive line wrapping
Hi Randy, --On February 17, 2011 3:04:02 PM -0800 Randy Presuhn wrote: Assuming you have ASCII key board, 80-column assumption is reasonable. For reasonable devices, I would agree. But the use case cited is for people are using devices with display capabilities which are in some respects much more limited than those of the teletypes and CRTs in common use in the 1970s. The question is whether to change email practice in order to better support these limited devices. (My answer would be "no".) All we have to do is make sure the tools we use actually make use of IETF standards (that have been around for a while) such as <https://datatracker.ietf.org/doc/rfc2646/> which would go a long way to solving this particular problem. -- Cyrus Daboo ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Last Call: (IANA Procedures for Maintaining the Timezone Database) to BCP
Hi, --On April 11, 2011 5:31:56 AM -0700 The IESG wrote: The IESG has received a request from an individual submitter to consider the following document: - 'IANA Procedures for Maintaining the Timezone Database' as a BCP I support publication of this document (with changes already provided by others' feedback). -- Cyrus Daboo ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Last Call: (xCal: The XML format for iCalendar) to Proposed Standard
s. Hrmm, good point. I will need to think about how the default value type can be handled in that case. So, in summary, I still don't think this is worth the trouble. Regardless of the application, providing multiple ways to represent the same information generally seems to degrade interoperability. I take it that you would consider offering similar comments on the vCard-in-XML draft (draft-ietf-vcarddav-vcardxml) which is also in IETF last call? -- Cyrus Daboo ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Pre-IETF RFCs to Historic (not really proposing)
Hi Keith, --On September 16, 2011 10:10:06 AM -0400 Keith Moore wrote: I think we need a low-overhead and relatively informal mechanism of reporting errata and requesting clarifications, and maybe that it should be expanded a bit to serve as an implementation and interoperability reporting mechanism. But I don't think that having such a mechanism requires us to maintain expertise in every subject matter area covered by every RFC. Again I would like to bring up the idea of every RFC having an associated wiki page(s). The goal here is to provide a way for implementors to add comments, annotations, clarifications, corrections etc to augment the RFCs. Whilst such commentary can often be found on IETF mailing lists after an RFC is published locating those and searching them can be tedious - plus the full history of discussion on various points is often not relevant to an implementor - all they need to know is what is the correct way to do it now. Doing something like this would obviously require some investment in additional infrastructure. There are also questions about how we would maintain the integrity of the information on the wiki pages, but I think those are things we can easily address. -- Cyrus Daboo ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
