Re: [TLS] Last Call: draft-ietf-tls-renegotiation (Transport Layer Security (TLS) Renegotiation Indication Extension) to Proposed Standard

On 09-12-01 12:19 AM, "David-Sarah Hopwood" wrote: > The IESG wrote: >> The IESG has received a request from the Transport Layer Security WG >> (tls) to consider the following document: >> >> - 'Transport Layer Security (TLS) Renegotiation Indication Extension ' >> as a Proposed Standard >>

Re: [TLS] Metadiscussion on changes in draft-ietf-tls-renegotiation

This makes no sense to me. Developers tend to live by the rule to be "liberal in what you accept" as it tends to generate less interop problems. It makes no sense to abort a TLS handshake just because it contains an SCSV if everything else is OK. So This "MUST NOT" requirement will likely be ignor

Re: [TLS] Metadiscussion on changes in draft-ietf-tls-renegotiation

Good points Marsh, but a few comments in line: On 10-01-29 4:53 PM, "Marsh Ray" wrote: > Stefan Santesson wrote: >> This makes no sense to me. >> >> Developers tend to live by the rule to be "liberal in what you accept" as it >> tends to

Re: Why the normative form of IETF Standards is ASCII

Julian, One minor question. How do you use xml2rfc to edit a document when you don't have that document in xml format? For example, if it was not originally created using xml2rfc. /Stefan On 10-03-22 2:58 PM, "Julian Reschke" wrote: > On 22.03.2010 22:28, Martin Rex wrote: >> ... >> With xml

Re: Why the normative form of IETF Standards is ASCII

On 10-03-12 8:34 PM, "Julian Reschke" wrote: >> Because of the page breaks and the consistent presence of these >> headers and footers just before and after the page breaks, an >> accessibility tool should be able to recognize them as such. > > I agree it would be nice if they did that. Do they

NroffEdit updated with December 2009 boilerplate

Andrew, You don't need an official template. You just need one that works and passes ID nits. NroffEdit comes with an nroff template that satisfies the ID nits check. I have just updated the NroffEdit tool with a new template that incorporates the December 2009 boilerplate. Downloads are availab

Re: Why the normative form of IETF Standards is ASCII

Actually, there seems to be one here: http://sourceforge.net/projects/rfc2xml/ Not sure how much of a good work it does. /Stefan On 10-03-24 5:10 PM, "Julian Reschke" wrote: > On 25.03.2010 00:56, Stefan Santesson wrote: >> Julian, >> >> One minor question. &

Re: Why the normative form of IETF Standards is ASCII

Martin, Thanks for your great review! On 10-03-26 4:17 PM, "Martin Rex" wrote: > I downloaded the WG document ASCII I-D (14-pages) from > http://tools.ietf.org/id/draft-ietf... > loaded it into NRoffEdit, selected "Edit->Convert Text to NRoff", > spent about 30 minutes fixing the Table Of Conte

Re: Review of draft-saintandre-tls-server-id-check

a human user? /Stefan On 10-09-08 3:40 PM, "Stefan Santesson" wrote: > Being the author of RFC 4985 I agree with most of you say here. > > Comments in line; > > On 10-09-06 8:48 PM, "Bernard Aboba" wrote: > >> That was in fact my original question. &

Re: Review of draft-saintandre-tls-server-id-check

Being the author of RFC 4985 I agree with most of you say here. Comments in line; On 10-09-06 8:48 PM, "Bernard Aboba" wrote: > That was in fact my original question. > > Section 5.1 states that the source domain and service type MUST be > provided by a human user, and can't be derived. Yet i

Re: Review of draft-saintandre-tls-server-id-check

ifier from the rediricet. Typical application I can think of is a redirect to a SAML IdP or a SAML Discovery service. /Stefan On 10-09-08 4:21 PM, "Stefan Santesson" wrote: > My apology, > > I just realized that the document defines "source domain" as what I tho

Re: I-D Action:draft-saintandre-tls-server-id-check-09.txt

First of all, I'm sorry for my late review. Time has been totally crazy after my vacation and I have worked nights and weekends in order to get to the point where I could go through this with the care it deserves. In case it matters, here are my comments: General: consider substituting ³PKIX-bas

