Martin J. Dürst | 4 Feb 11:56
Picon

Apps mail archive server down?

I'm trying to access
http://mail.apps.ietf.org/ietf/charsets/maillist.html,
but http://mail.apps.ietf.org/ as such seems to be down.

Regards,   Martin.
--

-- 
#-# Martin J. Dürst, Professor, Aoyama Gakuin University
#-# http://www.sw.it.aoyama.ac.jp   mailto:duerst <at> it.aoyama.ac.jp
_______________________________________________
Apps-Discuss mailing list
Apps-Discuss <at> ietf.org
https://www.ietf.org/mailman/listinfo/apps-discuss
Lisa Dusseault | 2 Feb 00:17
Picon

Lisa's Apps Area Activity Report for Dec 2009 & Jan 2010

News, Updates
HTTPSTATE, HYBI, MARF and IRI WGs have been approved & created
6LOWAPP still in chartering process

Document Status and Progress

Active documents, my action:
- draft-bryan-metalink (PS): In IESG Evaluation -- a couple DISCUSS issues have been resolved and ADs need to close them
- draft-ietf-idnabis-bidi (PS): One DISCUSS remaining which appears to be resolved in the document
- draft-hammer-oauth (Info): IESG Evaluation, one DISCUSS to clear
- draft-ietf-idnabis-mappings (Info): Working with chair on how to determine WG consensus for status of this doc

Active documents, waiting on other:
- draft-giralt-schac-ns (Info): Revised ID needed
- draft-larmouth-oid-uri (PS): Revised ID Needed (response to expert review & my own questions)
- draft-reschke-webdav-post (Exp): Cyrus Daboo is doing shepherd review and writeup
- draft-nottingham-http-link-header (PS): Waiting for revision from authors

Finished processing -- new in RFC Ed queue and new RFCs
- draft-ietf-idnabis-protocol (PS): approved
- draft-ietf-idnabis-defs (PS): approved
- draft-ietf-idnabis-tables (PS): approved
- draft-ietf-idnabis-rationale (Info): approved
- draft-bryan-http-digest-algorithm-values-update (Info): approved
- draft-morg-status-in-list (PS): approved
- draft-melnikov-imap-keywords (PS): Approved
- draft-nottingham-site-meta (PS): approved
- draft-freed-sieve-in-xml (PS): approved

Other
- draft-montemurro-gsma-imei-urn (Exp): New version of draft not received before draft expiration --> change state to "dead"

WG Status

ALTO: little activity
CALSIFY: WGLC for draft-ietf-calsify-rfc2447bis-07 completed and new draft -08 issued in January.
HTTPBIS: Resolving direct WG issues one by one; discussing various non-WG issues like cross-site scripting also.
HTTPSTATE: Starting work and discussing how to word stuff in the drafts
HYBI: Just approved; debate on process for coordinating with WHATWG begun as well as lots of tech discussion.
IDNABIS: Most of the WG documents were put into IESG Evaluation and approved.  draft-idnabis-mappings remains.
OAUTH: Discussion of WRAP requirements & authentication requirements
SIEVE: renewed activity over adopting a couple more docs
_______________________________________________
Apps-Discuss mailing list
Apps-Discuss <at> ietf.org
https://www.ietf.org/mailman/listinfo/apps-discuss
Adam Barth | 26 Jan 21:51

New version of media type sniffing draft

I've uploaded a new version of the media type sniffing draft based on
feedback received on this list an elsewhere:

http://www.ietf.org/id/draft-abarth-mime-sniff-04.txt

Adam
Eran Hammer-Lahav | 25 Jan 18:03
Favicon
Gravatar

Extension Relation Type Comparison - LC Comment on draft-nottingham-http-plink-header-07

The current text about comparing extension relation types is unclear:

   When extension relation types are compared, they MUST be compared as
   URIs in a case-insensitive fashion, character-by-character.  Because
   of this, all-lowercase URIs SHOULD be used for extension relations.

What does it mean "compared as URIs"?

It is clear that these two URIs would be deemed equivalent:

http://example.com/rel/type
HTTP://example.COM/rel/TYPE

But are they also equivalent to:

