Subject: [Sipping] Request for editorial input

From: Robert Sparks <[email-masked]>
Date: 07 Aug 2003 13:41:52 -0500

As noted at IETF57, I'm picking up editorship of the torture-test
document.

One of the things I want to do is disambiguate the printed text
examples. There are cases now where the torture consists of having very
long text fields. For example:

CSeq:
239sdfadfnm34r5u09sdfawetrq3o4t5nodifnaoihesfoiw34foisdfeijjnaosdfj4iosdfnaehnaasoo34ijdfn5kl3neasdfvnazs

which gets broken into a format that is not valid for SIP when you try
to render withing the 72 column limit of internet drafts. (Its probably
also broken badly in this message by many mail readers).

I propose making such breaks explicit as follows:

If I needed to break the following (short for clarity) header field:

Foo: areallybigtoken

I'll render it as

Foo: areally<break>
     </break>bigtoken

or

Foo: areally<break>
     </break>big<break>
     </break>token

Objections? Alternative suggestions?

Additionally, I'm considering including an appendix with an
ascii-armored container (a zip-file or compressed tarball
perhaps) with each message (so that we can include some
torturous whitespace and non-ASCII range UTF8 tests.

RjS

_______________________________________________
Sipping mailing list  https://www1.ietf.org/mailman/listinfo/sipping
This list is for NEW development of the application of SIP
Use [email-masked] for questions on current sip
Use [email-masked] for new developments of core SIP

---

From: Alan Hawrylyshen <[email-masked]>
Date: Thu, 7 Aug 2003 17:57:20 -0600

> As noted at IETF57, I'm picking up editorship of the torture-test

Excellent.

> [snip]
> [snip]

I'm tempted to suggest something less intrusive like a single EOL 
marker that indicates that the next line's leading WS is to be elided 
from the example text. Something like '*' or '~'.
eg)
Foo: areally~
      big~
	 token

equivalent to:

Foo: areallybigtoken

Of course this means that the above (legal) SIP would be hard to 
represent in the draft in literal form.

Not that this is better, but is IS more readable (IMHO). Perhaps there 
is a problem that I am overlooking with this, but it is certainly less 
intrusive. :-) Thoughts?

As for the appendix, are you proposing that the published draft would 
contain the (potentially base 64) encoded compressed archive of example 
messages -- completely unreadable by humans, but useful for extracting 
the examples?

Alan Hawrylyshen
Jasomi Networks Inc.

---

From: Robert Sparks <[email-masked]>
Date: 08 Aug 2003 09:00:07 -0500

inline
> is a problem that I am overlooking with this, but it is certainly less 

Adam suggested something similar (based on MIME conventions). 

My concern (fwiw) is that I don't expect it to be easy to find a single
symbol that wouldn't be a legal character where it was breaking a line
(it's not always a token that needs breaking). We could adopt a
convention that anytime that appeared last on a line in the text of
this document it has special meaning, but it brings us back to
ambiguity. Arguably, this <break></break> can suffer from the same
deficiency, but it uses a high level of intrusiveness as a tool to help
resolve the ambiguity in the intended way.

An alternative would be to put in the examples something along the lines
of:

   INVITE sip:a.example.com SIP/2.0
   To: sip:b.example.com
<allOneLine>
   Call-ID: 23423423039480239840234
            2390498u239759237947293
            39457349539485739485739
            20234802908u09823095480
</allOneLine>
   CSeq: 83347 INVITE

That said, I don't feel too strongly about how we add this extra hint
as long as we add something.

> messages -- completely unreadable by humans, but useful for extracting 

Exactly. A few pages of 4799EA9280F923870CDD3988A... or the like.

---

From: Cullen Jennings <[email-masked]>
Date: Sat, 09 Aug 2003 11:37:56 -0700

Some convention like this would be very helpful to me in the S/MIME example
call flows. Just about anything would be fine with me. Does this need to be
a IETF discussion?

---

From: Rohan Mahy <[email-masked]>
Date: Fri, 15 Aug 2003 13:18:26 -0700

Hi Robert,

The issue that you raise is also a problem for SMIME examples.  We need  
a way to display binary non-ASCII data.  We can display this using  
textual conventions like you suggest for short sections, but for longer  
sections of non-text formatted data, perhaps we need to use a hexdump  
format like the compression folks use (see the SIP static compression  
dictionary).

thanks,
-rohan