Re: Review of draft-saintandre-tls-server-id-check

On 10-09-08 9:53 PM, "Shumon Huque" wrote: >> If the "reference identifier" is _Service.Name then the match is being done >> on the *input* to the SRV lookup process, not the output, and prohibition on >> DNS lookups would not apply (or even make any sense). > > Yes. > > The output of the S

Re: Review of draft-saintandre-tls-server-id-check

ot it wrong and should not be allowed. Unfortunately, for these reasons I still don't think the proposed text is satisfactory /Stefan On 10-09-09 12:01 AM, "Peter Saint-Andre" wrote: > On 9/8/10 11:28 AM, Stefan Santesson wrote: >> For clarity, I'll provide t

Re: Review of draft-saintandre-tls-server-id-check

Peter, Thank for the clarifying example. I see now what problem you are addressing. Comments in line; On 10-09-09 12:35 AM, "Peter Saint-Andre" wrote: >> It is not. RFC 4985 says the following in section 2: >> >> _Service.Name >> >> >> >> Name >> The DNS domain name

Re: Review of draft-saintandre-tls-server-id-check

On 10-09-09 12:10 AM, "Peter Saint-Andre" wrote: > Aha, I see the source of confusion. I think the first sentence of > Section 5.1 is better written as follows: > >When the connecting application is an interactive client, >construction of the reference identifier SHOULD be based on th

Re: [certid] Review of draft-saintandre-tls-server-id-check

be, then it's not. What needs to be checked is to me a typical case of local policy and one size does not fit all. /Stefan On 10-09-09 8:11 PM, "Shumon Huque" wrote: > On Thu, Sep 09, 2010 at 12:59:29AM +0200, Stefan Santesson wrote: >> Peter, >> >> I do

Re: [certid] Review of draft-saintandre-tls-server-id-check

On 10-09-09 8:38 PM, "Shumon Huque" wrote: > Earlier in RFC 4985, it says: > >The SRVName, if present, MUST contain a service name and a domain >name in the following form: > > _Service.Name > >The content of the components of this name form MUST be consistent >with th

Re: [certid] Review of draft-saintandre-tls-server-id-check

Shumon, On 10-09-09 10:08 PM, "Shumon Huque" wrote: >> PKI enabled clients in general are used to check numerous of name forms and >> attributes in order to determine a match. > > Can you give us some examples of such applications, and where > their subject identity matching rules are specified

Re: [certid] Review of draft-saintandre-tls-server-id-check

On 10-09-13 7:03 PM, "Shumon Huque" wrote: >> >> Authorized by whom? I *think* that here the DNS domain name is one that >> the certified subject has itself authorized (perhaps even "established" >> is better) to provide the desired service. Therefore I suggest an >> alternative wording: >> >>

Re: Review of draft-saintandre-tls-server-id-check

Peter, On 10-09-13 6:08 PM, "Peter Saint-Andre" wrote: > > Hi Shumon, > > As I see it, this I-D is attempting to capture best current practices > regarding the issuance and checking of certificates containing > application server identities. Do we have evidence that any existing > certification

Re: Review of draft-saintandre-tls-server-id-check

Peter, Comments in line; On 10-09-13 9:16 PM, "Peter Saint-Andre" wrote: > On 9/13/10 12:39 PM, Stefan Santesson wrote: >> Peter, >> >> On 10-09-13 6:08 PM, "Peter Saint-Andre" wrote: >>> >>> Hi Shumon, >>> >&

Re: Review of draft-saintandre-tls-server-id-check

neral cases you are not interested in the host DNS name. I've decided that I'm perfectly fine with your proposed wording. /Stefan On 10-09-14 5:32 AM, "Peter Saint-Andre" wrote: > On 9/13/10 6:03 PM, Stefan Santesson wrote: >> Peter, >> Comments in line; >

Re: Review of draft-saintandre-tls-server-id-check

Peter, After the past discussions, the remaining things on my review list are: General: consider substituting ³PKIX-based systems² and ³PKIX Certificates² with ³PKI systems based on RFC 5280² and ³RFC 5280 Certificates², alternatively include [PKIX] brackets to clarify that it references RFC 5280