http://example.com:80/rel/type

I would argue that normalizing URIs in this context is non-obvious and counter-intuitive. We are not using
URIs for the purpose of resolving them, but only as a way to construct unique strings, using the URI format
to define authority and minting rules.

I think we would be better off comparing extension relation types "as strings in a case-insensitive
fashion, character-by-character".

EHL
Mark Nottingham | 28 Jan 05:27
Gravatar

Re: Extension Relation Type Comparison - LC Comment on draft-nottingham-http-plink-header-07


On 26/01/2010, at 4:03 AM, Eran Hammer-Lahav wrote:


> The current text about comparing extension relation types is unclear: > > When extension relation types are compared, they MUST be compared as > URIs in a case-insensitive fashion, character-by-character. Because > of this, all-lowercase URIs SHOULD be used for extension relations. > > What does it mean "compared as URIs"? > > It is clear that these two URIs would be deemed equivalent: > > http://example.com/rel/type > HTTP://example.COM/rel/TYPE > > But are they also equivalent to: > > http://example.com:80/rel/type
None of those are equivalent; it specifies case-insensitive, character-by-character. "As URIs" alludes to the fact that an extension type might be serialised in a non-URI form; e.g., as a CURIE, if that's your cup of tea. I'll try to clarify this in the next draft. Cheers, -- Mark Nottingham http://www.mnot.net/
Eran Hammer-Lahav | 28 Jan 05:50
Favicon
Gravatar

RE: Extension Relation Type Comparison - LC Comment on draft-nottingham-http-plink-header-07



> -----Original Message----- > From: Mark Nottingham [mailto:mnot <at> mnot.net] > Sent: Wednesday, January 27, 2010 8:28 PM > To: Eran Hammer-Lahav > Cc: apps-discuss <at> ietf.org > Subject: Re: Extension Relation Type Comparison - LC Comment on draft- > nottingham-http-plink-header-07 > > > On 26/01/2010, at 4:03 AM, Eran Hammer-Lahav wrote: > > > The current text about comparing extension relation types is unclear: > > > > When extension relation types are compared, they MUST be compared as > > URIs in a case-insensitive fashion, character-by-character. Because > > of this, all-lowercase URIs SHOULD be used for extension relations. > > > > What does it mean "compared as URIs"? > > > > It is clear that these two URIs would be deemed equivalent: > > > > http://example.com/rel/type > > HTTP://example.COM/rel/TYPE > > > > But are they also equivalent to: > > > > http://example.com:80/rel/type > > None of those are equivalent; it specifies case-insensitive, character-by- > character. "As URIs" alludes to the fact that an extension type might be > serialised in a non-URI form; e.g., as a CURIE, if that's your cup of tea.
I have talked to a few folks about this and they all assumed 'as URI' means that outside the lower-case exception, normal URI comparison rules apply. I agree with your intention though that these should be compared as case-insensitive strings. EHL
Anthony Bryan | 24 Jan 21:39
Picon
Gravatar

Updating IANA "Operating System Names" registry

Hi,

The IANA registry "Operating System Names" found at
http://www.iana.org/assignments/operating-system-names is missing a
few recent common OSes.

LINUX-2.6
WINDOWS-NT-6
WINDOWS-NT-6.1

There's MACOS but not MACOS-10.0 or MACOS-X-10.0, MACOS-X-10.1, etc.

I've been told the registry can be updated with an email, so I wanted
to check if anyone had suggestions for other additions?

(My ID http://tools.ietf.org/html/draft-bryan-metalink allows file
publishers to list what OS a file is intended for).

--

