Subject: [IPP] IPP over HTTP Transport Binding and 'ipps' URI Scheme (7 April 2014)

From: Ira McDonald <[email-masked]>
Date: Mon, 7 Apr 2014 11:32:56 -0400

Hi,

I've just posted another Internet-Draft of IPP over HTTP Transport Binding
and
'ipps' URI Scheme to:

ftp://ftp.pwg.org/pub/pwg/ipp/wd/draft-mcdonald-ipps-uri-scheme-10-20140407.txt
 - plaintext Internet-Draft format (warning - contains explicit formfeed
characters)

ftp://ftp.pwg.org/pub/pwg/ipp/wd/draft-mcdonald-ipps-uri-scheme-10-20140407.pdf
 - PDF of plaintext w/ line numbers (review *this* one)

This document has already been accepted and posted to the IETF I-D
repository.

This document is parallel to, but does not update or obsolete, RFC 3510.

This version has *minor* editorial changes since the previous version -
based on
IPP WG review on 31 March 2014.

Comments?

Cheers,
- Ira

------------------------------------

Change History

   7 April 2014 - draft-mcdonald-ipps-uri-scheme-11.txt
   Global - revised all references to section 4.2 and section 4.3, to
   add parenthetic (syntax) and (port) respectively, per IEEE-ISTO PWG
   IPP WG review.

   Editorial - Revised section 4.2 Syntax of 'ipps' URI Scheme, to
   correct two typos (extra words) in section 4.3 references, per
   IEEE-ISTO PWG IPP WG review.

   Editorial - Revised section 4.3 Associated Port for 'ipps' URI
   Scheme, to add note about compatibility for IPP Clients and IPP
   Printers that MUST accept explicit port 443 (assigned in 'https' URI
   scheme [RFC2818]) and process normally, per IEEE-ISTO PWG IPP WG
   review.

   Editorial - Revised section 4.6.1 Examples of 'ipps' URI for
   Printers, to add example of explicit port 443, per IEEE-ISTO PWG IPP
   WG review.
_______________________________________________
ipp mailing list
[email-masked]
https://www.pwg.org/mailman/listinfo/ipp

---

From: Ira McDonald <[email-masked]>
Date: Mon, 7 Apr 2014 11:54:00 -0400

Hi,

BTW - The correct title of this document (as published) is:
"IPP over HTTPS Transport Binding and 'ipps' URI Scheme".

That is to say, it's a binding of IPP over a mandatory HTTPS
session (TCP connection, TLS connection, HTTP connection
in that order only).

Sorry for the long-standing incorrect email subject lines.

Cheers,
- Ira

Ira McDonald (Musician / Software Architect)
Co-Chair - TCG Trusted Mobility Solutions WG
Chair - Linux Foundation Open Printing WG
Secretary - IEEE-ISTO Printer Working Group
Co-Chair - IEEE-ISTO PWG Internet Printing Protocol WG
IETF Designated Expert - IPP & Printer MIB
Blue Roof Music / High North Inc
http://sites.google.com/site/blueroofmusic
http://sites.google.com/site/highnorthinc
mailto: [email-masked]
Winter  579 Park Place  Saline, MI  48176  734-944-0094
Summer  PO Box 221  Grand Marais, MI 49839  906-494-2434

On Mon, Apr 7, 2014 at 11:32 AM, Ira McDonald <[email-masked]>wrote:

> Hi,
>
> I've just posted another Internet-Draft of IPP over HTTP Transport
> Binding and
> 'ipps' URI Scheme to:
>
>

---

From: "Gyaneshwar C Gupta" <[email-masked]>
Date: Tue, 8 Apr 2014 10:18:57 +0900

Dear PWG Members,

I have a simple request to PWG expert members' about IPP FaxOut spec. I will
be thankful if someone can please kindly response to my following request; 

On the IPP FaxOut spec (

http://ftp.pwg.org/pub/pwg/candidates/cs-ippfaxout10-20131115-5100.15.pdf):

-----------------

7.2.3 destination-uris

...

DialString = 1*(phonedigit / dtmf-digit / pause-character)

pause-character = one-second-pause / wait-for-dial-tone

one-second-pause = "p"

wait-for-dial-tone = "w"

dtmf-digit = "*" / "A" / "B" / "C" / "D" / "#"

phonedigit = DIGIT / [ visual-separator ]

visual-separator = "-" / "." / "(" / ")" / "'"

-----------------

Request:

We'd like to implement our MFP to support a character which corresponds to

an action of "flash".

So we'd like PWG to define a character of "flash" in IPP FaxOut spec.

For example, we think the following definition is appropriate:

---

DialString = 1*(phonedigit / dtmf-digit / pause-character /

flash-character)

...

flash-character = "f"

Thank you in advance for your kind help and cooperation.

Regards,

Gyaneshwar 

Gyaneshwar C. Gupta, Ph.D.

Director, Corporate R&D Center

Oki Electric Industry Co., Ltd.

Japan

+81-48-431-5489 (Office)

[email-masked]

---

From: Michael Sweet <[email-masked]>
Date: Tue, 08 Apr 2014 09:09:39 -0400

Let's discuss this at the next IPP conference call (Monday, April 14th at 3pm)

I don't foresee any issues with this addition, but it will require an errata update (at least) of the FaxOut spec.

On Apr 7, 2014, at 9:18 PM, Gyaneshwar C Gupta <[email-masked]> wrote:

> Dear PWG Members,
>  
> I have a simple request to PWG expert members' about IPP FaxOut spec. I will be thankful if someone can please kindly response to my following request;
>  
> On the IPP FaxOut spec (

_________________________________________________________
Michael Sweet, Senior Printing System Engineer, PWG Chair

---

From: Ira McDonald <[email-masked]>
Date: Tue, 8 Apr 2014 11:33:13 -0400

Hi,

Could you please explain why, during the dialing of a PSTN fax connection,
someone would want to use flash to skip to another line and dialtone?

I can't understand the practical use case.

Cheers,
- Ira

On Tue, Apr 8, 2014 at 9:09 AM, Michael Sweet <[email-masked]> wrote:

> I don't foresee any issues with this addition, but it will require an
> errata update (at least) of the FaxOut spec.
>
>
> I have a simple request to PWG expert members' about IPP FaxOut spec. I
> will be thankful if someone can please kindly response to my following
> request;
>
>
>
> On the IPP FaxOut spec (
>

---

From: Steve King <[email-masked]>
Date: Wed, 9 Apr 2014 13:48:18 +1000

It looks like in some cases people are using Flash/Recall as a
failover/logic pattern in some Voip setups.

It seems, from my knowledge of voip setups and a quick ask around, that
using flash/recall you can force the PABX to switch to a physical line,
rather than using a SIP connection out from the PABX. That is, in the above
example, that dialing with the "f" at the end would denote that this should
be carried over a copper/digital line rather than a protocol line.

Steve.