Subject: RE: [Sipping] Request for editorial input

From: Adam Roach <[email-masked]>
Date: Fri, 8 Aug 2003 13:52:10 -0500

Actually, my suggestion (although I didn't do a good job
of conveying it) would be to encode *all* the examples
using MIME Quoted-Printable encoding, thus removing all
ambiguity (and providing testers with ready-built decoders).

The downside of having all instances of "=" appear as
"=3D" should, of course, be considered....

/a

> -----Original Message-----
> From: Robert Sparks [mailto:[email-masked]]
> Sent: Friday, August 08, 2003 9:00
> To: Alan Hawrylyshen
> Cc: [email-masked]
> Subject: Re: [Sipping] Request for editorial input
> 
> 
> inline
> On Thu, 2003-08-07 at 18:57, Alan Hawrylyshen wrote:
> > On Thursday, Aug 7, 2003, at 12:41 Canada/Mountain, Robert 
> Sparks wrote:
> > > [snip]
> > > I propose making such breaks explicit as follows:
> > > [snip]
> > > Foo: areally<break>
> > >      </break>bigtoken
> > >
> > > or
> > >
> > > Foo: areally<break>
> > >      </break>big<break>
> > >      </break>token
> > >
> > >
> > 
> > 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?
> 
> 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.
> 
> > 
> > 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?
> 
> Exactly. A few pages of 4799EA9280F923870CDD3988A... or the like.
> 
> 
> > 
> > 
> > Alan Hawrylyshen
> > Jasomi Networks Inc.
> 
> 
> _______________________________________________
> 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
> 

_______________________________________________
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: "Chris Boulton" <[email-masked]>
Date: Mon, 11 Aug 2003 10:13:07 +0100

inline

>Sent: 08 August 2003 15:00
>To: Alan Hawrylyshen
>Cc: [email-masked]
>> On Thursday, Aug 7, 2003, at 12:41 Canada/Mountain, Robert Sparks
wrote:
>> marker that indicates that the next line's leading WS is to be elided
>> 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
>My concern (fwiw) is that I don't expect it to be easy to find a single
>deficiency, but it uses a high level of intrusiveness as a tool to help
>An alternative would be to put in the examples something along the
lines
>   Call-ID: 23423423039480239840234

[Chris Boulton] Robert, This one looks fine to me.

>> As for the appendix, are you proposing that the published draft would
>> contain the (potentially base 64) encoded compressed archive of
example
extracting