Re: call for ideas: tail-heavy IETF process
On Sun, 2013-05-05, John C Klensin wrote: Finally, there are a few things that we used to do, that were helpful, and that were abandoned due to industry evolution and changes in priorities. The original idea of a Proposed Standard as a fairly rough specification that would be used for study and evaluation on the basis of implementation experience, not a spec from which products were built, is one that has been mentioned (although not quite in that way). FWIW, this leads me to the thought that the IETF may have a terminology problem. The word standard is used too soon in the maturity levels of RFCs. I think that our skills are primarily in producing protocols rather than standards. Perhaps it would have been better if the names of the maturity levels were something like: Proposed Protocol Test Version 1 Protocol Test Version 2 protocol . . . Standard Protocol Only using the word standard when it was determined to be stable and recommended for wide usage. Anyway, my 2 cents. -- Bill McQuillan mcqui...@pobox.com
draft-ruoska-encoding-00.txt
Since there is no author email address in the draft, I'm sending this to the IETF Discussion list. Issues: Section 2.1: integer idenfier - integer identifier Section 2.1, para 2: Implemenations -Implementations Section 3.1, 3rd from last para: These bits determines - These bits determine Section 3.2.3, para 2: sub braches but braches - sub branches but branches Section 3.2.3, para 3: orginal - original Section 3.3.2: This section should mention the format for negative numbers (2's comp, 1's comp, signed magnitude,...) Section 4: No values are given for designating the 4 types of Identifier. Section 3.4: Definition of Extended Frame does not allow an Identifier for *any* new data type frame. Is this reasonable? Section 4.2, para 2: Integer identifiers are used to make document less resource hungry. ^--the They are very efficient from resource point of view when compared to ^--a string idenfiers. Downside is that they make debugging a bit more ^--ti ^--The complicated. People are not good in remembering semantics bind to at bound plain numbers so debugging tools maid need access to a look at table may lookup to convert integer idenfiers to more human friendly strings. ^--ti Section 4.3: Ascii art diagram split across page break. Section 5, para 2: Implemenations - Implementations Section 5.1, last para: String indentifier - String identifier Section 7, para 1: Implemenations - Implementations Section Author's Address: No email address given for Jukka-Pekka Makela. -- Bill McQuillan mcqui...@pobox.com
Re: draft-ietf-appsawg-json-pointer-07 - array index for end ofarray
ISTM that if the person constructing the pointer wants to append to an array and knows the size of the array (as pointed out in another thread) he should be able to use /foo/len where len is the index of the element just after the last existing one in the array. No need for /foo/- or any negative integers. The only requirement is to allow that one extra index to be used without error. On Mon, 2012-12-17, Mark Nottingham wrote: I disagree. Adding a capability for other indices down the road is NOT compatible for existing uses, so adding it will cause confusion (are you using the old JSON Pointer or the new one?) and interop problems. IIRC the discussion in the WG went much along these lines, and led to us explicitly choosing a single character, rather than a misleading -1 construct. I'd be more comfortable with changing the character to something even further away, rather than making this construct even more confusing. The other way we could go would be to do full negative indexing; we don't have any use cases for that, and it increases complexity a bit, but at least it would be unsurprising. On 18/12/2012, at 6:54 AM, Barry Leiba barryle...@computer.org wrote: This was discussed in the Working Group, but it wasn't felt that the added complexity was worth it; there's a strong feeling that this spec should be as simple as possible. Might I suggest, however, using -1 instead of - to refer to the last item in an array, as this provides two benefits: 1) Allows for adding the complexity down the road in a compatible way, should there be need 2) Uniformity; i.e. always using integer values for referring to array elements. I have to say that this suggestion sounds very compelling to me, for both reasons. I know there's a bunch of running code out there, but this (and perhaps teasing apart the add and insert concepts into separate verbs) seems worth the bother. Barry, as participant -- Mark Nottingham http://www.mnot.net/ -- Bill McQuillan mcqui...@pobox.com
Re: Gen-ART LC review of draft-leiba-5322upd-from-group-06
On Thu, 2012-10-18, John C Klensin wrote: snip As I said earlier, I can live with almost anything if it is correct and allows us to move forward. I am, however, getting more concerned about the consequences to the virtual 5322bis and its future instantiation if we go down these paths. I would really not like to be the relevant AD (or Pete-bis) trying to defend leaving the explanation and reference out of 5322bis given that they were important enough to include in this document and, if the explanation and reference go into 5322bis, why a large series of other references and explanations should not be included. I'd be a tad happier if this explanatory stuff when into an appendix rather than the text. serious value=false How about we put the explanation right next to the justification in 5322 why group was not allowed in From: in the first place? /serious I have wondered about that limitation for at least 15 years. I have come up with possible explanations but without a shred of evidence from the RFCs. snip -- Bill McQuillan mcqui...@pobox.com
Re: RFC 2119 terms, ALL CAPS vs lower case
On Sat, 2012-05-19, Brian E Carpenter wrote: On 2012-05-19 20:39, Ofer Inbar wrote: ... But don't change the rules. 2119 works well as is IMO. Just to be clear about the current rules, 2119 makes it clear that upper case keywords are optional (These words are often capitalized). Indeed, numerous standards track documents don't use them. I do not agree that 2119 is clear on this topic. I read the beginning of the first paragraph of the Abstract as: Some background motivation: In many standards track documents several words are used to signify the requirements in the specification. These words are often capitalized. A new proposal: This document defines these words as they should be interpreted in IETF documents. Thus, it is defining a new, unified convention for documenting requirements language. And then the boilerplate shows all of the requirement words in uppercase, obviously convincing a lot of people that the new standard is to use them in uppercase when their meaning is normative. As one example, in section 6 the text reads: Imperatives of the type defined in this memo must be used with care and sparingly. In particular, they MUST only be used where it is actually required for interoperation or to limit behavior which has potential for causing harm (e.g., limiting retransmisssions) For example, they must not be used to try to impose a particular method on implementors where the method is not required for interoperability. There is one instance of MUST and two of must in this paragraph. I would observe that the MUST is used to define a requirement upon RFC texts, but the two musts are used to try to affect the motivation of the humans writing the RFC texts. There are examples elsewhere in 2119 of the use of these words in lowercase that seem NOT be used in a normative way. If anything I would evaluate the evidence to indicate that the distinction of case *was intended* to be meaningful. -- Bill McQuillan mcqui...@pobox.com
Re: 2119bis
On Tue, 2011-08-30, Keith Moore wrote: But in general I get the impression that people are attacking SHOULD because of specific problems rather than general problems. Since I find SHOULD very useful, to me it makes more sense to try to outline cases where SHOULD is problematic, and provide advice for those cases, than to try to get rid of it or change what it means. e.g. For the specific case of optional features that must be negotiated, I don't think that SHOULD is the problem. Rather I think that optional features are too common. That's not to say that optional features and feature negotiation are never useful, particularly when extending a protocol that is already well-established in the field. But if making features optional is seen by WGs as a way to avoid making hard decisions about what is required to interoperate, that really is a problem. It just doesn't have anything to do with SHOULD. How about recommending SHOULD ... BECAUSE to encourage the author to justify the SHOULD. I suspect that this would reduce the number of SHOULDs, that would be better as MAYs, due to the author's personal preference. My impression is that the 2119 limitation on MUST and SHOULD for only necessary protocol features is sometimes forgotten. -- Bill McQuillan mcqui...@pobox.com ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: IESG voting procedures
On Sun, 2011-08-14, Keith Moore wrote: 2. Even if the document is approved over the AD's objection, I think it's completely unacceptable to bury the AD's technical objection. Expecting the AD to change his Discuss to an Abstain is dishonesty on the part of the organization. It sure sounds like if the status is renamed: Disagree-But-Overruled the annoyance becomes much smaller. (Just my 2 cents) -- Bill McQuillan mcqui...@pobox.com ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: I-D Working groups and mailing list
On Wed, 2011-08-03, Hector Santos wrote: I would like to propose that new I-D submissions include information about the existence of a Working Group, if any, and/or discussion group list address, if any, for to join and participate in the development of the I-D or simply to follow it. I think I have read some I-D that including this useful information, but most do not. Its one the first things I look for. I was going to suggest the same for an RFC, but it could be the WG was closed down by this time. Just a thought if it makes sense. +100 Perhaps it could be included in the ID-Announce message. -- Bill McQuillan mcqui...@pobox.com ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: I-D Action:draft-housley-two-maturity-levels-04.txt
On Tue, 2011-03-15, Martin Rex wrote: Dave CROCKER wrote: Brian E Carpenter wrote: Any documents that are still classified as Draft Standard two years after the publication of this RFC will be automatically downgraded to Proposed Standard. 1. While the accounting ugliness of leaving these untouched is obvious, I am less clear about the practical trouble they cause. We should gain some public agreement that this is seriousness enough to worry about, and why. 2. Automatic reclassification strikes me as dangerous and likely to have serious unintended consequences. I don't understand the motivation about changing anything about the status of documents that have already been published. Among the original complaints there were the two: - the IETF is confusing the non-IETFers about the standardization with its three levels of document maturity - the bar for Proposed is too high and ought to be lowered. Unless the clear intent and IETF consensus is to add - mislead _everyone_ about the real document maturity of *ALL* IETF documents, including all existing documents - penalize all folks did put effort into going to Draft Standard by completely nixing their effort two years later. the status of the existing documents should NOT be touched by any new rules for publishing documents as Proposed Standards. +1 To make clear which documents were issued under the original regime and which were issued under the new, there should probably be an obvious gap in the number range (going to 5 digit or 6 digit numbers). -1 (simple sequentially increasing RFC numbers for all items is fine) -Martin -- Bill McQuillan mcqui...@pobox.com ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: I-D Action:draft-yevstifeyev-abnf-separated-lists-01.txt
I found several problems with this draft. In overview, the reason that we removed the #rule from ABNF was that it was very difficult to specify for a general case. This draft has the same problem. The production given does not actually produce the desired results. n^(a)m element = ( n(*LWS element) *o(*LWS a *LWS element)) If the usage is: 5^(,)10 abc it would allow something like: abc abc abc abc abc abc , abc not: abc, abc, abc, abc, abc, abc, abd which was probably intended. - The production: a = VCHAR / SP / HT / any other separator does not seem to address the possibility of multi-character separators very clearly. What if I want to define a list like: abc and def and ghi and jkl can I use: ^( and )ident - I also do not believe that *FWS belongs in such a general rule and should rather be defined by the actual usage. E.g.: 5^(*FWS , *FWS)10 abc - Typo: 2.1 Examples, fourth example should be: ^(-)element -- Bill McQuillan mcqui...@pobox.com ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: motivations (was: Re: draft-housley-two-maturity-levels-00)
It seems to me that this discussion is conflating two related but distinct things: protocols and specifications. The IETF is concerned with producing and refining *protocols*; however the work products are specifications(RFCs). A *protocol* such as SMTP is very mature and thus can be used by many different parties to enable e-mail exchange with high confidence in its interoperability. For example, SMTP has matured over the last several decades by adopting DNS and MX routing, creating a mechanism for allowing enhancements (EHLO), dropping unuseful features such as SEND and source routing, separating Submission from forwarding (SUBMIT), among others. The *specifications* for SMTP (RFC821, etc.) have been of varying quality measured by their accuracy in describing the *protocol*. The goal of a specification should be its capability for allowing someone to implement the protocol accurately, not whether the protocol itself is well designed. Therefore I would suggest that the SMTP protocol remains a Full Standard even while successor specifications to RFC821, which are trying to describe it, are cycling through levels of wordsmithing. Although the words Proposed and Draft seem reasonable to describe these editing cycles I am not sure that Full quite captures the goal of this process. For what it's worth. -- Bill McQuillan mcqui...@pobox.com ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
websocketprotocol or the demise of the draft-100 experiment
I noticed the publication of draft-ietf-hybi-thewebsocketprotocol-00 and, I presume, the ending of its previous incarnation as draft-hixie-thewebsocketprotocol at 76. I had been watching to see how this test of the naming format of internet drafts, as it approached 3 digits, would disrupt various scripts. Sadly, now we may never know. ;-) -- Bill McQuillan mcqui...@pobox.com ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Towards consensus on document format
On Tue, 2010-03-16, Doug Ewell wrote: The other silly aspect of this will it be readable in 1000 years argument is the supposition that the documents will sit, forgotten, for 1000 years until some future archaeologist digs them up and wants to decipher them. Obviously, if a newer and more wonderful format comes along that obsoletes PDF or HTML or whatever, there will surely be a utility (or, more likely, a spate of them) to convert data from the old format to the new format. The RFC series, and zillions of documents more valuable than 80% of the RFC series, will be converted and will exist in both old and new formats LONG before there is any risk of irreversible obsolescence. I am haunted by the reports I've heard of NASA plaintively requesting *anybody* to provide them with a 7-track tape machine to allow them to read old data tapes from the 1960's and 1970's. Not so much 1000 years as 40 years! -- Bill McQuillan mcqui...@pobox.com ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: draft-jabley-sink-arpa, was Last Call: draft-jabley-reverse-servers ...
On Mon, 2010-01-11, Arnt Gulbrandsen wrote: Ie. if .invalid has to be dumped, the replacement should be in .arpa. I can accept that. _If_ it has to be dumped. Maybe .invalid was a bad choice in the first place. But that's water under the bridge. My understanding was that the intended usages are slightly different: *.invalid could be used in places that if it accidentally got out onto the internet it would do no harm to any legitimate domains. It was also acceptable for a resolver to recognize that .invalid was invalid and short circuit the DNS lookup. sink.arpa seems to be intended to allow for recursive lookup and a proper NXDOMAIN to be returned as normal. I think that it is specifically intended NOT be treated specially by resolvers. -- Bill McQuillan mcqui...@pobox.com ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: I-D Action:draft-levine-reserved-names-registry-00.txt
In the table for Initial Contents of Registry, it seems to me that the Categorys for INADDR.ARPA, IP6.ARPA, E164.ARPA, URI.ARPA, URN.ARPA, and IRIS.ARPA should be S rather than R. They are not Reserved in the sense of not intended to be used on the public Internet. I am also not sure they should be listed at level Top since they are each handled by the SLD .arpa rather than the root. -- Bill McQuillan mcqui...@pobox.com ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: I-D Action:draft-davies-dtnrg-uri-find-00.txt
On Fri, 2009-10-09, internet-dra...@ietf.org wrote: A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : Adding the find Operation to the dtn: URI Scheme Author(s) : E. Davies, A. Doria Filename: draft-davies-dtnrg-uri-find-00.txt Pages : 7 Date: 2009-10-09 This document discusses the addition of a new operation to the proposed dtn: URI (Uniform Resource Identifier) scheme. The new find operation would provide support for DTN anycast services. I find it odd that the acronym URI is explained (IMHO unnecessarily) but dtn is not. Even reading the draft, I could not determine what dtn means. -- Bill McQuillan mcqui...@pobox.com ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: RFC archival format, was: Re: More liberal draft formatting standards required
On Sun, 2009-07-05, Yaakov Stein wrote: OK, here is what happens on my netbook using your method. Original 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type |Length |R|T| Transport flags | Res | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | MTU | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ What I see : 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+- +-+-+-+-+-+-+-+-+-+-+-+-+ -+-+-+-+-+-+-+-+-+ | Type |L ength |R|T| Transpor t flags | Res | +-+-+-+-+-+-+-+-+-+-+- +-+-+-+-+-+-+-+-+-+-+-+-+ -+-+-+-+-+-+-+-+-+ | MTU | +-+-+-+-+-+-+-+-+-+-+- +-+-+-+-+-+-+-+-+-+-+-+-+ -+-+-+-+-+-+-+-+-+ What sort of editable input, handled by what sort of presentation mechanism, would solve this case? And, if it involves horizontal scrolling and/or zooming in or out, why wouldn't that also handle plain text, too? -- Bill McQuillan mcqui...@pobox.com ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: WG Review: Yet Another Mail (yam)
If an existing protocol implementation is conforming to the Draft Standard version of the protocol specification, it must also be conforming to the resulting Full Standard version. Hence, specification changes that create a violation of this requirement are out of scope of the working group charter. This part of the charter worries me. It presumes that no Draft Standard can be ambiguous! On the off chance that a Draft Standard *is* ambiguous in some way that has caused two implementations to be non-interoperable, but arguably conforming, it seems that the WG must drop the Standard from consideration without any chance of some engineering judgement (or even horse-trading) to get the implementations to become interoperable and to resolve the ambiguity. OTOH, maybe that WAS the intent of the charter. -- Bill McQuillan mcqui...@pobox.com ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: [taugh.com-standards] Re: Review of draft-ietf-dkim-ssp-08
On Sun, 2009-01-04, Dave CROCKER wrote: From: ACME Chief Officers: Alice c...@acme.example.com, Bob c...@acme.example.com; There must have been *some* concept of email that dictated that a message could be sent *to* a group but not *from* one! I don't remember whether this idea came up during discussions for RFC 733. I don't think so, although it certainly seems to me to be as reasonable to be able to apply the construct to the author field as to a recipient field. But since the construct so infrequently used, I'm not sure it's all that helpful to explore this enhancement... Well, this prompted me to go searching the RFCs, and I found out that the From: group: ... ; construct WAS allowed in RFCs 724 and 733 but was removed in 822. There are examples showing exactly this construct in the earlier RFCs (724: II.D.i and 733: V.C.9), but the corresponding example has been changed in 822 (A.2.7) and a note added specifically saying: Note that the name of the committee cannot be specified, since group names are not permitted in the From field. I'd love to see the discussion that brought about that change. :-) Anyway, this tangent has probably run it's course, so I'll drop it on this list. -- Bill McQuillan mcqui...@pobox.com ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: [taugh.com-standards] Re: Review of draft-ietf-dkim-ssp-08
On Sat, 2009-01-03, Dave CROCKER wrote: RFC5322 models the world of memos. Paper messages and other human communications can be, and sometimes are, from multiple authors. That's not just theory; it's real-world practice. If the Internet's email format drops that construct from the only place in the message that provides a structured designation of authorship, how are legitimate occurrences of multiple authors to be indicated? Perhaps someone knows what the Founders (of email) conceptual models were for a message (memo?) For instance, although I obviously do not understand the original intent behind the group of mailboxes construct, I have long wondered why the following is not valid: From: ACME Chief Officers: Alice c...@acme.example.com, Bob c...@acme.example.com; There must have been *some* concept of email that dictated that a message could be sent *to* a group but not *from* one! -- Bill McQuillan mcqui...@pobox.com ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
draft-rfc-image-files-00.txt
On first reading this seems to be an interesting way to go. However, is it necessary to call a file full of figures an image file? Couldn't we just pick one word throughout? I vote for figures since it seems to match more to the book publishing metaphore. Thus: draft-...-vv.figs.pdf RFCn/Figures and some other text changes. I also hope that some guidelines for standard ways to reference a particular figure from the ASCII text will be developed. -- Bill McQuillan [EMAIL PROTECTED] ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Be aware when traveling to the USA.
On Sat, 2008-08-02, Jeroen Massar wrote: Truman Boyes wrote: How about mailing yourself a USB drive with encrypted data and taking that along for the trip. Unfortunately, the above interpretation is defeated by the last two sentences of the relevant paragraph in the CBP document: --8-- Sealed Letter Class Mail. Officers may not read or permit others to read correspondence contained in sealed letter class mail (the international equivalent of First Class) without an appropriate search warrant or consent. Only articles in the postal system are deemed mail. Letters carried by individuals or private carriers such as DHL, UPS, or Federal Express, for example, are not considered to be mail, even if they are stamped, and thus are subject to a border search as provided in this policy. --8-- Guess they thought of that workaround. :-( So, back to the internet as savior! -- Bill McQuillan [EMAIL PROTECTED] ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
draft-mayrhofer-geopriv-geo-uri-00
While reading through this ID: A Uniform Resource Identifier for Geographic
Locations ('geo' URI), I found several minor issues.
Section 2. Introduction
[use of WGS84 reference system]
I wonder if it might be more forward thinking to allow for the optional
specification of the reference system being used. Perhaps this could be one
of the URI parameters mentioned in section 4.7
Section 4.4.1 Component Description
The number of decimal places indicates the precision of the value.
One degree equals 111.319,45m at the equator (40.075,004km / 360
degree). Five decimal places (0.1 degree) seem to imply a for
civil use sufficient accuracy.
To my American eye the decimal notation (partially) used here was jaring.
Searching (briefly) for some sort of presentation standard in an RFC or
other technical document was unsuccessful. Is the use of . and ,
standardized in the representation of real numbers in RFCs?
Section 6. GML Mappings
There seems to be no explanation of what GML is, not even a Reference
document.
Section 9.1. Invalid Locations
Is there a recommended way to represent the poles? Dare I suggest geo:90
and geo:-90? If that is too much of a special case, should the longitude
always be zero or can it be anything between -180.0 and 180.0?
Section 9.2. Location Privcay
Typo: .Privacy
--
Bill McQuillan [EMAIL PROTECTED]
___
IETF mailing list
IETF@ietf.org
https://www.ietf.org/mailman/listinfo/ietf
Re: Proposed IESG Statement Regarding RFC Errata for IETF Sream RFCs
On Thu, 2008-04-17, Bob Hinden wrote: I think that only Approved and Archived are required. Approved is correctly for implementors to correct problems in the specification. Everything else is for a working group to consider when the RFC is revised. I believe that this is a good way to go. One quibble that I have is with the word Archived. It merely describes the mechanism to be used. (BTW, I hope that Approved Errata will also be archived!) Archiving, IMO, implies saving something valuable. Unfortunately, it doesn't distinguish between items that are of value to be considered in the next update discussion and items that may be of value to current implementors. I would propose that the two classifications be labeled: Approved and Not Yet Approved with the clear understanding that *both* such types of items will be archived so as to be available to the next document update process. -- Bill McQuillan [EMAIL PROTECTED] ___ IETF mailing list IETF@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Comment on draft-santoni-timestampeddata-02
Perusing this draft I came upon a paragraph that seemed to need comment: 3. Compliance requirements ... Compliant applications SHALL always populate the fileName field of TimeStampedData structure with a non-empty string, which is supposed to be the real name of the time-stamped file. Path information MUST NOT be included. A valid example is patent123.doc. An invalid example is c:\Documents and settings\John\Desktop\patent123.doc. It seems to me that the MUST for a non-null filename presumes that there will never be a situation where the data has no natural filename and the identity of the data is known from other context information. If it ever becomes necessary for a convention to arise where data, that doesn't have a natural filename, gets some name like unknown.name, I believe that it would be better to allow a null name to be given. Note that some sort of validation must be done by the consumer of the TimeStampedData anyway to prevent a filename being used that has invalid syntax for the consumers filesystem or would overwrite another file that happens to have the same name, etc. Further, it seems to me that path information MUST NOT be included makes too many assumptions about the larger context. If the file happens to have a natural name which, for instance, has date information in the path, like: /logs/2008/02/08/transaction.log and is routinely sent each day, the so-called real name of the file (transaction.log) is useless since it would be the same for every version of the file. A more appropriate requirement for both of these situations would be to put text in the Security Considerations section requiring any consumer of TimeStampedData to validate the entire filename according the rules of its local filesystem and its intended usage before using some or all of the name to store the data. -- Bill McQuillan [EMAIL PROTECTED] ___ Ietf mailing list Ietf@ietf.org http://www.ietf.org/mailman/listinfo/ietf
Re: IETF solution for pairing cellular hosts
On Tue, 2007-09-25, Pars Mutaf wrote: On 9/25/07, Suresh Krishnan [EMAIL PROTECTED] wrote: Pars Mutaf wrote: Model of operation 1. The querier user types the target user's human name (as if he were consulting a phonebook), or a pseudoynm. 2. The pairing request is forwarded to the target phone. How? How do you locate the target phone? Isn't this the problem we are trying to solve? For example (I'm not saying that this THE solution): You can have a relay agent where the human names map to MIPv6 home addresses of the target phones. This is the big problem. Human names are not unique enough! In a normal wire-line directory the name is associated with a fixed location, usually an address but at least a city. This can be used as a discriminator among possible name duplications by the querier. Cellphones do not provide the relay agent with such fixed, known information to assist in discriminating among customers with the same name. Since cellphones are so mobile there even might only be a country indication. Or were you intending that ALL phones of people with the same name be contacted. Wouldn't this just put the burden on all of the target users to determine the identity of the querier based onwhat? And how would any one of the targets determine that she was the intended victim? -- Bill McQuillan [EMAIL PROTECTED] ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
RFC Announcement Format
I am curious why all of the RFC Publication announcements on the IETF-Announce list since 2007 Jun 20 have been double-spaced throughout, except for the footer apparently added by the list software. -- Bill McQuillan [EMAIL PROTECTED] ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Comment on draft-wilde-text-fragment-06.txt
The discussion about least astonishment led me to review this document and I have to agree that it raises some issues of astonishment. It seems to me that the draft unnecessarily joins two separate concepts: 1 - Specifying a portion of a document, and 2 - Providing an identity check on the complete document. The mechanism proposed for #1 seems to be well specified. I have some comments on #2. I think what the hash sums are trying to do is verify the correct version of the whole document. I can think of a number of such checks off of the top of my head: 1 - md5 hash 2 - length 3 - charset 4 - Content-Id 5 - timestamp 6 - Content-Language Obviously not all of these attributes would be available from every source, but some of them are available from some sources. It also seems that these checks are useful when retrieving a whole document and not just a fragment. With the current proposal I could use (the somewhat obscure): http://example.com/text.txt#char=0,;length=9876 to apply an identity check to a whole document. It also seems that I might want to merely identify the required charset of the whole document, but I can not do so without specifying either a length or an md5 hash. Rather than just rework the phrase hash sum to reduce the astonishment, I would hope that would be possible to make these two separate text/plain add-on features more independent and even allow for the extension of the identity check feature in the future to more than just length, md5 and charset. -- Bill McQuillan ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