-- 
(( Anthony Bryan ... Metalink [ http://www.metalinker.org ]
  )) Easier, More Reliable, Self Healing Downloads
Paul Hoffman | 24 Jan 23:29
Picon

Re: Updating IANA "Operating System Names" registry

At 3:39 PM -0500 1/24/10, Anthony Bryan wrote:
>Hi,
>
>The IANA registry "Operating System Names" found at
>http://www.iana.org/assignments/operating-system-names is missing a
>few recent common OSes.
>
>LINUX-2.6
>WINDOWS-NT-6
>WINDOWS-NT-6.1

...where "few" means "most".

This registry is a complete mess. Linux is listed by kernel versions, not distro versions, but FreeBSD is
only listed once.

>(My ID http://tools.ietf.org/html/draft-bryan-metalink allows file
>publishers to list what OS a file is intended for).

Given the state of the registry and the number of people-hours that will be wasted on arguing what should and
should not be in it, I suggest that simply removing "The IANA registry named "Operating System Names"
defines values for OS types." and then letting the registry rot is probably a better use of everyone's time.
Thomas Narten | 26 Jan 19:15
Picon
Favicon

Re: Updating IANA "Operating System Names" registry


> The IANA registry "Operating System Names" found at > http://www.iana.org/assignments/operating-system-names is missing a > few recent common OSes.
More to the point, who uses this registry and who cares? It is old, and probably stopped serving a useful purpose years ago. What protocols make use of the registry? Absent a real usage, the registry should either be shutdown, or just quietly left alone. Thomas
Peter Saint-Andre | 26 Jan 19:32

Re: Updating IANA "Operating System Names" registry


On 1/26/10 11:15 AM, Thomas Narten wrote: >> The IANA registry "Operating System Names" found at >> http://www.iana.org/assignments/operating-system-names is missing a >> few recent common OSes. > > More to the point, who uses this registry and who cares? It is old, > and probably stopped serving a useful purpose years ago. > > What protocols make use of the registry? > > Absent a real usage, the registry should either be shutdown, or just > quietly left alone.
+1. Who uses it, how extensively, and (these days) why? Peter -- -- Peter Saint-Andre https://stpeter.im/
Attachment (smime.p7s): application/pkcs7-signature, 6820 bytes
_______________________________________________
Apps-Discuss mailing list
Apps-Discuss <at> ietf.org
https://www.ietf.org/mailman/listinfo/apps-discuss
John C Klensin | 27 Jan 10:07

Re: Updating IANA "Operating System Names" registry


--On Tuesday, January 26, 2010 13:15 -0500 Thomas Narten
<narten <at> us.ibm.com> wrote:

>> The IANA registry "Operating System Names" found at
>> http://www.iana.org/assignments/operating-system-names is
>> missing a few recent common OSes.
> 
> More to the point, who uses this registry and who cares?  It
> is old, and probably stopped serving a useful purpose years
> ago.
> 
> What protocols make use of the registry?

Sigh.

The FTP SYST command, among other things.   SYST is much less
important now than it was a few decades ago when there was a lot
more diversity of hardware architecture and operating systems,
but there is what we would now describe as a normative reference
from RFC 959 (STD 9) to this registry.

The DNS HINFO record is also supposed to use them.  While I
haven't see a lot of uses of HINFO recently in the public DNS,
we haven't deprecated the RR type either.

I have generated an errata entry for RFC 959 noting that SYST
should point to this registry rather than pointing more vaguely
to "Assigned Numbers".  I will leave similar comments on the
definition of HINFO and possibly a modification to the new FTP
Commands and Extensions registry (to note that this registry
specifies the parameter space for SYST) to someone who has more
energy and time for that kind of work.

With a quarter-century's hindsight, it is clear that this
registry, and the names in it, should have used structured names
of some style such as 

   OperatingSystem Delimiter Version Delimiter Subversion

possibly with explicit registration for only the first element,
but it is a little late now.   Getting the list up to date and
into shape would clearly require significant work, but I don't
think we should discourage new registrations by anyone who
thinks that particular entries are needed.

> Absent a real usage, the registry should either be shutdown,
> or just quietly left alone.

I don't see how one can shut down a registry that is used
normatively by two full standards (FTP and DNS) without first
deprecating the FTP Command and the DNS RR that use it.
Continuing the long-standing practice of neglect unless new
entries are actually needed seems entirely reasonable and has
the advantage of not requiring any action.  In general, it is
probably better to believe that registries should be updated
when someone has a substantive need for new entries than to try
to create some abstract requirement to add entries for their own
sake.

I am tempted to ask why we are even wasting time discussing this
registry, but I won't.

      john

Gmane