W3C home > Mailing lists > Public > public-html@w3.org > September 2009

Re: Protocol feature sets and specification clarity

From: Peter Saint-Andre <stpeter@stpeter.im>
Date: Thu, 24 Sep 2009 10:06:09 -0600
Message-ID: <4ABB98F1.1090408@stpeter.im>
To: Larry Masinter <masinter@adobe.com>
CC: "Paul Cotton (pcotton@microsoft.com)" <pcotton@microsoft.com>, "public-html@w3.org WG" <public-html@w3.org>
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hi Larry,

Thanks for the reminder. For the next published versions of
draft-ietf-xmpp-3920bis and draft-ietf-xmpp-3921bis I shall name and
define the features as you suggest. I think that is more productive than
having a separate document (which no one will ever look at).

Peter

On 9/23/09 11:16 PM, Larry Masinter wrote:
> In setting up a HTML testing task force, I wanted to bring
> up some work I did earlier in IETF on a proposal to formalize
> the notion of what "independent interoperable implementations
> of every feature".
> 
> I'd made a proposal for trying to formalize interoperability
> reports
> 
> http://larry.masinter.net/draft-ietf-newtrk-interop-reports-00.html
> 
> and Peter Saint-Andre built one for the XMPP protocol.
> 
> http://xmpp.org/internet-drafts/draft-saintandre-xmpp-feature-set-00.html
> 
> While perhaps too formal for HTML testing, having a clear
> definition of "feature" and what is or isn't a normative
> requirement for producers of HTML and consumers of HTML
> (or more specialized roles such as editor, summarizer,
> translator, spider, validator, etc.) might be a useful
> way to also understand spec quality.
> 
> Larry
> --
> http://larry.masinter.net
> 
> 
> -----Original Message-----
> From: Peter Saint-Andre [mailto:stpeter@stpeter.im] 
> Sent: Thursday, November 01, 2007 8:17 AM
> To: LMM@acm.org
> Subject: Re: I-D Action:draft-saintandre-xmpp-feature-set-00.txt
> 
> I like the idea of feature names, since that makes them easier to
> reference. One thing I discovered while working on the feature set is
> that it forces you to be clearer about the features themselves in the
> specs. I wonder if it makes sense to have a "feature index" in each spec
> so that implementors can easily find the referenced features. I may
> experiment with that for the next revision of the XMPP bis drafts.
> 
> Do you think a feature set should also describe how the feature can be
> tested? For example, the features you list below are indeed testable
> since you (as a client) can try to include disallowed characters in a
> domain name or try to set a domain identifier that is longer than 1023
> bytes. The server to which you're connected should enforce the rule.
> 
> Granted, it's even more work to specify all that, but that's what we're
> here for, no? :)
> 
> Larry Masinter wrote:
>> Interesting. Much more elaborate than I had imagined; I was thinking more
>> of a list 
>>
>> Feature: "nameprep-domain-identifier"
>>   spec: rfc3920bis/section 3.2
>>   requirement: does domain identifier conform to Nameprep profile of Stringprep
>>   mandatory: Client - SHOULD, Server - MUST
>>
>> Feature "max-domain-identifier-length"
>>   spec: rfc 3920bis/section 3.2
>>   requirement: domain identifier portion of XMPP address not exceed 1023 bytes
>>   mandatory: all roles: MUST
>>
>>
>> Features should be things you can test in an interoperability test, though.
>> I don't know how to test those things, exactly.
>>
>>
>> Larry
>>
>>
>>
>>
>>
>> -----Original Message-----
>> From: Peter Saint-Andre [mailto:stpeter@stpeter.im] 
>> Sent: Wednesday, October 31, 2007 10:57 AM
>> To: LMM@acm.org
>> Subject: FW: I-D Action:draft-saintandre-xmpp-feature-set-00.txt
>>
>> FYI.
>>
>> ----- Forwarded message from Internet-Drafts@ietf.org -----
>>
>> To: i-d-announce@ietf.org
>> Cc: 
>> From: Internet-Drafts@ietf.org
>> X-Spam-Score: -1.4 (-)
>> X-Scan-Signature: d185fa790257f526fedfd5d01ed9c976
>> Subject: I-D Action:draft-saintandre-xmpp-feature-set-00.txt 
>> X-BeenThere: i-d-announce@ietf.org
>> X-Mailman-Version: 2.1.5
>> Reply-To: internet-drafts@ietf.org
>> List-Id: i-d-announce.ietf.org
>> List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/i-d-announce>,
>> 	<mailto:i-d-announce-request@ietf.org?subject=unsubscribe>
>> List-Archive: <http://www1.ietf.org/pipermail/i-d-announce>
>> List-Post: <mailto:i-d-announce@ietf.org>
>> List-Help: <mailto:i-d-announce-request@ietf.org?subject=help>
>> List-Subscribe: <https://www1.ietf.org/mailman/listinfo/i-d-announce>,
>> 	<mailto:i-d-announce-request@ietf.org?subject=subscribe>
>>
>> A New Internet-Draft is available from the on-line Internet-Drafts directories.
>>
>> 	Title           : A Feature Set for the Extensible Messaging and Presence Protocol (XMPP)
>> 	Author(s)       : P. Saint-Andre
>> 	Filename        : draft-saintandre-xmpp-feature-set-00.txt
>> 	Pages           : 17
>> 	Date            : 2007-10-31
>>
>> This document defines a protocol feature set for the Extensible
>> Messaging and Presence Protocol (XMPP), in accordance with the
>> concepts and formats proposed by Larry Masinter within the NEWTRK
>> Working Group.
>>
>> A URL for this Internet-Draft is:
>> http://www.ietf.org/internet-drafts/draft-saintandre-xmpp-feature-set-00.txt 
>>
>> To remove yourself from the I-D Announcement list, send a message to
>> i-d-announce-request@ietf.org with the word unsubscribe in the body of 
>> the message.
>> You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce
>> to change your subscription settings.
>>
>> Internet-Drafts are also available by anonymous FTP. Login with the 
>> username "anonymous" and a password of your e-mail address. After 
>> logging in, type "cd internet-drafts" and then
>> 	"get draft-saintandre-xmpp-feature-set-00.txt".
>>
>> A list of Internet-Drafts directories can be found in
>> http://www.ietf.org/shadow.html
>> or ftp://ftp.ietf.org/ietf/1shadow-sites.txt
>>
>> Internet-Drafts can also be obtained by e-mail.
>>
>> Send a message to:
>> 	mailserv@ietf.org.
>> In the body type:
>> 	"FILE /internet-drafts/draft-saintandre-xmpp-feature-set-00.txt".
>>
>> NOTE:   The mail server at ietf.org can return the document in
>> 	MIME-encoded form by using the "mpack" utility.  To use this
>> 	feature, insert the command "ENCODING mime" before the "FILE"
>> 	command.  To decode the response(s), you will need "munpack" or
>> 	a MIME-compliant mail reader.  Different MIME-compliant mail readers
>> 	exhibit different behavior, especially when dealing with
>> 	"multipart" MIME messages (i.e. documents which have been split
>> 	up into multiple messages), so check your local documentation on
>> 	how to manipulate these messages.
>>
>> Below is the data which will enable a MIME compliant mail reader
>> implementation to automatically retrieve the ASCII version of the
>> Internet-Draft.
>>
>>
>> _______________________________________________
>> I-D-Announce mailing list
>> I-D-Announce@ietf.org
>> https://www1.ietf.org/mailman/listinfo/i-d-announce
>>
>>
>> ----- End forwarded message -----
>>
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.8 (Darwin)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAkq7mPEACgkQNL8k5A2w/vx28QCfSPToydJetL2dL2wn71W6Ah2I
9/YAnReBwDKeRrKMeoHnJt6PLywyUco2
=N+OV
-----END PGP SIGNATURE-----
Received on Thursday, 24 September 2009 16:06:50 UTC

This archive was generated by hypermail 2.3.1 : Monday, 29 September 2014 09:39:08 UTC