Re: More liberal draft formatting standards required

To respond to the original question. For what it is worth, I have written a simple and free tool in java for editing (and viewing) drafts using nroff, which I find a lot easier and convenient than XML. It's available from: http://aaa-sec.com/nroffedit/index.html Source is available upon request.

Re: More liberal draft formatting standards required

ld E. Eastlake 3rd > d3e...@gmail.com > > On Wed, Jul 1, 2009 at 2:22 AM, Stefan Santesson wrote: >> To respond to the original question. >> >> For what it is worth, I have written a simple and free tool in java for >> editing (and viewing) drafts using n

Re: More liberal draft formatting standards required

On 09-07-02 1:00 AM, "Randy Presuhn" wrote: > One of the advantages of nroff input is that it *is* human readable. (To me > it seems much easier to read than HTML, but that's not the issue here.) > To generate formatted output (in a variety of possible formats) the freely- > available groff prog

Re: [Tools-discuss] Java application for editing nroff formatted Internet Drafts

FYI, I have just released version 0.8 of NroffEdit (WYSIWYG nroff editor linked at http://tools.ietf.org/tools/) This version is now fully compatible with the IETF nroff template file (http://aaa-sec.com/pub/NroffEdit/2-nroff_template.nroff) and correctly implements all features that is supported

Re: [Tools-discuss] Java application for editing nroff formatted Internet Drafts

Sorry for the double posting. The link to the tool fell off. Here it is: http://aaa-sec.com/nroffedit/index.html /Stefan On 09-07-05 9:08 PM, "Stefan Santesson" wrote: > FYI, > > I have just released version 0.8 of NroffEdit (WYSIWYG nroff editor linked > at http:

Re: XML2RFC must die, was: Re: Two different threads - IETF Document Format

I also would be against mandating xml2rfc. I do agree that certain aspects of xml2rfc are convenient, but when it comes to edit text, I really prefer .nroff On 09-07-05 8:16 PM, "ned+i...@mauve.mrochek.com" wrote: > I particularly like the fact that xml2rfc lets me focus on the content of my >

Re: [Tools-discuss] Java application for editing nroff formatted Internet Drafts

Update FYI, In light of the xml2rfc discussion, I have now updated the NroffEdit tool (version 0.84) so that it correctly supports nroff content that has been auto generated by the xml2rfc tool. /Stefan On 09-07-05 10:08 PM, "Stefan Santesson" wrote: > > Sorry for th

Automatically updated Table of Contents with Nroff

As I know there are quite some Nroff users still out there, this might be welcome news. While I quite like Nroff for its easy to use and readability. one of the problem that always have annoyed me with Nroff is to manually update the Table of Content. This is something where xml2rfc have a great e

Re: Last Call: draft-ietf-pkix-ta-format (Trust Anchor Format) to Proposed Standard

Carl, I think the critique of the TSL work is well founded from the perspective of TAM, but there is nevertheless an important point here. While TSL might not be an ideal standard for automated trust anchor management, very much caused by its mixed scope of fields for both human and machine consu

Re: Last Call: draft-ietf-pkix-ta-format (Trust Anchor Format) to Proposed Standard

ul Hoffman" wrote: > > At 12:42 AM +0200 7/15/09, Stefan Santesson wrote: >> There is a substantial risk that we will see two very different approaches >> that at least overlap in scope, which may harm interoperability. > > And? > > Are you proposing tha

Re: Automatically updated Table of Contents with Nroff

Donald Eastlake" wrote: > It's trivial to define nroff macros to create a Table of Contents. > > Donald > = > Donald E. Eastlake 3rd +1-508-634-2066 (home) > 155 Beaver Street > Milford, MA 01757 USA > d3e...@gmail.com >

Re: Last Call: draft-ietf-pkix-ta-format (Trust Anchor Format) to Proposed Standard

he appropriate format that meets > its needs. Certificates are not suitable as trust anchors in all cases. > TAF is a relatively minimal, natural solution to this problem. > > >> -Original Message- >> From: Stefan Santesson [mailto:ste...@aaa-sec.com] >>

Re: Automatically updated Table of Contents with Nroff

All of this is interesting reading indeed and reveals stuff that I did not know about. However, I have never regarded boilerplate issues as something that has bothered me a lot when writing a draft. These boilerplates are pretty stable and once you got them in place in the first draft (often by co

Re: Automatically updated Table of Contents with Nroff

efore I'm done. Page breaks is the least of the issues. What is more important is that sections describing protocol syntax is not all messed up with wrong indent, line breaks etc. I guess not everyone appreciate WYSIWYG, but I do :) /Stefan On 09-07-16 12:15 PM, "Julian Reschke"

Re: Automatically updated Table of Contents with Nroff

Julian, For me this is not about nroff versus xml and I'm really not trying to convince anyone to move away from xml. I meant to discuss how to do TOC and other formatting for those who like to edit in nroff. /Stefan On 09-07-16 1:17 PM, "Julian Reschke" wrote: > Stef

New major release of NroffEdit

For your information: A new major release of NroffEdit is available from: http://aaa-sec.com/nroffedit/index.html This version provides several features requested by the RFC editor as well as other IETF:ers. This includes: - Added background spellchecker - Color and style formats added to Nroff

Re: New major release of NroffEdit

Resending as original mail got lost. Sorry for double posing in case it turns up... On 09-08-31 7:21 PM, "Stefan Santesson" wrote: > For your information: > > A new major release of NroffEdit is available from: > http://aaa-sec.com/nroffedit/index.html > > T

Current ietf e-mail delays

I and others have experienced unusually long delays from posting messages to various ietf mailing lists lately. 4-5 hours delivery time or more is not uncommon. Anyone else having the same issue or any idea what the problem is? /Stefan ___ Ietf mailing

NroffEdit updated with new boilerplate

Short informational notice. A new update of NroffEdit is available ( http://aaa-sec.com/nroffedit/index.html ), supporting the boilerplate from the new Trust Legal Provisions from September 2009. /Stefan ___ Ietf mailing list Ietf@ietf.org https://www.i

RE: [TLS] Re: Last Call: 'TLS User Mapping Extension' to Proposed Standard

. Stefan Santesson Program Manager, Standards Liaison Windows Security -Original Message- From: Russ Housley [mailto:[EMAIL PROTECTED] Sent: den 19 februari 2006 23:22 To: Bill Fenner; Steven M. Bellovin Cc: iesg@ietf.org; [EMAIL PROTECTED]; ietf@ietf.org Subject: [TLS] Re: Last Call: 

RE: Last Call: 'TLS User Mapping Extension' to Proposed Standard

This empty appendix was removed in draft 02. As Russ stated before, an IPR disclosure has been posted to the IETF IPR page which can be found at: Stefan Santesson Program Manager, Standards Liaison Windows Security -Original Message- From: Bill Strahm [mailto:[EMAIL PROTECTED] Sent

RE: Last Call: 'TLS User Mapping Extension' to Proposed Standard

Sorry, managed to hit send button to early. The IPR statement is available at: https://datatracker.ietf.org/public/ipr_detail_show.cgi?ipr_id=688 Stefan Santesson Program Manager, Standards Liaison Windows Security -Original Message- From: Stefan Santesson Sent: den 28 februari 2006

RE: [TLS] Re: Last Call: 'TLS User Mapping Extension' toProposedStandard

y has stated that it prefers out of the types the client has stated that it supports. While it would be technically possible to implement the same solution along with Eric's alternative suggestions, I don't think it has been demonstrated that it would provide any significant advantages. S

RE: [TLS] Re: Last Call: 'TLS User Mapping Extension' toProposedStandard

becomes a problem. Stefan Santesson Program Manager, Standards Liaison Windows Security -Original Message- From: Russ Housley [mailto:[EMAIL PROTECTED] Sent: den 28 februari 2006 17:19 To: EKR Cc: Stefan Santesson; Ari Medvinsky; ietf@ietf.org; [EMAIL PROTECTED] Subject: Re: [TLS] Re: Last

RE: draft-santesson-tls-ume Last Call comment

come back with a proposal on new text later today. Stefan Santesson Program Manager, Standards Liaison Windows Security -Original Message- From: Mark Andrews [mailto:[EMAIL PROTECTED] Sent: den 8 mars 2006 04:23 To: Eric A. Hall Cc: Kurt D. Zeilenga; ietf@ietf.org Subject: Re: draft

RE: Re: [TLS] Re: Last Call: 'TLS User Mapping Extension' to Proposed Standard

I was made aware of these comments that in some mysterious way didn't make its way to my inbox. Sorry for the delay. Comments in-line; Stefan Santesson Program Manager, Standards Liaison Windows Security >Date: Tue, 28 Feb 2006 10:54:35 -0800 >From: Wan-Teh Chang <[EMAIL PROTECTED

RE: Re: [TLS] Re: Last Call: 'TLS User Mapping Extension' to Proposed Standard

Russ, Thanks for that clarification. This is what I poorly was trying to communicate. Stefan Santesson Program Manager, Standards Liaison Windows Security > -Original Message- > From: Russ Housley [mailto:[EMAIL PROTECTED] > Sent: den 20 mars 2006 14:09 > To: Stefan Sante

RE: draft-santesson-tls-ume Last Call comment

ctions for the accessed system. Stefan Santesson Program Manager, Standards Liaison Windows Security > -Original Message- > From: Eric A. Hall [mailto:[EMAIL PROTECTED] > Sent: den 7 mars 2006 21:06 > To: Mark Andrews > Cc: Kurt D. Zeilenga; ietf@ietf.org > Subject:

RE: draft-santesson-tls-ume Last Call comment

s such the client will also know in what form the server needs it. The client should never send the name hint in a way where the server needs to process it in order to map the hint to an account. There reference will be fixed (or removed). Stefan Santesson Program Manager, Standards Liaison Window

Re: [pkix] Last Call: (X.509 Internet Public Key Infrastructure Online Certificate Status Protocol - OCSP) to Proposed Standard

Martin, Whether we like it or not. This is the legacy. There is no way for a client to know whether the OCSP responder implements RFC 2560 only or in combination with RFC 5019. So therefore, the update that was introduced in 5019 must be expected by all clients from all responders. Therefore it i

Re: [pkix] Last Call: (X.509 Internet Public Key Infrastructure Online Certificate Status Protocol - OCSP) to Proposed Standard

5019, that using "unauthorized" in the present manner was a reasonable tradeoff. I still think it is. Unless you can convince the community of your course of action, I don't see this happening. /Stefan On 3/26/13 6:28 AM, "Martin Rex" wrote: >Stefan Santesson wrote:

Re: [pkix] Last Call: (X.509 Internet Public Key Infrastructure Online Certificate Status Protocol - OCSP) to Proposed Standard

On 3/26/13 12:13 PM, "Martin Rex" wrote: >Adding 3 more OCSPResponseStatus error codes { no_authoritative_data(7), >single_requests_only(8), unsupported_extension(8) } with well-defined and >conflict-free semantics to the existing enum would be perfectly backwards >compatible. Of course it is ba

Re: [pkix] Last Call: (X.509 Internet Public Key Infrastructure Online Certificate Status Protocol - OCSP) to Proposed Standard

What OCSP client are you using that behaves like this? On 3/26/13 1:09 PM, "Martin Rex" wrote: >I would no longer get a popup from my OCSP client that tells my >that I'm unauthorized to submit OCSPRequests to that server, and that >the server has been moved to a blacklist

Re: [pkix] Last Call: (X.509 Internet Public Key Infrastructure Online Certificate Status Protocol - OCSP) to Proposed Standard

ave to convince. It's the community of implementers. /Stefan On 3/26/13 1:39 PM, "Martin Rex" wrote: >Stefan Santesson wrote: >> What OCSP client are you using that behaves like this? >> >> On 3/26/13 1:09 PM, "Martin Rex" wrote: >> >>

Re: Gen-ART review of draft-ietf-pkix-rfc2560bis-15

Hi David, Thanks for the review. My reply in line. On 3/26/13 1:25 AM, "Black, David" wrote: >Authors, > >I am the assigned Gen-ART reviewer for this draft. For background on >Gen-ART, please >see the FAQ at . > >Please resolve these comm

Re: Gen-ART review of draft-ietf-pkix-rfc2560bis-15

quirement. Why is that the case? > >-- > >Beyond that, the proposed actions (or proposed non-actions) on items >[2]-[5] >are fine with me, Sean's taken care of the author permissions item from >idnits, and I assume someone has or will check the ASN.1 . > &g

Re: [pkix] Last Call: (X.509 Internet Public Key Infrastructure Online Certificate Status Protocol - OCSP) to Proposed Standard

It is risky to assume that existing clients would work appropriately if you send them a new never seen before error code. I'm not willing to assume that unless a big pile of current implementers assures me that this is the case. /Stefan On 3/27/13 3:14 PM, "Martin Rex"

Re: Gen-ART review of draft-ietf-pkix-rfc2560bis-15

uot;running >code" >concerns, IMHO) and alternatives to using "revoked" ("have a number of >tools >to prevent the client from accepting a bad certificate") seem particularly >relevant. > >Thanks, >--David > >> -Original Message- >> Fro

Re: Gen-ART review of draft-ietf-pkix-rfc2560bis-15

eaching a (compromise) decision, it really is valuable >to record why the decision was reached to avoid recovering that ground >in the future and (specific to this situation) to give implementers some >more context/information on how the protocol is likely to work in >practice. > &g

Re: Gen-ART review of draft-ietf-pkix-rfc2560bis-15

>"revoked" is optional, and the existing text on CRLs as a fallback >mechanism suffices to illuminate a likely consequence of not using >"revoked". > >Thank you, >--David > >> -Original Message- >> From: Carlisle Adams [mailto:cad...@ee

Re: [pkix] Last Call: (X.509 Internet Public Key Infrastructure Online Certificate Status Protocol - OCSP) to Proposed Standard

On 3/27/13 10:11 PM, "Martin Rex" wrote: >It was the Security co-AD Russ Housley who indicated _early_ during >the discussion of that draft (2.5 years after it had been adopted >as a WG item) that he considered some of the suggested abuses of >existing error codes "unacceptable" For the record.

Re: [pkix] Gen-ART review of draft-ietf-pkix-rfc2560bis-15

On 3/29/13 5:17 PM, "Piyush Jain" wrote: >' "revoked" status is still optional in this context in order to maintain >backwards compatibility with deployments of RFC 2560.' > >I fail to understand this statement about backward compatibility. >How does "revoked" being "optional/required breaks back

Re: [pkix] Last Call: (X.509 Internet Public Key Infrastructure Online Certificate Status Protocol - OCSP) to Proposed Standard

Nothing has changed in this regard. The good response is pretty clear that it by default provides information that the cert is not on a black-list (is not know to be revoked). However, it is also made clear that extensions may be used to expand this default information about the status. This is h

Re: [pkix] Last Call: (X.509 Internet Public Key Infrastructure Online Certificate Status Protocol - OCSP) to Proposed Standard

On 4/12/13 1:31 AM, "Henry B. Hotz" wrote: >What I would find helpful, and what I think some people really would >like, is for OCSP to be able to provide white-list information in >addition to the previous black-list information. When I read through >2560bis, I could not tell if there was an ext

Re: [pkix] Last Call: (X.509 Internet Public Key Infrastructure Online Certificate Status Protocol - OCSP) to Proposed Standard

On 4/13/13 2:53 AM, "Henry B. Hotz" wrote: >You've just said that there are only two valid responses from an OCSP >server which has access to a white list. In other words such a server >inherently cannot provide any information about the actual revocation >status of a cert, and its responses ca

Re: [pkix] Last Call: (X.509 Internet Public Key Infrastructure Online Certificate Status Protocol - OCSP) to Proposed Standard

On 4/13/13 6:51 PM, "Piyush Jain" wrote: > >> An extension may differentiate which serial number that results in a >> "revoked" response, that is actually issued and revoked, or if there is >any >> other particular reason for responding "revoked". >> In my universe a syntactically valid serial

Re: [pkix] Last Call: (X.509 Internet Public Key Infrastructure Online Certificate Status Protocol - OCSP) to Proposed Standard

On 4/13/13 8:56 PM, "Piyush Jain" wrote: >> >[Piyush] From an RP's perspective finding status of serial numbers >> >serves no purpose unless they can associate that serial number with a >> >certificate. >> >> Absolutely, that is the client's perspective of this. > >Great. We agree >> >> >Whe

New version of NroffEdit released for IETF80

I have made some significant improvements to the NroffEdit IETF draft editor. Most notably, NroffEdit will now build your list of references automatically based on the IETF citation library. A new "look for update" function will automatically download the latest version of the library as well as u

Re: Automatically updated Table of Contents with Nroff

Julian, Sorry for an awfully late response, but just spotted this and thought I should clarify as author of the NroffEdit tool. >> >> >> >> NRoffEdit is an all-in-one wysiwyg tool in Java that maintains >> the TOC for you (within the .nroff source itself). > >Which will only work properly as lon

Re: Automatically updated Table of Contents with Nroff

eschke wrote: >>> >>> On 17.03.2011 01:07, Stefan Santesson wrote: >>>> ... >>>> This is not correct. >>>> >>>> The automatic ToC function (and now since version 1.40 also the >>>>automated >>>> reference function)

Re: Automatically updated Table of Contents with Nroff

OK, I understand what you say now. All they have to do is to run it through NroffEdit once more after they are done with their nroff editing. They don't use NroffEdit as their main tool for nroff editing, but they do have it and use it (at least last time I talked to them). But agreed, NroffEdit

Re: Automatically updated Table of Contents with Nroff

It's up to them, but it could easily be done if they want to. It could even easily be done even if there is no nroff since NroffEdit can generate nroff from text and then generate the ToC. /Stefan On 11-03-17 5:03 PM, "Julian Reschke" wrote: >On 17.03.2011 16:55, Stef

Re: New version of NroffEdit released for IETF80

57 AM, "Stefan Santesson" wrote: >I have made some significant improvements to the NroffEdit IETF draft >editor. > >Most notably, NroffEdit will now build your list of references >automatically based on the IETF citation library. >A new "look for update" function will

Re: Automatically updated Table of Contents with Nroff

I can't escape the feeling that this discussion of using markup language editing to produce RFCs, is a bit upside down. I'm much more concerned with draft writers having to deal with markup syntax than I am about drafters trying to put a page break in a sensible location, or format their text in a

Change notice of the handling of escape characters in NroffEdit

I recently discovered a bug in NroffEdits handling of the escape character backslash "\". If you are using NroffEdit today and write drafts where backslash is used in your draft text, then the output of your draft may change when upgrading to NroffEdit 2.02 (released yesterday). There is however

Re: Automatically updated Table of Contents with Nroff

Ned, On 11-03-24 9:48 PM, "Ned Freed" wrote: >> I can't escape the feeling that this discussion of using markup language >> editing to produce RFCs, is a bit upside down. > >> I'm much more concerned with draft writers having to deal with markup >> syntax than I am about drafters trying to put a

Re: Automatically updated Table of Contents with Nroff

Great thoughts from many people. I just want to clarify a few things as I see that my message is slightly misunderstood. Firstly: The core of my opinion is NOT that I think people should convert to nroff encoding or XML coding or XHTML encoding or whatever encoding as editing language. I don't th

Now safe to download NroffEdit 2.05

ately. Thanks for all feedback that helped this version get better. /Stefan Santesson ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf

Problems using the default ftp settings in NroffEdit for diff display

It has come to my attention that there is a problem using the default ftp settings for displaying the diff between the current edited draft and the latest published draft using NroffEdit. The reason is that I signed up for a free ftp service without understanding that they had a per month max traf

Re: Problems using the default ftp settings in NroffEdit for diff display

plans to do what you suggest, but I don't have time to do it atm. It will be implemented before the summer is over I think. /Stefan On 11-05-25 2:31 AM, "Martin Rex" wrote: >Stefan Santesson wrote: >> >> It has come to my attention that there is a problem usin