format, I am not sure whether simply concatenating the
binary data for all tzs is valid - that is something that that format will
need to be clear about.
--
Cyrus Daboo
___
ietf-privacy mailing list
ietf-privacy@ietf.org
https://www.ietf.org/mailman
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
names.
--
Cyrus Daboo
have an N
property where individual components of a name can be broken out.
--
Cyrus Daboo
the others blank.
--
Cyrus Daboo
in Florida is
16:00 UTC (12:00 - (-4:00)).
--
Cyrus Daboo
-based agenda to be
displayed in a chosen timezone.
--
Cyrus Daboo
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
and flexibility to using IMAP as a shared mailing list
repository.
--
Cyrus Daboo
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
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
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
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
--
!-- DAV:responsedescription defined in RFC 4918, Section 14.25 --
Why do we have DAV: prefixes on some of the DTD elements?
I haver removed the DAV: prefix in the actual !ELEMENT ... definitions,
but kept them in the comments. OK?
--
Cyrus Daboo
___
Ietf mailing list
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
,
rather than using propstat.
--
Cyrus Daboo
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf
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
?
--
Cyrus Daboo
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf
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
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
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
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
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
what could be done with new iCalendar data objects.
--
Cyrus Daboo
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf
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
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
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
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
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
this.
--
Cyrus Daboo
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf
this).
--
Cyrus Daboo
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf
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
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
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
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
. 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
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
. Let's not have them re-invent the wheel.
--
Cyrus Daboo
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf
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
registry?
--
Cyrus Daboo
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf
), 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
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
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
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
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
/thread anyhow.
--
Cyrus Daboo
___
IETF mailing list
IETF@ietf.org
https://www.ietf.org/mailman/listinfo/ietf
of us are working on that!
--
Cyrus Daboo
___
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf
] 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
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
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
(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
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
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
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
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
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
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
this document there:
mailto:[EMAIL PROTECTED]
List-Archive: http://www.imc.org/ietf-smtp/mail-archive/
List-ID: ietf-smtp.imc.org
List-Subscribe: mailto:[EMAIL PROTECTED]
--
Cyrus Daboo
58 matches
Mail list logo
